GET或POST比另一个更安全吗？
将HTTP GET与HTTP POST进行比较时，从安全角度来看有什么区别？ 其中一个选择本质上比另一个更安全吗？ 如果是这样，为什么？
我意识到POST不公开URL上的信息，但是有没有真正的价值呢，还是仅仅因为默默无闻的安全？ 是否有任何理由让我在安全问题上更喜欢POST？
编辑：
通过HTTPS，POST数据被编码，但是第三方可能会嗅到URL？ 另外，我正在处理JSP; 当使用JSP或类似框架时，说最好的做法是避免将敏感数据放在POST或GET中，并使用服务器端代码来处理敏感信息，这是否公平？
就安全性而言，它们本质上是相同的。 虽然POST不通过URL公开信息，但它在客户端和服务器之间的实际网络通信中公开与GET相同的信息。 如果您需要传递敏感信息，您的第一道防线就是使用安全HTTP传递它。
GET或查询字符串帖子对于为特定商品添加书签所需的信息，或者用于协助搜索引擎优化和索引项目都非常有用。
POST适用于提交一次数据的标准表单。 我不会使用GET发布实际表单，除非在搜索表单中您希望允许用户将查询保存在书签中，或者沿着这些行。
GET请求的安全性比POST请求稍低。 它本身也不能提供真正的“安全”; 使用POST请求不会奇迹般地使您的网站安全防范恶意攻击。 但是，使用GET请求可能会使安全应用程序不安全。
您“不得使用GET请求进行更改”的口头禅仍然非常有效，但这与恶意行为无关。 登录表单是使用错误的请求类型发送的最敏感的表单。
搜索蜘蛛和网络加速器
这是您应该使用POST请求更改数据的真正原因。 搜索蜘蛛将遵循您网站上的每个链接，但不会提交他们发现的任意表单。
Web加速器比搜索蜘蛛更糟糕，因为它们在客户端的机器上运行，并在登录用户的上下文中“点击”所有链接。 因此，即使需要管理员，使用GET请求删除东西的应用程序也会高兴地服从（非恶意！）网络加速器的命令并删除它看到的所有内容。
混淆副攻击
无论您使用GET还是POST请求，都可能发生混淆的副攻击（代理是浏览器）。
在攻击者控制的网站上，GET和POST同样很容易在没有用户交互的情况下提交。
POST稍微不太敏感的唯一场景是许多不受攻击者控制的网站（比如第三方论坛）允许嵌入任意图像（允许攻击者注入任意的GET请求），但是阻止所有注入任意POST请求的方式，无论是自动还是手动。
有人可能会争辩说，网络加速器是混淆副攻击的一个例子，但这只是一个定义问题。 如果有的话，恶意攻击者无法控制这一点，所以即使代理人感到困惑，也不会发生攻击。
代理日志
代理服务器可能会完整记录GET URL，而不会剥离查询字符串。 POST请求参数通常不会被记录。 在任何情况下都不可能记录Cookie。 （例）
这是一个支持POST的非常弱的理由。 首先，未加密的流量可以完整记录; 恶意代理已经拥有了它所需要的一切。 其次，请求参数对攻击者的使用有限：他们真正需要的是cookie，因此如果他们唯一拥有的是代理日志，他们不太可能攻击GET或POST URL。
登录请求有一个例外：这些例程往往包含用户的密码。 将其保存在代理日志中会打开一个在POST情况下不存在的攻击向量。 然而，通过普通HTTP进行登录本质上是不安全的。
代理缓存
缓存代理可能保留GET响应，但不保留POST响应。 话虽如此，GET的反应可以做成不可缓存的，但比将URL转换为POST处理程序省力。
HTTP“Referer”
如果用户从响应GET请求的页面导航到第三方网站，该第三方网站会查看所有GET请求参数。
属于“向第三方披露请求参数”的类别，其严重性取决于这些参数中存在的内容。 POST请求自然不受此限制，但是要利用GET请求，黑客需要在自己的网站中插入链接到服务器的响应中。
浏览器历史
这与“代理日志”参数非常相似：GET请求与其参数一起存储在浏览器历史记录中。 如果攻击者能够物理访问机器，攻击者可以轻松获得这些信息。
浏览器刷新操作
只要用户点击“刷新”，浏览器就会重试GET请求。 它可能会在关闭后恢复标签页时执行此操作。 任何行为（比如支付）都会在没有任何警告的情况下重复。
浏览器不会在没有警告的情况下重试POST请求。
这是仅使用POST请求来更改数据的好理由，但与恶意行为以及安全性无关。
所以我该怎么做？
通过HTTPS，POST数据被编码，但是第三方可能会嗅到URL？
不，他们不能被嗅到。 但是这些URL将被存储在浏览器历史记录中。
最好的做法是避免将敏感数据放在POST或GET中，并使用服务器端代码来处理敏感信息，这是否公平？
取决于它的敏感程度，或者更具体地说，以何种方式。 客户很明显会看到它。 任何有权访问客户计算机的人都会看到它。 当客户发回给你时，它可以欺骗它。 如果那些问题是肯定的，请将敏感数据保存在服务器上，并且不要让它离开。
您没有提供更高的安全性，因为这些变量是通过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请求如下：
许多浏览器不支持除POST / GET以外的HTTP方法。
许多浏览器行为存储页面地址，但这并不意味着您可以忽略任何其他问题。
具体来说：
那么另一个本质上更安全吗？ 我意识到POST不公开URL上的信息，但是有没有真正的价值，还是仅仅是通过默默无闻的安全性？ 这里最好的做法是什么？
这是正确的，因为你用来说HTTP的软件倾向于用一种方法存储请求变量，而不是另一种只能阻止某人查看你的浏览器历史或来自10岁认为他们理解h4x0r1ng的其他天真攻击，或检查您的历史商店的脚本。 如果你有一个可以检查你的历史存储的脚本，你可以很容易地检查你的网络流量，所以通过默默无闻的整个安全性只是提供默默无闻的脚本小子和嫉妒的女朋友。
通过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 GET
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的保护，攻击者仍然可以使用受害者证书执行操作。 攻击者无法看到服务器的响应，因为它会被传输到受害者的浏览器，但通常在那个时候已经完成了破坏。
链接地址: http://www.djcxy.com/p/21587.html