HTMLSpecialChars

[iKNG]

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

[CoDy]

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

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

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

лучшего хакера

. Это мое исключительно субъективное мнение.

[iKNG]

 

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

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

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

 

лучшего хакера

. Это мое исключительно субъективное мнение.

 

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

[BSandro]

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

простую sql injection

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

 

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

[Radiocity]

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

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

[SelenIT]

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

[iKNG]

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

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

 

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

простую sql injection

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

 

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

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

[SelenIT]

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

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

 

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

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

 

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

[CoDy]

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

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

[Veseloff]

Используйте готовые фреймворки — в них уже встроена необходимая защита.

[iKNG]

 

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

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

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

 

 

 

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

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

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

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

[SelenIT]

Прямая

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

 

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

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

 

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

 

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

[Int]

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

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

[BSandro]

 

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

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

 

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

 

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

 

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

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

 

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

Edited November 21, 2013 by BSandro

[SelenIT]

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

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

[Great Rash]

iKNG, дружище, научись юзать PDO, там всё уже есть, никакие htmlspecialchars и mysql_escape_string будут не нужны.

[SelenIT]

никакие htmlspecialchars

Пардон! Как раз htmlspecialchars останется нужна по прямому назначению (напр. выводить текст из базы для редактирования в textarea).

[VolCh]

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