Jump to content
  • 0

HTMLSpecialChars


iKNG
 Share

Question

Собственно, я в своих сайтах и сайтах заказчиков всегда обрабатываю пользовательские данные этой функцией. Но так ли уж она надежна? Неужели это простое превращение пары символов в спецсимволы может остановить любого, даже лучшего хакера?

Link to comment
Share on other sites

17 answers to this question

Recommended Posts

  • 0
Неужели это простое превращение пары символов в спецсимволы может остановить любого, даже лучшего хакера?

Запомните одну вещь: если вас захотят "поломать", вас "поломают". Главное на сколько сильно будет это желание. Не смогут пробиться через сайт, - полезут через хостинг(OS,httpd,СУБД...). А уж в абсолютной безопасности своего хостера врятли кто-то может быть уверен.

Поэтому не стоит пытаться защитится от

лучшего хакера
. Это мое исключительно субъективное мнение.
Link to comment
Share on other sites

  • 0

 

Неужели это простое превращение пары символов в спецсимволы может остановить любого, даже лучшего хакера?

Запомните одну вещь: если вас захотят "поломать", вас "поломают". Главное на сколько сильно будет это желание. Не смогут пробиться через сайт, - полезут через хостинг(OS,httpd,СУБД...). А уж в абсолютной безопасности своего хостера врятли кто-то может быть уверен.

Поэтому не стоит пытаться защитится от

 

лучшего хакера
. Это мое исключительно субъективное мнение.

 

Я имею в виду защиту конкретно на стороне скрипта. Взломать через него - это первое, что пытаются сделать большинство хакеров.

Link to comment
Share on other sites

  • 0

По желанию можно взломать через Blind sql injection

простую sql injection

через mysql программы, способов моря..

 

Хочу тока сказать одно, если вы хотите что бы вас не сломали стан те сами хакером и пытайтесь ломать свой сайт, через что сломали то и прав те...

Link to comment
Share on other sites

  • 0

Собственно, я в своих сайтах и сайтах заказчиков всегда обрабатываю пользовательские данные этой функцией. Но так ли уж она надежна? Неужели это простое превращение пары символов в спецсимволы может остановить любого, даже лучшего хакера?

Хотя, любой код можно взломать (даже восстановить пароль из md5 хэша), в данном случае имеет место быть паранойя.

Link to comment
Share on other sites

  • 0

Начнем с того, от чего именно мы хотим защититься. В данном случае, как я понимаю, от XSS?

Ну, допустим, от XSS. И от SQL инъекций.

 

По желанию можно взломать через Blind sql injection

простую sql injection

через mysql программы, способов моря..

 

Хочу тока сказать одно, если вы хотите что бы вас не сломали стан те сами хакером и пытайтесь ломать свой сайт, через что сломали то и прав те...

А вы сможете написать такую инъекцию, в которой не используются кавычки, которые экранирует эта функция?

Link to comment
Share on other sites

  • 0
И от SQL инъекций.

А какая связь между синтаксисом запросов SQL и кодированием спецсимволов в HTML?

 

такую инъекцию, в которой не используются кавычки

Да легко. Например, через параметры LIMIT-а (скажем, в пагинаторе).

 

Крайне рекомендую вот эту ссылку (включая эту презентацию по ссылке там внизу).

  • Like 1
Link to comment
Share on other sites

  • 0
А вы сможете написать такую инъекцию, в которой не используются кавычки, которые экранирует эта функция?

Теоретически двойное тире, с последующим пробелом закоментит весь далее следующий SQL-код, но это сработает только есть подделываемые данные на заключаются в кавычки в теле запроса(например тупо вставляют передаваемые числовые данные без их преобразования в int/float).

  • Like 1
Link to comment
Share on other sites

  • 0

 

И от SQL инъекций.

А какая связь между синтаксисом запросов SQL и кодированием спецсимволов в HTML?

Прямая. Попробуйте сделать SQL инъекцию 1) с помощью кавычек 2) с помощью группы символов: "

 

 

 

такую инъекцию, в которой не используются кавычки

Да легко. Например, через параметры LIMIT-а

Приведите пример, допустим, с таким запросом: SELECT * FROM `users` WHERE `login`="пользовательские данные".

Так? SELECT * FROM `users` WHERE `login`="LIMIT 0" :huh:

Link to comment
Share on other sites

  • 0
Прямая

Ну если у вас база используется только для вывода — тогда да, прямая (как одноименная кишка, которая тоже используется только для вывода:)). Но если вам понадобится в этой базе, например, название «ООО "ЫЫЫ"», или отсортировать поле с такими названиями — кодирование/раскодирование этих символов выльется в много лишних действий, доставляющих неудобства, сравнимые с болью в... ну вы поняли).

 

допустим, с таким запросом: SELECT * FROM `users` WHERE `login`="пользовательские данные".

Это у вас единственный запрос во всем приложении? Запросов вида SELECT * FROM `goods` ORDER BY `price` LIMIT $startFrom, 20 у вас точно нет? И никогда не будет? А сложных запросов с джойнами? А поисков с LIKE?

 

Нельзя считать подход, затыкающий проблему в одной частной задаче, решением проблемы вообще. Как не является решением «засобачивание» сообщения об ошибке в php.

 

Решение проблемы иньекций (и вообще надежности работы с базой) — соблюдение правил синтаксиса SQL (разных для данных и для команд). Символы ", равно как < и т.п., имеют к нему отношение чуть менее чем никакое.

  • Like 2
Link to comment
Share on other sites

  • 0

Прямая. Попробуйте сделать SQL инъекцию 1) с помощью кавычек 2) с помощью группы символов: "

Эээээ. Как бэ для записи в базу-то есть mysql_escape_string(), а htmlspecialchars() делается не перед записью в базу, а при выводе из неё в браузер.
Link to comment
Share on other sites

  • 0

 

Собственно, я в своих сайтах и сайтах заказчиков всегда обрабатываю пользовательские данные этой функцией. Но так ли уж она надежна? Неужели это простое превращение пары символов в спецсимволы может остановить любого, даже лучшего хакера?

Хотя, любой код можно взломать (даже восстановить пароль из md5 хэша), в данном случае имеет место быть паранойя.

 

Восстановить пароль из md5 хэша нереально, а вот сбрутить  реально, тока на это уйдет время, лучше использовать sha 1 + соль...

 

А по теме могут взломать путем заливкой shela

 

Через ошибку javascript

Эээээ. Как бэ для записи в базу-то есть mysql_escape_string(), а htmlspecialchars() делается не перед записью в базу, а при выводе из неё в браузер.

 

Поправлю htmlspecialchars() обрабатывает символы...

Edited by BSandro
Link to comment
Share on other sites

  • 0
обрабатывает символы...

Они обе «обрабатывают символы». Только разные символы, по-разному и для разных задач (одна — для подготовки данных к вставке в запрос, другая — для правильного отображения текста в браузере).

  • Like 1
Link to comment
Share on other sites

  • 0

Основное назначение функции htmlspecialchars - обработка сырых данных перед выводом пользователю. Считали сырые данные из базы, файла, входных параметров - перед выводом в html обрабатываем их htmlspecialchars, если не уверены, что считали готовый html. В базу можно (и нужно) смело писать без    htmlspecialchars почти всегда. Хранить в базе html обычно плохая идея.

  • Like 2
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. See more about our Guidelines and Privacy Policy