当比较HTTP GET和HTTP POST时，从安全角度看有什么不同?其中一个选择是否天生就比另一个更安全?如果有，为什么?
我意识到POST没有公开URL上的信息，但其中有任何真正的价值吗?或者它只是通过隐匿性来实现安全?当安全性是一个问题时，我是否有理由更喜欢POST ?
编辑: 通过HTTPS, POST数据被编码，但url会被第三方嗅探吗?此外，我正在处理JSP;当使用JSP或类似的框架时，是否可以公平地说，最佳实践是避免将敏感数据完全放在POST或GET中，而是使用服务器端代码来处理敏感信息?
当前回答
最近发布了一种攻击，它允许中间人泄露压缩HTTPS请求的请求体。由于请求头和URL没有被HTTP压缩，GET请求可以更好地防止这种特定的攻击。
在某些模式下，GET请求也容易受到攻击，SPDY压缩请求头，TLS也提供可选的(很少使用)压缩。在这些情况下，攻击更容易预防(浏览器供应商已经提供了修复程序)。HTTP级别的压缩是一个更基本的特性，供应商不太可能禁用它。
这只是一个示例，展示了GET比POST更安全的场景，但从这种攻击原因来看，我不认为选择GET而不是POST是一个好主意。这种攻击相当复杂，需要非常重要的先决条件(攻击者需要能够控制部分请求内容)。在攻击可能有害的情况下，最好禁用HTTP压缩。
其他回答
POST在安全性方面较差的一个原因是GET在默认情况下被记录，参数和所有数据几乎都被你的web服务器记录。
POST则相反，它几乎没有被记录，导致很难发现攻击者的活动。
我不相信“它太大了”的说法，这不是不记录任何东西的理由，至少1KB，这对人们识别攻击者很有帮助，直到它出现，然后POST做了双重破坏服务，通过启用任何基于HTTP的后门来无声地传递无限数量的数据。
区别在于GET发送数据是开放的，而POST是隐藏的(在http-header中)。
所以get更适合于不安全的数据，比如谷歌中的查询字符串。Auth-data永远不会通过GET发送，所以在这里使用POST。当然，整个主题有点复杂。如果你想阅读更多，请阅读这篇文章(德语)。
最近发布了一种攻击，它允许中间人泄露压缩HTTPS请求的请求体。由于请求头和URL没有被HTTP压缩，GET请求可以更好地防止这种特定的攻击。
在某些模式下，GET请求也容易受到攻击，SPDY压缩请求头，TLS也提供可选的(很少使用)压缩。在这些情况下，攻击更容易预防(浏览器供应商已经提供了修复程序)。HTTP级别的压缩是一个更基本的特性，供应商不太可能禁用它。
这只是一个示例，展示了GET比POST更安全的场景，但从这种攻击原因来看，我不认为选择GET而不是POST是一个好主意。这种攻击相当复杂，需要非常重要的先决条件(攻击者需要能够控制部分请求内容)。在攻击可能有害的情况下，最好禁用HTTP压缩。
许多人采用一种约定(Ross提到过)，即GET请求只检索数据，不修改服务器上的任何数据，而POST请求用于所有数据修改。虽然其中一种并不比另一种更安全，但如果你遵循这个约定，你可以应用横切安全逻辑(例如，只有拥有帐户的人才可以修改数据，因此未经身份验证的post将被拒绝)。
由于通过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.
