#php #mysql #security #xss #sql-injection
#php #mysql #Безопасность #xss #sql-инъекция
Вопрос:
Я просмотрел множество статей, чтобы найти простой список символов, которые могут ограничить ввод пользователем для защиты моего сайта от XSS и SQL-инъекций, но не смог найти какой-либо общий список как таковой.
Может ли кто-нибудь помочь мне, просто предоставив мне список безопасных или небезопасных символов в этом отношении? Я знаю, что это может зависеть от конкретного поля, но мне это нужно для текстового поля, где я хочу разрешить максимально возможные символы.
Комментарии:
1. спасибо всем за ваши ответы. итак, похоже, что мне придется немного подробнее изучить это, поскольку просто символы белого списка не помогут.
Ответ №1:
Подход «черного списка» чреват проблемами. Как для SQLi, так и для XSS важна проверка входных данных по белому списку, т. е. определите, что вы ожидаете, а не то, чего вы не ожидаете. Помните также, что пользовательский ввод — или «ненадежные данные» — поступает из многих мест: форм, строк запроса, заголовков, тегов ID3 и exif и т.д.
Для SQLi убедитесь, что вы всегда используете параметризованные инструкции SQL, обычно в форме параметров хранимой процедуры или любого приличного ORM. Также примените «принцип наименьших привилегий» и ограничьте ущерб, который может нанести учетная запись, подключающаяся к вашей базе данных. Подробнее о SQLi здесь:http://www.troyhunt.com/2010/05/owasp-top-10-for-net-developers-part-1.html
Что касается XSS, всегда кодируйте свои выходные данные и убедитесь, что вы кодируете их для соответствующего языка разметки, на котором они отображаются. Кодировка вывода для JavaScript отличается от HTML, который отличается от CSS. Не забывайте кодировать не только ответы, которые немедленно отражают ввод, но и ненадежные данные, хранящиеся в базе данных, которые могут содержать постоянную угрозу XSS. Подробнее обо всем этом здесь: http://www.troyhunt.com/2010/05/owasp-top-10-for-net-developers-part-2.html
Я знаю, что это немного выходит за рамки вашего первоначального вопроса, но я пытаюсь подчеркнуть, что допустимые символы — это лишь одна небольшая часть картины. Другие методы, упомянутые выше, возможно, более важны (но вы все равно должны использовать эти белые списки).
Комментарии:
1. спасибо за ваш ответ. итак, суть в том, что просто белого списка недостаточно. но что я хотел знать, так это то, существуют ли какие-либо символы, кроме буквенно-цифровых символов, которые никогда не используются ни в каких атаках. например, что, если я разрешу использовать только буквенно-цифровой текст с точкой (.) и запятой (,), позволит ли это кому-либо причинить какой-либо вред?
2. Есть ли какие-либо символы сегодня или будут ли какие-либо символы завтра? На сегодня взгляните на XSS-шпаргалку, и вы поймете, насколько обширными могут быть структуры атаки: ha.ckers.org/xss.html На завтра, ну, весь смысл в том, что мы не знаем. Постоянно появляются новые эксплойты, так что кто знает, какие нулевые дни там ожидают своего появления. Вот почему белый список так важен; даже если мы не думаем , что определенный символ может быть использован злонамеренно, со временем мы вполне можем оказаться неправы.
Ответ №2:
Фильтрация символов — это не то, как вы должны заботиться о безопасности. Чтобы предотвратить SQL-инъекцию, используйте подготовленные инструкции. Чтобы предотвратить XSS, вы должны экранировать весь пользовательский ввод должным образом
Комментарии:
1. спасибо за ваш ответ и ссылку, но я не хочу сейчас углубляться в вопросы безопасности, потому что у меня не так много времени 🙂 разве я не могу просто избегать определенных символов, которые, как известно, используются в таких атаках?
2. Я не рекомендую вам это делать, но если вы собираетесь обеспечивать безопасность с помощью фильтрации символов, то вам лучше внести их в белый список, чем в черный. Я недостаточно знаю ни о SQL-инъекции, ни о XSS, чтобы дать вам окончательный ответ относительно того, какие символы вам нужно запретить для обеспечения полной безопасности (и нет смысла запрещать какие-либо символы, если вас могут использовать другие), но запрет кавычек (как одинарных, так и двойных) и угловых скобок хорош для начала, хотя почти наверняка этого недостаточно.
3. Atul, если вы действительно хотите сократить путь, начните с параметризованного SQL (в любом случае, вы не должны делать это каким-либо другим способом) и кодирования вывода. Сделайте это правильно, и белый список не будет иметь большого значения (но вы должны это все равно реализовать). Внесение символов в черный список — скользкий путь, который почти всегда выполняется кропотливо и некачественно с ограниченной эффективностью.
Ответ №3:
Посмотрите на реализацию фильтрации xss в Drupal CMS. Функция имеет белый список, содержащий разрешенные HTML-теги, все остальное будет экранировано.