GET或POST是否比另一种安全？

282

将HTTP GET与HTTP POST进行比较时，从安全角度来看有什么区别？这些选择中的一种在本质上比另一种更安全吗？如果是这样，为什么？

我意识到POST不会在URL上公开信息，但是其中有任何真正的价值还是仅仅是通过隐蔽性实现安全性？当出于安全考虑时，是否有理由我应该选择POST？

编辑：
通过HTTPS，对POST数据进行了编码，但是URL是否可以被第三方监听？另外，我正在处理JSP；当使用JSP或类似框架时，可以公平地说，最佳实践是避免将敏感数据完全放在POST或GET中，而使用服务器端代码来处理敏感信息吗？

html  security  http 
— James McMahon
source
1
Jeff的博客Coding Horror：Cross-Site Request Forgeries and You上有一篇不错的博客文章。
— FHE
您不会在大多数情况下使用POST。例如，对于一个API，说您需要从数据库中获取数据，但是在服务器返回数据之前，您必须首先进行身份验证吗？使用post，您只需传递会话ID +请求所需的所有参数。如果为此使用了GET req，则可以在浏览器历史记录或中间位置轻松找到会话ID。
— James111
我记得这场讨论是从战前（99或00左右）开始的，当时HTTP并不流行。
— David Tonhofer
@DavidTonhofer，您指的是哪一场战争？浏览器大战？
— DeltaFlyer
@DeltaFlyer不，关于物的永远战争，又名GWOT。我们做了什么。
— David Tonhofer，

Answers:

205

就安全性而言，它们本质上是相同的。的确POST不会通过URL公开信息，但是它在客户机与服务器之间的实际网络通信中公开的信息与GET一样多。如果您需要传递敏感信息，那么第一道防线就是使用安全HTTP传递信息。

GET或查询字符串文章对于将特定项目添加书签或协助搜索引擎优化和建立索引所需的信息确实非常有用。

POST适用于用于提交一次数据的标准表格。我不会使用GET来发布实际的表单，除非在搜索表单中您希望允许用户将查询保存在书签中，或者类似的方式。

— 斯蒂芬拜尔
source
5
需要注意的是，对于GET，在位置栏中显示的URL可以公开将隐藏在POST中的数据。
— tvanfosson
93
仅在最幼稚的意义上隐藏了它
— davetron5000
7
是的，但是您也可以说键盘是不安全的，因为在您输入密码时可能有人抬头看着您。默默无闻的安全性与根本没有安全性之间几乎没有区别。
— stephenbayer
65
URL中查询字符串的可见性（和缓存）以及地址框的安全性显然较差。没有绝对的安全性，因此安全程度是相关的。
— pbreitenbach
6
如果您使用信息，甚至会暴露出来。就您而言，该帖子会更加安全。但是认真的..我可以整天更改post变量，就像获取变量一样容易。Cookies甚至可以查看和修改。.永远不要依赖您的网站以任何形式发送的信息。您需要的安全性越高，应采用的验证方法就越多。
— stephenbayer 2010年
427

GET请求的安全性比POST请求低。两者都不提供真正的“安全性”。使用POST请求不会神奇地使您的网站免受恶意攻击的威胁。但是，使用GET请求可以使原本安全的应用程序是不安全的。

您“不得使用GET请求进行更改”的口号仍然非常有效，但这与恶意行为无关。登录表单是最敏感使用错误的请求类型发送的表单。

搜索蜘蛛和网络加速器

这是您应该使用POST请求更改数据的真正原因。搜索蜘蛛将跟踪您网站上的每个链接，但不会提交他们找到的随机表格。

Web加速器比搜索蜘蛛差，因为它们在客户端计算机上运行，​​并在登录用户的上下文中 “单击”所有链接。因此，使用GET请求删除内容的应用程序即使需要管理员，也会很乐意服从（非恶意！）Web加速器的命令并删除其看到的所有内容。

困惑的副手攻击

一个困惑副攻击（其中副是浏览器）是不管你是否使用GET或POST请求可能。

在不受用户干预的情况下，在攻击者控制的网站上GET和POST 同样容易提交 。

POST不太容易受到影响的唯一情况是，许多不受攻击者控制的网站（例如，第三方论坛）允许嵌入任意图像（允许攻击者注入任意GET请求），但阻止所有注入任意POST请求的方式，无论是自动还是手动。

有人可能会争辩说，Web加速器是混淆的副手攻击的一个例子，但这只是定义问题。如果有的话，恶意攻击者对此拥有没有控制权，所以这是很难的攻击，即使副被混淆。

代理日志

代理服务器很可能会完整记录GET URL，而不会剥离查询字符串。POST请求参数通常不会记录。无论哪种情况，都不太可能记录Cookie。（例）

这是支持POST的非常微弱的论据。首先，未加密的流量可以完整记录。恶意代理已经拥有所需的一切。其次，请求参数对攻击者的使用是有限的：它们真正需要的是cookie，因此，如果它们仅有的是代理日志，则它们不太可能攻击GET或POST URL。

登录请求有一个例外：它们通常包含用户的密码。将其保存在代理日志中会打开一个攻击媒介，而在POST情况下是不存在的。但是，无论如何，通过纯HTTP登录本质上是不安全的。

代理缓存

缓存代理可能保留GET响应，但不保留POST响应。话虽这么说，与将URL转换为POST处理程序相比，可以更轻松地使GET响应不可缓存。

HTTP“推荐人”

如果用户要从响应GET请求的页面中导航到第三方网站，则该第三方网站可以查看所有GET请求参数。

属于“向第三方显示请求参数”类别，其严重性取决于这些参数中存在的内容。POST请求自然不受此影响，但是，要利用GET请求，黑客需要在服务器的响应中插入指向自己网站的链接。

浏览器历史

这与“代理日志”参数非常相似：GET请求连同其参数一起存储在浏览器历史记录中。如果攻击者可以物理访问计算机，则攻击者可以轻松获取它们。

浏览器刷新动作

用户单击“刷新”后，浏览器将重试GET请求。在关闭后恢复选项卡时，可能会这样做。因此，任何动作（例如付款）都会在没有警告的情况下重复进行。

浏览器不会在没有警告的情况下重试POST请求。

这是仅使用POST请求来更改数据的良好理由，而与恶意行为以及安全性无关。

所以我该怎么做？

  • 主要出于与安全无关的原因，仅使用POST请求来更改数据。
  • 仅将POST请求用于登录表单；否则会引入攻击媒介。
  • 如果您的网站执行敏感操作，那么您确实需要知道他们在做什么的人，因为这不能在一个答案中涵盖。您需要使用HTTPS，HSTS，CSP，减轻SQL注入，脚本注入（XSS），CSRF以及大量特定于平台的其他功能（例如各种框架中的批量分配漏洞：ASP.NET MVC，Ruby on Rails等）。在“安全”（不可利用）和“不安全”之间没有任何区别。

通过HTTPS，可以对POST数据进行编码，但是URL是否可以被第三方监听？

不，他们不能被嗅探。但是，URL将存储在浏览器历史记录中。

公平地说，最佳实践是避免将敏感数据完全放在POST或GET中，而是使用服务器端代码来处理敏感信息吗？

取决于它的敏感程度，或更具体地说，以何种方式。显然，客户会看到它。可以物理访问客户端计算机的任何人都可以看到它。客户端可以在将其发送回给您时对其进行欺骗。如果那很重要，则将敏感数据保留在服务器上，不要让它离开。

— Roman Starkov
source
29
哎呀，CSRF尽可能与POST一起使用。
— AviD 2010年
5
@Lotus Notes，这有点困难，但是您不需要任何类型的XSS。POST请求一直在各地发送，不要忘了CSRF可以从任何网站获得，不包括XSS。
— AviD 2010年
18
不，您不必让其他人可以键入它，这与浏览器将以静默方式获取的GET相反。考虑到每个POST表单都应使用可验证的源哈希进行保护，并且对于GET链接没有这样的手段，您的观点很愚蠢。
— kibitzer 2011年
7
好吧，您可以将散列添加到所有GET请求中，就像将它们添加到POST表单中一样...但是，对于修改数据的任何内容，您仍不应使用GET。
— 伊莱
13
在GET上使用POST不会阻止任何CSRF。它只是使他们的操作稍微容易一些，因为它使人们更容易进入一个允许查看来自url图像的随机网站，而不是进入您可以控制的网站（足够使用javascript）。这样做<body onload="document.getElementById('a').submit()"><form id="a" action="http://example.com/delete.php" action="post"><input type="hidden" name="id" value="12"></form>是不是真的那么难通过单击链接自动某处提交后（包含HTML）
— FryGuy
175

您没有提供更高的安全性，因为通过HTTP POST发送的变量比通过HTTP GET发送的变量要高。

HTTP / 1.1为我们提供了一堆发送请求的方法：

  • 选项
  • 得到
  • 头
  • 开机自检
  • 放
  • 删除
  • 跟踪
  • 连接

让我们假设您具有使用GET的以下HTML文档：

<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攻击。
  • 第三方和脚本机器人很容易复制。

除POST / GET外，许多浏览器不支持HTTP方法。

许多浏览器行为都会存储页面地址，但这并不意味着您可以忽略任何其他这些问题。

所以具体来说：

一个天生比另一个更安全吗？我意识到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/?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这样的软件如何存在？

请注意，即使您使用HTTPS，并且您的站点不包含XSS漏洞，您也可能会受到CSRF的攻击。简而言之，此攻击情形假定受害者（您的站点或服务的用户）已经登录并且具有正确的cookie，然后要求受害者的浏览器对您的（应该是安全的）站点执行某些操作。如果您没有针对CSRF的防护，攻击者仍然可以使用受害者凭证执行操作。攻击者无法看到服务器的响应，因为它将被转移到受害者的浏览器中，但是通常情况下已经造成了损害。

— 隐身
source
1
可惜您没有谈论CSRF :-)。有什么联系方式吗？
— Florian Margaine 2012年
@FlorianMargaine在Twitter上添加我，我会给您DM我的电子邮件。twitter.com/#!/BrianJGraham
— 隐身时间：
谁说Facebook是安全的？很好的答案。+1。
— Amal Murali13年
1
“ [...]因此，通过默默无闻的整个安全性只能使脚本小子和嫉妒的女友默默无闻。[...]” 这完全取决于嫉妒的gf的技能。此外，不允许gf / bf访问您的浏览器历史记录。曾经。大声笑。
— turkishweb
34

没有增加的安全性。

发布数据未显示在历史记录和/或日志文件中，但是如果应确保数据安全，则需要SSL。
否则，任何嗅探导线的人都可以读取您的数据。

— 雅科
source
2
如果您通过SSL获取URL，则第三方将无法看到该URL，因此安全性是相同的
— davetron5000
7
GET信息只能在SSL隧道的开始和结束处看到
— -Jacco，
1
当sys管理员通过日志文件进行grep操作时。
— Tomalak
1
我要说的是，由于POST数据不会存储在用户的浏览器历史记录中，所以会增加一些安全性，但是GET数据会存储。
— 基普（Kip）
3
借助SSL / TLS的HTTP（正确实现），攻击者可以嗅探（或主动篡改）仅看到两件事-目标IP地址和双向数据量。
— 亚伦
29

对于登录表单或任何其他具有相对敏感信息的表单，即使POST与相比并没有带来真正的安全优势GET，也请确保您使用的POST身份是：

  1. 信息POSTed将不会保存在用户的历史记录中。
  2. 表单中发送的敏感信息（密码等）以后在URL栏中将不可见（通过使用GET，它将在历史记录和URL栏中可见）。

而且，GET对数据有理论上的限制。POST不。

有关真实的敏感信息，请确保使用SSL（HTTPS）

— 安德鲁·摩尔
source
在默认设置中，每次我在firefox / IE中输入用户名和密码时，它都会询问我是否要保存此信息，特别是这样，以后就不必键入它。
— Kibbee
安德鲁，我认为他的意思是在用户输入字段上自动完成。例如，Firefox会记住我在网站中输入的所有数据，因此，当我开始在搜索框中键入文本时，它将提供使用以前的搜索来完成文本的功能。
— James McMahon
是的，这就是自动完成的重点，不是吗。我的意思是实际的历史记录，而不是自动完成的记录。
— 安德鲁·摩尔
如果攻击者可以访问完整的浏览器历史记录，那么他也可以访问完整的浏览器自动完成数据。
— Mikko Rantalainen
19

GET和POST中的任何一个都不比另一个固有地“更安全”，就像传真和电话中的任何一个都不比另一个更“安全”。提供了各种HTTP方法，因此您可以选择一种最适合您要解决的问题的方法。GET更适合幂等查询，而POST更适合“动作”查询，但是如果您不了解要维护的应用程序的安全体系结构，则可以轻松地与其中任何一个脚步。

最好阅读第9章：HTTP / 1.1 RFC的方法定义，以全面了解GET和POST最初的含义。

— Mihai Limbășan
source
16

GET和POST之间的区别不应该从安全性角度考虑，而应从它们对服务器的意图来看。GET永远不要更改服务器上的数据-至少不更改日志中的数据-但POST可以创建新资源。

好的代理不会缓存POST数据，但是它们可以缓存URL的GET数据，因此您可以说POST应该更安全。但是POST数据仍可用于性能不佳的代理。

如许多答案中所述，唯一确定的选择是通过SSL。

但是一定要确保GET方法不会提交任何更改，例如删除数据库行等。

— 鲁基
source
1
我同意这一点。问题不是安全性，而是POST和GET的目的。
— pbreitenbach
6

我通常的选择方法是：

  • GET稍后将通过URL 检索的项目
    • 例如，搜索应为GET，以便稍后可以执行search.php？s = XXX
  • POST将要发送的项目
    • 这与GET 相对不可见，并且比较难发送，但是仍然可以通过cURL发送数据。
— 罗斯
source
但它是很难做一个POST比GET。GET只是地址框中的URL。POST需要在HTML页面或cURL中使用<form>。
— pbreitenbach
2
因此，虚假帖子需要记事本和5分钟的时间……实际上并不难。我使用记事本向电话系统添加了不存在的功能。我能够为系统创建一个管理表单的副本，从而使我可以将命令分配给与卖方有关的“不可能”的按钮。
— Matthew Whited
6

两者都没有神奇地赋予请求安全性，但是GET隐含了一些通常会阻止其安全性的副作用。

GET URL显示在浏览器历史记录和网络服务器日志中。因此，切勿将它们用于登录表单和信用卡号之类的东西。

但是，仅发布该数据也不能保证其安全性。为此，您需要SSL。通过HTTP使用时，GET和POST均以有线方式以纯文本形式发送数据。

POST数据还有其他很好的理由-例如提交无限数量的数据或对临时用户隐藏参数的功能。

缺点是用户无法为通过POST发送的查询结果添加书签。为此，您需要GET。

— 埃德比尔
source
5

考虑这种情况：松散的API接受GET请求，例如：

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

在某些设置中，当您请求此URL时，如果对该请求有错误/警告，则整行将记录在日志文件中。更糟糕的是：如果您忘记在生产服务器中禁用错误​​消息，则此信息仅在浏览器中以纯文本显示！现在，您已经将API密钥提供给了所有人。

不幸的是，真正的API是以这种方式工作的。

我不希望在日志中包含一些敏感信息或在浏览器中显示它们。POST和GET不一样。在适当的地方使用每个。

— 哈利尔·厄兹古尔（HalilÖzgür）
source
3

  1. 安全性是数据在传输中的安全性：POST和GET之间没有区别。

  2. 作为计算机上数据安全的安全性：POST更安全（无URL历史记录）

— 克什米尔人
source
2

除非您定义要防止的安全性，否则安全性概念毫无意义。

如果您想防止存储的浏览器历史记录，某些类型的日志记录以及查看您的URL的人的安全，则POST更安全。

如果您想防止有人嗅探您的网络活动，则没有任何区别。

— 泰蒙
source
1

许多人采用了一个约定（罗斯所禁止的约定），即GET请求仅检索数据，而不修改服务器上的任何数据，而POST请求用于所有数据修改。虽然一个是不固有的安全性比其他的，如果你做到遵守这个约定，你可以申请跨部门的安全逻辑（例如仅拥有帐户可以修改数据，因此未经验证的职位是拒绝）。

— 埃里克·R·拉斯
source
4
实际上，这不是“约定”，而是HTTP标准的一部分。RFC对于不同方法的预期非常明确。
— John Nilsson
实际上，如果您允许GET请求修改状态，则可能是浏览器在预装它认为您可能访问过的页面时会意外地执行您不希望其执行的操作。
— Jessta 2011年
1

更改POST请求比较困难（比编辑查询字符串需要更多的精力）。编辑：换句话说，这只是出于默默无闻的安全，而几乎没有。

— 失眼
source
3
我可以使用一些Firefox附加组件来更改POST请求，就像查询字符串请求一样容易。我什至可以修改cookie数据以适应我的内心需求。
— stephenbayer
它不会减慢脚本小子的运行速度，这恰恰是脚本小子一直尝试的事情。问题在于它们有时会成功。
— 雅科（Jacco）
2
嗯 在Firefox中使用附加组件=比查询字符串花费更多的精力。
— 2008年
您的回答会使人误以为他们在使用帖子时会更安全，而实际上却并非如此。错误的答案，坏人。
— 克里斯·玛拉斯蒂·乔治
我进行了编辑，以使答案的意图更加明确。希望有帮助。
— 2008年
1

我不会重复所有其他答案，但是有一个我尚未提及的方面-这是数据消失的故事。我不知道在哪里找到，但是...

基本上，它是关于一个Web应用程序，每隔几个晚上就会神秘地释放所有数据，而没人知道为什么。后来检查日志发现，该网站是由google或其他任意蜘蛛找到的，它很高兴GET（读取：GOT）它在该网站上找到的所有链接-包括“删除此条目”和“您确定吗？” 链接。

实际上-已经提到了其中的一部分。这就是“不要在GET上更改数据，而只能在POST上更改数据”背后的故事。抓取者会很乐意遵循GET，而不是POST。甚至robots.txt也无助于防止抓取工具行为异常。

— 奥拉夫·科克（Olaf Kock）
source
1

您还应该注意，如果您的站点包含指向其他外部站点的链接，那么您在使用GET将该站点中的链接添加到外部站点的Refererer标头中时，该数据将被放置在该站点中。因此，通过GET方法传输登录数据始终是一个大问题。因为那样可以通过仅查看日志或查看Google Analytics（分析）（或类似数据）来公开登录凭据，以便于访问。

— 3cho
source
1

RFC7231：

即使在URI标识安全资源的情况下，它们也希望被共享而不是安全的。URI通常显示在显示器上，在打印页面时将其添加到模板中，并存储在各种不受保护的书签列表中。因此，不明智地包括URI中的敏感信息，个人身份信息或存在泄露风险的信息。

服务的作者应避免基于GET的表单提交敏感数据，因为该数据将被放置在请求目标中。许多现有的服务器，代理和用户代理会在第三方可能可见的地方记录或显示请求目标。这些服务应改为使用基于POST的表单提交。”

该RFC明确规定，不应使用GET提交敏感数据。因此，某些实现者可能不会同样谨慎地处理从GET请求的查询部分获得的数据。我自己正在研究一种确保数据完整性的协议。根据此规范，我不必保证GET数据的完整性（因为没有人遵守这些规范，所以我会这样做）

— 银
source
1

就像以前有人说的那样，HTTPS带来了安全性。

但是，POST比GET安全一些，因为GET可以存储在历史记录中。

但是，更不幸的是，有时POST或GET的选择不取决于开发人员。例如，超链接始终由GET发送（除非使用javascript将其转换为帖子形式）。

— 马加拉内斯
source
0

GET对任何人都是可见的（甚至现在就在您的肩膀上），并且保存在缓存中，因此不确定使用post的安全性，不确定没有某些加密例程的btw post，出于安全考虑，您必须使用SSL（ https）

— 健太浦
source
0

POST的安全性较差的一个原因是，默认情况下记录GET，参数和所有数据几乎都由您的Web服务器记录。

POST是相反的，它几乎普遍不记录，导致很难发现攻击者的活动。

我不赞成“它太大”的说法，这也就没有理由不记录任何东西，至少1KB，对于人们识别攻击者在弱的入口点工作直到它弹出之前，将有很长的路要走。通过启用任何基于HTTP的后门以静默方式传递无限量的数据，从而实现双重保护。

— 随机NickName42
source
0

区别在于GET发送的数据处于打开状态，而POST则处于隐藏状态（位于http标头中）。

因此，对于非安全数据（例如Google中的查询字符串），get会更好。身份验证数据绝不能通过GET发送-因此请在此处使用POST。当然，整个主题要复杂一些。如果您想了解更多信息，请阅读这篇文章（德语）。

— 丹尼尔
source
0

最近发布了一种攻击，该攻击允许一个中间人泄露被压缩HTTPS请求的请求主体。由于HTTP不会压缩请求标头和URL，因此可以更好地保护GET请求免受这种特殊攻击。

在某些模式下，GET请求也容易受到攻击，SPDY压缩请求标头，TLS还提供可选的（很少使用）压缩。在这些情况下，更容易防止攻击（浏览器供应商已提供了修复程序）。HTTP级别压缩是更基本的功能，供应商不太可能会禁用它。

这只是一个示例，显示了GET比POST更安全的情况，但我认为从这种攻击原因中选择GET而不是POST并不是一个好主意。攻击非常复杂，并且要求先决条件（攻击者必须能够控制部分请求内容）。在攻击可能有害的情况下，最好禁用HTTP压缩。

— Jan Wrobel
source
0

免责声明：以下几点仅适用于API调用，不适用于网站URL。

网络安全性：您必须使用HTTPS。在这种情况下，GET和POST同样安全。

浏览器历史记录：对于Angular JS，React JS等前端应用程序，API调用是由前端进行的AJAX调用。这些不会成为浏览器历史记录的一部分。因此，POST和GET同样安全。

服务器端日志：使用数据屏蔽和访问日志格式的写集，可以从request-URL隐藏所有或仅敏感数据。

浏览器控制台中的数据可见性：对于有恶意的人来说，查看POST数据和获取GET几乎一样。

因此，通过正确的日志记录做法，GET API与POST API一样安全。到处都遵循POST，迫使API定义不正确，应避免使用。

— 基绍硼酸盐
source
-2

与SSL一起安装，Post是最安全的，因为它在邮件正文中传输。

但是所有这些方法都是不安全的，因为在其下面使用的7位协议很容易被擒纵。即使通过4级Web应用程序防火墙。

套接字也不能保证...即使它在某些方面更安全。

— drtechno
source
-3

这是一篇旧文章，但我想反对一些答案。如果您要传输敏感数据，则需要使用SSL。如果您将SSL与GET参数一起使用（例如？userid = 123），则该数据将以纯文本格式发送！如果使用POST发送，则这些值将放入消息的加密主体中，因此对于大多数MITM攻击都不可读。

最大的区别是数据传递的位置。唯一有意义的是，如果将数据放置在URL中，则不能对其进行加密，否则您将无法路由到服务器，因为只有您才能读取URL。这就是GET的工作方式。

简而言之，您可以通过SSL通过POST安全地传输数据，但不能通过GET（无论是否使用SSL）来传输数据。

— LVM
source
4
这是完全不正确的。SSL是传输层协议。它首先连接到服务器，然后将所有应用程序数据作为加密的二进制数据流发送。看看这个线程：answer.google.com/answers/threadview/id/758002.html
— Simeon G
做一个TCPDump，您会发现这是100％正确的。为了连接到服务器，您必须发送未加密的请求。如果您以GET身份进行操作，则您的args将添加到初始请求中，因此不会被加密。无论您在链接的文章中看到什么，都可以使用TCPDump（或类似工具）对其进行测试。
— LVM 2012年
1
做完了！只需在Mac上运行tcpdump。而您的答案却是100％错误。这是我使用的命令：sudo tcpdump -w ssl.data -A -i en1 -n dst端口443然后当我查看ssl.data时，我当然看到了gobly gook。所有HTTP数据均已加密。为了确保正常的非ssl调用正常工作，我使用了：sudo tcpdump -w clear.data -A -i en1 -n dst port 80可以肯定的是，在clear.data内部，所有标头和URI都以明文形式显示。我在gmail和google plus（即HTTPS）以及某些非SSL页面（例如google.com）上对此进行了测试。
— Simeon G
我不是网络专家，所以如果您认为我在tcpdump上使用了错误的命令，请随时纠正我。
— Simeon G
我没有立即可用的命令，但是您也可以使用Wireshark / Ethereal进行检查。
— LVM 2012年
-3

甚至POST也接受GET请求。假设您有一个表单，其中包含诸如user.name和user.passwd之类的输入，这些输入应该支持用户名和密码。如果我们仅添加？user.name =“ my user＆user.passwd =” my password“，则将通过“绕过登录页面”来接受请求。

一种解决方案是在服务器端实现过滤器（java过滤器为e），并且不检测任何字符串查询作为GET参数传递。

— 佩剑
source
2
不对！关于接受POST的代码是否也接受GET，这完全取决于您的后端。
— 科林·哈特
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.