当比较HTTP GET和HTTP POST时，从安全角度看有什么不同?其中一个选择是否天生就比另一个更安全?如果有，为什么?
我意识到POST没有公开URL上的信息，但其中有任何真正的价值吗?或者它只是通过隐匿性来实现安全?当安全性是一个问题时，我是否有理由更喜欢POST ?
编辑: 通过HTTPS, POST数据被编码，但url会被第三方嗅探吗?此外，我正在处理JSP;当使用JSP或类似的框架时，是否可以公平地说，最佳实践是避免将敏感数据完全放在POST或GET中，而是使用服务器端代码来处理敏感信息?
当前回答
安全如同数据传输中的安全:POST和GET之间没有区别。 安全性与计算机上的数据安全一样:POST更安全(没有URL历史)
其他回答
没有额外的安全性。
Post数据不会显示在历史和/或日志文件中，但如果数据应该保持安全，则需要SSL。 否则，任何嗅探线路的人都可以读取数据。
GET请求的安全性略低于POST请求。两者本身都不能提供真正的“安全”;使用POST请求并不能神奇地使你的网站免受恶意攻击。但是，使用GET请求会使原本安全的应用程序变得不安全。
“不能使用GET请求进行更改”的咒语仍然非常有效，但这与恶意行为没有多大关系。登录表单对于使用错误的请求类型发送最为敏感。
搜索蜘蛛和网络加速器
这就是应该使用POST请求来更改数据的真正原因。搜索蜘蛛会跟踪你网站上的每个链接，但不会提交他们找到的随机表单。
Web加速器比搜索蜘蛛更糟糕，因为它们运行在客户端机器上，并且“点击”登录用户上下文中的所有链接。因此，使用GET请求删除内容的应用程序，即使它需要管理员，也会很高兴地服从(非恶意的!)web加速器的命令，删除它看到的所有内容。
混淆副攻
不管使用GET请求还是POST请求，都可能出现混淆代理攻击(代理是浏览器)。
在攻击者控制的网站上，GET和POST同样容易提交，无需用户交互。
POST不太容易受到影响的唯一情况是，许多不受攻击者控制的网站(比如第三方论坛)允许嵌入任意图像(允许攻击者注入任意GET请求)，但阻止所有方式注入任意POST请求，无论是自动还是手动。
有人可能会说，网络加速器是混淆代理攻击的一个例子，但这只是一个定义的问题。如果有的话，恶意攻击者无法控制这一点，所以即使副手感到困惑，这也很难说是攻击。
代理日志
代理服务器可能会完整地记录GET url，而不剥离查询字符串。POST请求参数通常不会被记录。在这两种情况下，cookie都不太可能被记录。(例子)
这是支持POST的一个非常薄弱的论点。首先，未加密的流量可以被完整地记录;恶意代理已经拥有了它所需要的一切。其次，请求参数对攻击者的用处有限:他们真正需要的是cookie，所以如果他们唯一拥有的是代理日志，他们就不太可能攻击GET或POST URL。
登录请求有一个例外:这些请求往往包含用户的密码。将此保存在代理日志中会打开一个在POST情况下不存在的攻击向量。然而，通过纯HTTP登录本身就是不安全的。
代理缓存
缓存代理可能会保留GET响应，但不会保留POST响应。话虽如此，GET响应可以变得不可缓存，而不是将URL转换为POST处理程序。
HTTP“推荐人”
如果用户从响应GET请求的页面导航到第三方网站，该第三方网站将看到所有GET请求参数。
属于“向第三方透露请求参数”的类别，其严重性取决于这些参数中包含的内容。POST请求自然不受此影响，但是要利用GET请求，黑客需要在服务器的响应中插入到他们自己网站的链接。
浏览器历史记录
这与“代理日志”参数非常相似:GET请求连同它们的参数一起存储在浏览器历史记录中。如果攻击者有物理访问机器的权限，他们可以很容易地获得这些信息。
浏览器刷新动作
一旦用户点击“刷新”，浏览器就会重新尝试GET请求。它可能在关闭后恢复选项卡时这样做。因此，任何行为(比如付款)都会在没有任何警告的情况下重复发生。
浏览器不会在没有警告的情况下重试POST请求。
这是只使用POST请求来更改数据的一个很好的理由，但与恶意行为无关，因此与安全性无关。
那我该怎么办呢?
Use only POST requests to change data, mainly for non-security-related reasons. Use only POST requests for login forms; doing otherwise introduces attack vectors. If your site performs sensitive operations, you really need someone who knows what they’re doing, because this can’t be covered in a single answer. You need to use HTTPS, HSTS, CSP, mitigate SQL injection, script injection (XSS), CSRF, and a gazillion of other things that may be specific to your platform (like the mass assignment vulnerability in various frameworks: ASP.NET MVC, Ruby on Rails, etc.). There is no single thing that will make the difference between "secure" (not exploitable) and "not secure".
通过HTTPS, POST数据被编码，但url会被第三方嗅探吗?
不，他们不能嗅。但url将存储在浏览器历史记录中。
是否可以公平地说，最佳实践是避免将敏感数据完全放在POST或GET中，而是使用服务器端代码来处理敏感信息?
这取决于它有多敏感，或者更具体地说，以何种方式敏感。显然客户会看到它。任何可以实际访问客户端计算机的人都可以看到它。客户端可以在发送回给您时欺骗它。如果这些很重要，那么是的，把敏感数据保存在服务器上，不要让它离开。
我通常的选择方法是:
GET用于稍后将通过URL检索的项 例如，搜索应该是GET，所以你可以做Search .php?s=XXX POST将被发送的项目 与GET相比，这是相对不可见的，并且更难发送，但数据仍然可以通过cURL发送。
免责声明:以下几点仅适用于API调用，不适用于网站url。
网络安全:必须使用HTTPS。在这种情况下，GET和POST同样安全。
浏览器历史记录:对于前端应用程序，如Angular JS, React JS等，API调用是前端进行的AJAX调用。这些不会成为浏览器历史的一部分。因此，POST和GET是同样安全的。
服务器端日志:通过使用写入数据屏蔽和访问日志格式，可以隐藏所有或仅从request-URL中隐藏敏感数据。
浏览器控制台中的数据可见性:对于怀有恶意的人来说，查看POST数据和查看GET数据几乎是一样的。
因此，通过正确的日志记录实践，GET API与POST API一样安全。在所有地方都使用POST，会强制执行糟糕的API定义，应该避免。
由于通过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攻击。 很容易被第三方复制，和脚本机器人。
许多浏览器不支持POST/GET以外的HTTP方法。
许多浏览器行为存储页面地址，但这并不意味着您可以忽略任何其他问题。
具体来说:
一种天生就比另一种更安全吗?我意识到POST不会暴露URL上的信息，但其中是否有任何真正的价值，或者它只是通过隐匿性来安全?这里的最佳实践是什么?
This is correct, because the software you're using to speak HTTP tends to store the request variables with one method but not another only prevents someone from looking at your browser history or some other naive attack from a 10 year old who thinks they understand h4x0r1ng, or scripts that check your history store. If you have a script that can check your history store, you could just as easily have one that checks your network traffic, so this entire security through obscurity is only providing obscurity to script kiddies and jealous girlfriends.
在https上，POST数据被编码，但url可能被第三方嗅探?
下面是SSL的工作原理。还记得我上面发送的两个请求吗?下面是它们在SSL中的样子: (我将页面更改为https://encrypted.google.com/，因为example.com在SSL上没有响应)。
通过SSL POST
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这样的软件是如何存在的呢?
Note that you may be attacked with CSRF even if you use HTTPS and your site does not contain XSS vulnerabilities. In short, this attack scenario assumes that the victim (the user of your site or service) is already logged in and has a proper cookie and then the victim's browser is requested to do something with your (supposedly secure) site. If you do not have protection against CSRF the attacker can still execute actions with the victims credentials. The attacker cannot see the server response because it will be transferred to the victim's browser but the damage is usually already done at that point.
