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

Ответ 1

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

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

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

Ответ 2

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

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

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

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

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

Запутанная депутатская атака

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

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

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

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

Прокси логи

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

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

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

Прокси кеш

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

HTTP "Referer"

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

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

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

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

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

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

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

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

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

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

По протоколу HTTPS данные POST кодируются, но могут ли сторонние пользователи прослушивать URL-адреса?

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

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

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

Ответ 3

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

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

• OPTIONS
• GET
• ГОЛОВКА
• POST
• PUT
• DELETE
• TRACE
• CONNECT

Предположим, у вас есть следующий 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:

 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-запросов:

• Не зашифровано
• В обоих примерах
• Могут быть подвергнуты проверке и подвержены атакам MITM.
• Легко воспроизводится сторонними и script ботами.

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

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

Так что конкретно:

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

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

Чем выше https, данные POST закодированы, но могут ли ссылки URL-адреса третьей стороной?

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

POST через SSL

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

GET через SSL

rV/O8ow1pc`?058/8OS_Qy/$7oSsU'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_/&[email protected] f $)/xvxfgO'[email protected]&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 - это мера безопасности? Защита от вашей ревнивой экс-пролистывания в истории вашего браузера. Это. Остальная часть мира войдет в ваш аккаунт, смеясь над вами.

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

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

Ответ 4

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

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

Ответ 5

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

• Информация POST ed не будет сохранена в истории пользователя.
• Информация о секретности (пароль и т.д.), отправленная в форме, не будет отображаться позже в строке URL (с помощью GET, она будет видна в истории и в строке URL).

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

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

Ответ 6

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

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

Ответ 7

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

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

Как упоминалось во многих ответах, единственная уверенная ставка - через SSL.

Но НЕ убедитесь, что методы GET не вносят никаких изменений, таких как удаление строк базы данных и т.д.

Ответ 8

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

• GET для элементов, которые будут извлечены позже по URL-адресу
  • например. Поиск должен быть GET, поэтому вы можете выполнить search.php? S = XXX позже
• POST для элементов, которые будут отправлены
  • Это относительно незаметно для GET и сложнее отправить, но данные все равно можно отправить через cURL.

Ответ 9

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

Ответ 10

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

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

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

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

Недостатком является то, что пользователи не могут добавлять в закладки результаты запроса, отправленного через POST. Для этого вам нужно ПОЛУЧИТЬ.

Ответ 11

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

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

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

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

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

Ответ 12

• БЕЗОПАСНОСТЬ как безопасность данных В ТРАНЗИТ: нет разницы между POST и GET.

• БЕЗОПАСНОСТЬ как безопасность данных на компьютере: POST более безопасен (нет истории URL)

Ответ 13

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

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

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

Ответ 14

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

Ответ 15

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

Ответ 16

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

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

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

Ответ 17

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

Ответ 18

RFC7231:

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

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

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

Ответ 19

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

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

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

Ответ 20

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

Ответ 21

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

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

Ответ 22

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

POST - это нечто противоположное, оно почти универсально не зарегистрировано, что приводит к очень сложной атаке.

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

Ответ 23

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

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

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

Ответ 24

Отказ от ответственности: Следующие пункты применимы только для вызовов API, а не URL-адресов веб-сайта.

Безопасность в сети: вы должны использовать HTTPS. GET и POST одинаково безопасны в этом случае.

История браузера. Для интерфейсных приложений, таких как Angular JS, React JS и т.д., Вызовы API - это вызовы AJAX, выполняемые интерфейсом. Они не становятся частью истории браузера. Следовательно, POST и GET одинаково безопасны.

Журналы на стороне сервера. С помощью набора записей для маскирования данных и формата журналов доступа можно скрыть все или только конфиденциальные данные из URL-адреса запроса.

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

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

Ответ 25

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

Большое различие заключается в том, где данные передаются. Имеет смысл только то, что если данные помещаются в URL-адрес, он НЕ МОЖЕТ быть зашифрован, иначе вы не сможете направить его на сервер, потому что только вы могли бы прочитать URL-адрес. Это как работает GET.

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

Ответ 26

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

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