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

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

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

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

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

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

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

Моя обычная методика выбора выглядит примерно так:

• ПОЛУЧИТЬ для элементов, которые позже будут извлечен по URL
  • Например. Поиск должен быть GET, чтобы вы могли выполнить search.php? S = XXX позже.
• ПОЧТА для элементов, которые будут послал
  • Это невидимый относительно по сравнению с GET, и его сложнее отправить, но данные все равно можно отправлять через cURL.

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

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

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

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

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

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

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

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

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

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

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

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

Но ОБЯЗАТЕЛЬНО убедитесь, что методы GET не фиксируют никаких изменений, таких как удаление строк базы данных и т. д.

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

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

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

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

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

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

По сути, речь идет о веб-приложении, которое таинственным образом каждые несколько ночей теряло все свои данные, и никто не знал почему. Позже проверка журналов показала, что сайт был обнаружен Google или другим случайным пауком, который с радостью ПОЛУЧИЛ (читай: ПОЛУЧИТЬ) все ссылки, которые он нашел на сайте, включая «удалить эту запись» и «вы уверены?» ссылки.

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

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

2. БЕЗОПАСНОСТЬ как безопасность данных НА КОМПЬЮТЕРЕ: POST безопаснее (без истории URL)

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

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

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

• ОПЦИИ
• ПОЛУЧИТЬ
• ГОЛОВА
• ПОЧТА
• ПОМЕЩАТЬ
• УДАЛИТЬ
• СЛЕД
• СОЕДИНЯТЬ

Предположим, у вас есть следующий 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.
• Легко воспроизводится сторонними программами и ботами-скриптами.

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

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

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

Is one inherently more secure then another? I realize that POST doesn't expose information on the URL but is there any real value in that or is it just security through obscurity? What is the best practice here?

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

Over https, POST data is encoded, but could urls be sniffed by a 3rd party?

Вот как работает 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?`2o?O4G5D12Aovo?C@?/P/oOEQC5v?vai /%0Odo
QVw#6eoGXBF_o?/u0_F!_1a0A?Q b%TFyS@Or1SR/O/o/_@5o&_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/ x?B?oO@&
Pw?os9Od!c?/$3bWWeIrd_?( `P_C?7_g5O(ob(go?&/ooRxR'u/
T/yO3dS&??hIOB/?/OI?$oH2_?c_?OsD//0/_s%r

ПОЛУЧИТЬ через 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_/&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 является мерой безопасности? Защита от вашего ревнивого бывшего, пролистывающего историю вашего браузера. Вот и все. Остальной мир вошел в вашу учетную запись, смеясь над вами.

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

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

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

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

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

ПОЧТА - это противоположный, почти всегда не зарегистрирован, что приводит к тому, что активность злоумышленников очень трудно обнаружить.

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

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

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

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

К сожалению, так работают настоящие API.

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

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

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

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

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

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

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

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

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

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

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

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

RFC7231:

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

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

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

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

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

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

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

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

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

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

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

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

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

Но все эти методы небезопасны, потому что 7-битный протокол, который он использует под ним, можно взломать с помощью спуска. Даже через брандмауэр веб-приложений уровня 4.

Сокеты тоже не являются гарантией ... Хотя в некоторых отношениях это более безопасно.

Нет безопасности, если не используется https - а с https безопасность передачи одинакова для GET и POST.

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

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

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

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

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