Является ли GET или POST более безопасным, чем другой?

при сравнении HTTP GET с HTTP POST, каковы различия с точки зрения безопасности? Является ли один из вариантов более безопасным, чем другой? Если так, то почему?

Я понимаю, что POST не предоставляет информацию по URL-адресу, но есть ли в этом какая-то реальная ценность или это просто безопасность через неизвестность? Есть ли причина, по которой я должен предпочесть пост, когда безопасность вызывает беспокойство?

Edit:
Через HTTPS данные POST кодируются, но может ли URL-адреса быть обнюханы третьей стороной? Кроме того, я имею дело с JSP; при использовании JSP или аналогичной структуры, было бы справедливо сказать, что лучшая практика заключается в том, чтобы избежать размещения конфиденциальных данных в сообщении или получить вообще и использовать код на стороне сервера для обработки конфиденциальной информации вместо этого?

25 ответов


Что касается безопасности, они по своей сути одинаковы. Хотя это правда, что POST не предоставляет информацию через URL, он предоставляет столько же информации, сколько GET в фактической сетевой связи между клиентом и сервером. Если вам нужно передать конфиденциальную информацию, вашей первой линией защиты будет передать ее с помощью защищенного HTTP.

сообщения GET или query string действительно хороши для информации, необходимой для закладки определенного элемента или для помощь в поисковой оптимизации и индексации элементов.

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


запрос GET несколько менее безопасен, чем запрос POST. Ни один из них не предлагает истинную "безопасность" сам по себе; используя POST requests не будет волшебным образом сделать ваш сайт безопасным от вредоносных атак на заметную сумму. Однако, используя GET requests can сделать в противном случае безопасное приложение небезопасным.

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

Поиск пауков и веб-ускорители

Это реальная причина, по которой вы должны использовать POST-запросы для изменения данных. Поисковые пауки будут следовать по каждой ссылке на вашем сайте, но не будут отправлять случайные формы, которые они находят.

веб-ускорители хуже, чем поисковые пауки, потому что они работают на машине клиента и "нажимают" все ссылки в контексте зарегистрированного пользователя. Таким образом, приложение, которое использует запрос GET для удаления материалов, даже если для этого требуется администратор, с радостью подчинится приказам (не злонамеренным!) веб-ускоритель и удалить все, что он видит.

смущенный заместитель атаки

A смущенная атака депутата (где депутат браузера)возможно независимо от того, используете ли вы GET или POST запрос.

на контролируемых злоумышленником веб-сайтах GET и POST являются одинаково легко представить без взаимодействия с пользователем.

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

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

логи прокси-сервера

прокси-серверы, скорее всего, будут регистрировать URL-адреса GET полностью, без удаления строки запроса. Параметры запроса POST обычно не отяжелевший. Cookies вряд ли будут зарегистрированы в любом случае. (пример)

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

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

Прокси-кэш

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

HTTP "Referer"

Если пользователь должен был перейти на сторонний веб-сайт со страницы, обслуживаемой в ответ на запрос GET, этот сторонний веб-сайт получает все параметры запроса GET.

относится к категории "раскрывает параметры запроса третьим лицам", тяжесть которого зависит от того, что присутствует в этих параметрах. Запросы POST естественно невосприимчивы к этому, однако для использования запроса GET хакеру нужно будет вставить ссылка на собственный сайт в ответе сервера.

история браузера

Это очень похоже на аргумент "proxy logs": GET-запросы хранятся в истории браузера вместе с их параметрами. Злоумышленник может легко получить их, если они имеют физический доступ к машине.

действие обновления браузера

браузер повторит запрос GET, как только пользователь нажмет "обновить". Это может сделать это при восстановлении вкладок после выключение. Любое действие (скажем, платеж), таким образом, будет повторено без предупреждения.

браузер не будет повторять запрос POST без предупреждения.

Это хорошая причина использовать только запросы POST для изменения данных, но не имеет ничего общего со злонамеренным поведением и, следовательно, безопасностью.

так что же мне делать?

  • используйте только запросы POST для изменения данных, в основном по причинам, не связанным с безопасностью.
  • использовать только запросы POST для форм входа в систему; в противном случае вводятся векторы атаки.
  • если ваш сайт выполняет конфиденциальные операции, вам действительно нужен кто-то, кто знает, что они делают, потому что это не может быть покрыто одним ответом. Вам нужно использовать HTTPS, HSTS, CSP, смягчить SQL-инъекцию,инъекция скрипта (XSS), CSRF в и множество других вещей, которые могут быть специфичны для вашей платформы (например, уязвимость массового назначения в различных фреймворках: ASP.NET MVC, Ruby на Rails, etc.). Нет ни одной вещи, которая будет делать разницу между "безопасным" (не эксплуатируемым) и "не безопасным".

через HTTPS данные POST кодируются, но могут ли URL-адреса быть обнюханы третьей стороной?

нет, их нельзя обнюхать. Но URL-адреса будут сохранены в истории браузера.

было бы справедливо сказать, что лучшая практика-избегать возможно размещение конфиденциальных данных в сообщении или получить вообще и использовать код на стороне сервера для обработки конфиденциальной информации?

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


у вас нет большей безопасности, потому что переменные отправляются по HTTP POST, чем у вас есть с переменными, отправленными по HTTP GET.

HTTP / 1.1 предоставляет нам кучу методов для отправки запроса:

  • опции
  • GET
  • глава
  • в должности
  • поставить
  • удалить
  • след
  • подключиться

предположим, у вас есть следующий HTML-документ с помощью GET:

<html>
<body>
<form action="http://example.com" method="get">
    User: <input type="text" name="username" /><br/>
    Password: <input type="password" name="password" /><br/>
    <input type="hidden" name="extra" value="lolcatz" />
    <input type="submit"/>
</form>
</body>
</html>

что спрашивает Ваш браузер? Он спрашивает:

 GET /?username=swordfish&password=hunter2&extra=lolcatz HTTP/1.1
 Host: example.com
 Connection: keep-alive
 Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/ [...truncated]
 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) [...truncated]
 Accept-Encoding: gzip,deflate,sdch
 Accept-Language: en-US,en;q=0.8
 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

теперь давайте притворимся, что мы изменили этот метод запроса на сообщение:

 POST / HTTP/1.1
 Host: example.com
 Connection: keep-alive
 Content-Length: 49
 Cache-Control: max-age=0
 Origin: null
 Content-Type: application/x-www-form-urlencoded
 Accept: application/xml,application/xhtml+xml,text/ [...truncated]
 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; [...truncated]
 Accept-Encoding: gzip,deflate,sdch
 Accept-Language: en-US,en;q=0.8
 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

 username=swordfish&password=hunter2&extra=lolcatz

и из этих HTTP-запросов:

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

много - браузеры не поддерживают методы HTTP, кроме POST / GET.

много - браузеры поведение хранит адрес страницы, но это не означает, что вы можете игнорировать любые из этих других проблем.

так, чтобы быть конкретными:

является ли один по своей сути более безопасным, чем другой? Я понимаю, что POST не предоставляет информацию по URL-адресу, но есть ли в этом какая-то реальная ценность или это просто безопасность через безвестность? Какая здесь лучшая практика?

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

через https данные POST кодируются, но могут ли URL-адреса быть обнюханы третьей стороной?

вот как работает SSL. Помните те две просьбы, что я послал выше? Вот как они выглядят в SSL: (Я изменил страницу на https://encrypted.google.com/ как example.com не отвечает на SSL).

пост через SSL

q5XQP%RWCd2u#o/T9oiOyR2_YO?yo/3#tR_G7 2_RO8w?FoaObi)
oXpB_y?oO4q?`2o?O4G5D12Aovo?C@?/P/oOEQC5v?vai /%0Odo
QVw#6eoGXBF_o?/u0_F!_1a0A?Q b%TFyS@Or1SR/O/o/_@5o&_o
9q1/?qyOAXOD5sc$H`BECo1w/`4?)f!%geOOF/!/#Of_f&AEI#
yvv/wu_b5?/o d9O?VOVOFHwRO/pO/OSv_/8/9o6b0FGOH61O?ti
/i7b?!_o8u%RS/Doai%/Be/d4sv_%YD2_/EOAO/C?vv/%X!T?R
_o_2yoBP)orw7H_yQsXOhoVUo49itare#cA?/c)I7R?YCsg ??c'
(_!(0u)o4eIis/S8Oo8_BDueC?1uUO%ooOI_o8WaoO/ x?B?oO@&
Pw?os9Od!c?/bWWeIrd_?( `P_C?7_g5O(ob(go?&/ooRxR'u/
T/yO3dS&??hIOB/?/OI?$oH2_?c_?OsD//0/_s%r

получить через SSL

rV/O8ow1pc`?058/8OS_Qy/oSsU'qoo#vCbOO`vt?yFo_?EYif)
43`I/WOP_8oH0%3OqP_h/cBO&24?'?o_4`scooPSOVWYSV?H?pV!i
?78cU!_b5h'/b2coWD?/43Tu?153pI/9?R8!_Od"(//O_a#t8x?__
bb3D?05Dh/PrS6_/&5p@V f $)/xvxfgO'q@y&e&S0rB3D/Y_/fO?
_'woRbOV?_!yxSOdwo1G1?8d_p?4fo81VS3sAOvO/Db/br)f4fOxt
_Qs3EO/?2O/TOo_8p82FOt/hO?X_P3o"OVQO_?Ww_dr"'DxHwo//P
oEfGtt/_o)5RgoGqui&AXEq/oXv&//?%/6_?/x_OTgOEE%v (u(?/
t7DX1O8oD?fVObiooi'8)so?o??`o"FyVOByY_ Supo? /'i?Oi"4
tr'9/o_7too7q?c2Pv

(Примечание: я преобразовал HEX в ASCII, некоторые из них, очевидно, не должны отображаться)

весь разговор HTTP зашифрован, единственная видимая часть связи находится на уровне TCP/IP (что означает IP-адрес и информацию о порте подключения).

поэтому позвольте мне сделать здесь большое смелое заявление. Ваш сайт не обеспечивает большую безопасность по одному методу HTTP, чем другой, хакеры и новички во всем мире точно знают, как делать то, что я только что продемонстрировал. Если вы хотите безопасности, используйте SSL. Браузеры, как правило, хранят историю, рекомендуется RFC2616 9.1.1 не использовать GET для выполнения действия, но думать, что POST обеспечивает безопасность, категорически неправильно.

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

чтобы еще раз продемонстрировать, почему POST не является безопасным, Facebook использует запросы POST повсюду, так как программное обеспечение, такое как FireSheep?

обратите внимание, что вы можете быть атакованы с CSRF в даже если вы используете HTTPS, и ваш сайт не содержит межсайтовый скриптинг уязвимостей. Короче говоря, этот сценарий атаки предполагает, что жертва (пользователь вашего сайта или службы) уже вошла в систему и имеет соответствующий файл cookie, а затем браузер жертвы просят сделать что-то с вашим (предположительно безопасным) сайтом. Если у вас нет защиты от CSRF, злоумышленник все равно может выполнять действия с учетными данными жертв. Злоумышленник не может увидеть ответ сервера, потому что он будет передан в браузер жертвы, но повреждение обычно уже сделано в этот момент.


нет дополнительной безопасности.

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


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

  1. информация POSTed не будет сохранен в истории пользователя.
  2. конфиденциальная информация (пароль и т. д.) отправленный в форме не будет отображаться позже в строке URL (с помощью GET, он будет виден в истории и URL бар.)

и GET имеет теоретический предел данных. POST нет.

для реальной конфиденциальной информации обязательно используйте SSL (HTTPS)


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

вероятно, лучше всего, если Вы читаете Глава 9: Определения Методов на HTTP / 1.1 RFC чтобы получить общее представление о том, что GET и POST изначально предполагалось OT.


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

хорошие прокси не будут кэшировать данные POST, но они могут кэшировать данные из URL-адреса, поэтому вы можете сказать, что POST должен быть более безопасным. Но данные POST по-прежнему будут доступны прокси, которые не играют хорошо.

As упомянутый во многих ответах, единственная верная ставка - через SSL.

но убедитесь, что методы GET не фиксируют никаких изменений, таких как удаление строк базы данных и т. д.


моя обычная методология выбора-это что-то вроде:

  • GET для элементов, которые будут извлечь позже по URL
    • например. Поиск должен быть GET, чтобы вы могли делать поиск.РНР?s=XXX позже
  • в должности для элементов, которые будут отправлено
    • Это относительно невидимая проблема получить и труднее отправить, но данные все еще могут быть отправлены через локон.

Это не связано с безопасностью, но... браузеры не кэшируют почтовые запросы.


ни один из них магически не обеспечивает безопасность запроса, однако GET подразумевает некоторые побочные эффекты, которые обычно предотвращают его безопасность.

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

однако, просто размещение этих данных также не делает его безопасным. Для этого вам нужен SSL. Как GET, так и POST отправляют данные в открытом виде по проводу при использовании HTTP.

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

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


рассмотрим эту ситуацию: небрежный API принимает запросы GET, такие как:

http://www.example.com/api?apikey=abcdef123456&action=deleteCategory&id=1

в некоторых настройках, когда вы запрашиваете этот URL и если есть ошибка / предупреждение относительно запроса, вся эта строка регистрируется в файле журнала. Хуже того: если вы забыли отключить сообщения об ошибках на рабочем сервере,эта информация просто отображается в браузере! Теперь вы просто отдали свой ключ API всем.

к сожалению, работают реальные API именно такой образ.

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


  1. безопасность как безопасность данных в пути: нет разницы между POST и GET.

  2. безопасность как безопасность данных на компьютере: сообщение безопаснее (нет истории URL)


понятие безопасности бессмысленно, если вы не определяете, от чего вы хотите быть в безопасности.

Если вы хотите быть в безопасности от сохраненной истории браузера, некоторых типов ведения журнала и людей, смотрящих на ваши URL-адреса, то POST более безопасен.

Если вы хотите быть защищены от кого-то нюхать вашу сетевую активность, то нет никакой разницы.


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


труднее изменить запрос POST (это требует больше усилий, чем редактирование строки запроса). изменить: другими словами, это только безопасность по неизвестности, и едва ли это.


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

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

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


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


RFC7231:

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

авторы услуг должны избегать GET-based форм для представления из конфиденциальные данные, поскольку эти данные будут помещены в запрос-цель. Журнал многих существующих серверов, прокси-серверов и агентов пользователей или отображать цель запроса в местах, где она может быть видна третьи страны. Таких услуг должны использовать POST-отправка форма вместо."

в этом RFC четко указано, что конфиденциальные данные не должны представляться с помощью GET. Из-за этого замечания некоторые исполнители могут не обрабатывать данные, полученные из части запроса GET с помощью та же забота. Я сам работаю над протоколом, который обеспечивает целостность данных. Согласно этой спецификации мне не нужно гарантировать целостность данных GET (что я и сделаю, потому что никто не придерживается этих спецификаций)


Как ранее говорили некоторые люди, HTTPS обеспечивает безопасность.

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

но еще больше, к сожалению, иногда выборы поста или получить не зависит от разработчика. Например, гиперссылка всегда отправляется GET (если она не преобразована в форму post с помощью javascript).


GET виден любому (даже тот, который сейчас на вашем плече) и сохраняется в кэше, поэтому менее безопасно использовать post, btw post без какой-либо криптографической процедуры не уверен, для Немного безопасности вы должны использовать SSL (https)


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

в должности - это напротив, это почти повсеместно не вошли, что приводит к очень трудно обнаружить активность злоумышленника.

Я не покупаю аргумент "это слишком большой", это не причина, чтобы не войти что-нибудь, по крайней мере 1Кб, пошел бы длинный путь для люди, чтобы идентифицировать злоумышленников, работающих в слабой точке входа, пока это pop, а затем POST делает двойной dis-сервис, позволяя любому http-бэк-двери молча передавать неограниченное количество данных.


разница в том, что GET отправляет данные открытыми и POST hidden (в http-заголовке).

Так что get лучше для небезопасных данных, таких как строки запросов в Google. Auth-данные никогда не будут отправляться через GET-so использовать POST здесь. Конечно, вся тема немного сложнее. Если вы хотите прочитать больше, прочитайте в этой статье (на немецком языке).


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

есть режимы в котором GET-запросы также уязвимы, SPDY сжимает заголовки запросов, TLS также предоставляет необязательное (редко используемое) сжатие. В этих сценариях атаку легче предотвратить (поставщики браузеров уже предоставили исправления). Сжатие уровня HTTP является более фундаментальной функцией, маловероятно, что поставщики отключат ее.

Это просто пример, который показывает сценарий, в котором GET более безопасен, чем POST, но я не думаю, что было бы хорошей идеей выбрать GET over POST из этой причины атаки. Атака довольно сложная и требует нетривиальных предварительных условий (злоумышленник должен иметь возможность контролировать часть содержимого запроса). Лучше отключить Сжатие HTTP в сценариях, где атака будет вредной.


Это старый пост, но я хотел бы возразить на некоторые ответы. Если вы передаете конфиденциальные данные, вы захотите использовать SSL. Если вы используете SSL с параметром GET (например ?userid=123), эти данные будут отправлены в виде обычного текста! Если вы отправляете сообщение, значения помещаются в зашифрованное тело сообщения и поэтому не читаются большинством атак MITM.

большое различие заключается в том, где передаются данные. Имеет смысл только, если данные помещены в URL-адрес, он не может быть зашифрован, иначе вы не сможете маршрутизировать на сервер, потому что только вы можете прочитать URL-адрес. Вот как работает GET.

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


даже POST принимает запросы GET. Предположим, у вас есть форма, имеющая входные данные, такие как user.имя и пользователь.passwd, они должны поддерживать имя пользователя и пароль. Если мы просто добавим a ?пользователь.name= " мой пользователь и пользователь.пароль="пароль", тогда запрос будет принят", минуя страницу входа в систему".

решение для этого заключается в реализации фильтров (Java filters как e) на стороне сервера и обнаружении, что никакие строковые запросы не передаются в качестве аргументов GET.