2> stephenbayer..：
就安全性而言,它们本质上是相同的.虽然POST不会通过URL公开信息,但它在客户端和服务器之间的实际网络通信中公开的信息与GET一样多.如果您需要传递敏感信息,您的第一道防线是使用安全HTTP传递它.
GET或查询字符串帖子非常适用于为特定项目添加书签或协助搜索引擎优化和索引项目所需的信息.
POST适用于用于提交一次性数据的标准表单.我不会使用GET发布实际表单,除非您希望允许用户将查询保存在书签中的搜索表单中,或者沿着这些行显示.
它只隐藏在最天真的意义上
URL中的查询字符串的可见性(和缓存)以及地址框明显*不太安全.没有绝对的安全性,所以安全程度是相关的.
是的,但你也可以说键盘是不安全的,因为当你输入密码时,有人可能会看着你的肩膀.通过默默无闻的安全性与完全没有安全性之间的差别很小.
如果你使用帖子,它甚至会暴露出来.在你的情况下,帖子会更安全一些.但是说真的..我可以整天改变post变量,就像获取变量一样简单.甚至可以查看和修改Cookie.永远不要依赖您网站以任何形式或形式发送的信息.您需要的安全性越高,您应该拥有的验证方法就越多.
需要注意的是,对于GET,位置栏中显示的URL可以显示将在POST中隐藏的数据.
@RocketR POST和GET只是动词,你可以在HTTP请求中应用一些动词.区别主要是语义.GET用于获取信息,而POST用于发送新信息,PUT用于更新信息.那就是设计理念,但人们会使用他们想要的任何动词.POST传输并不比GET更安全,它在不同的OSI层中处理安全性.认为GET和POST之间的安全性存在差异是危险的.
@Night Shade.如何在显示订单之前验证订单属于用户？如果用户"足够聪明"(阅读,如果他们可以安装任何允许你随意修改http请求的大量浏览器插件),POST不会给你买任何东西.
3> Incognito..：
您没有提供更高的安全性,因为变量是通过HTTP POST发送的,而不是通过HTTP GET发送的变量.
HTTP/1.1为我们提供了一堆发送请求的方法:
OPTIONS
得到
头
POST
放
删除
跟踪
CONNECT
让我们假设你有使用GET的以下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请求的两个是:
没有加密
包含在两个示例中
可以被evesdroped,并受到MITM攻击.
由第三方和脚本机器人轻松复制.
许多浏览器不支持POST/GET以外的HTTP方法.
许多浏览器行为存储页面地址,但这并不意味着您可以忽略任何其他问题.
所以具体来说:
一个人本来就比另一个人更安全吗？我意识到POST不会暴露关于URL的信息,但是它是否有任何实际价值,或者只是通过默默无闻的安全性？这里的最佳做法是什么？
这是正确的,因为您用来说HTTP的软件倾向于使用一种方法存储请求变量而不是另一种方法只会阻止某人查看您的浏览器历史记录或其他一些认为他们理解h4x0r1ng的10岁儿童的天真攻击或检查历史记录存储的脚本.如果你有一个可以检查你的历史存储的脚本,你可以很容易地检查你的网络流量,所以通过默默无闻的整个安全只是为脚本小子和嫉妒的女朋友提供默默无闻.
通过https,POST数据被编码,但可能被第三方嗅探？
以下是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的保护,攻击者仍然可以使用受害者凭据执行操作.攻击者无法看到服务器响应,因为它将被转移到受害者的浏览器,但损坏通常已经在那时完成.
4> Jacco..：
没有额外的安全性.
发布数据不会显示在历史记录和/或日志文件中,但如果数据应保持安全,则需要SSL.
否则,任何嗅探电线的人都可以读取您的数据.
GET信息只能在SSL隧道的开头和结尾看到
HTTP over SSL/TLS(正确实现)允许攻击者嗅探线路(或主动篡改)只能看到两件事 - 目的地的IP地址和双向数据量.
如果你通过SSL获取URL,第三方将无法看到URL,因此安全性是相同的
5> Andrew Moore..：
即使POST没有真正的安全利益GET,对于登录表单或任何其他具有相对敏感信息的表单,请确保您使用的POST是:
信息POSTed不会保存在用户的历史记录中.
表单中发送的敏感信息(密码等)稍后将在URL栏中显示(通过使用GET,它将在历史记录和URL栏中可见).
此外,GET还有数据的理论限制.POST没有.
对于真正的敏感信息,请务必使用SSL(HTTPS)
6> Mihai Limbăș..：
GET和POST中的任何一个本身都不比另一个"更安全",就像传真和电话中的任何一个都不比另一个"更安全"一样.提供了各种HTTP方法,以便您可以选择最适合您尝试解决的问题的方法.对于幂等查询,GET更适合,而POST更适合"动作"查询,但如果您不了解正在维护的应用程序的安全体系结构,您可以轻松地使用它们中的任何一个.
如果你阅读第9章:HTTP/1.1 RFC的方法定义,以便全面了解最初设想的GET和POST是什么意思,这可能是最好的.
7> ruquay..：
不应该从安全性的角度来看待GET和POST之间的区别,而是要考虑他们对服务器的意图.GET永远不应该更改服务器上的数据 - 至少不是在日志中 - 但POST可以创建新资源.
好的代理不会缓存POST数据,但是它们可能会缓存来自URL的GET数据,所以你可以说POST应该更安全.但POST数据仍然可用于不能很好地播放的代理.
正如许多答案所述,唯一可靠的赌注是通过SSL.
但请确保GET方法不提交任何更改,例如删除数据库行等.
8> Ross..：
我通常的选择方法是这样的:
GET为将物品取出后通过URL
例如,搜索应该是GET所以你可以稍后进行search.php？s = XXX
POST将发送的项目
这是相对不可见的,与GET相关并且难以发送,但数据仍然可以通过cURL发送.
所以一个假帖子需要记事本和5分钟的时间......并不是真的难得多.我使用记事本为不存在的电话系统添加功能.我能够为系统创建一个管理表单的副本,这样我就可以将命令分配给供应商所关注的"不可能"的按钮.
9> Daniel Silve..：
这与安全性无关,但是...... 浏览器不会缓存POST请求.
10> edebill..：
两者都没有神奇地赋予请求安全性,但是GET意味着一些副作用通常会阻止它的安全性.
GET URL显示在浏览器历史记录和Web服务器日志中.出于这个原因,它们永远不应该用于登录表单和信用卡号码之类的东西.
但是,仅发布该数据也不会使其安全.为此你想要SSL.当通过HTTP使用时,GET和POST都通过线路以明文形式发送数据.
POST数据还有其他很好的理由 - 比如能够提交无限量的数据,或隐藏临时用户的参数.
缺点是用户无法为通过POST发送的查询的结果添加书签.为此,你需要GET.
11> Halil Özgür..：
考虑这种情况:一个草率的API接受GET请求,例如:
http://www.example.com/api?apikey=abcdef123456&action=deleteCategory&id=1
在某些设置中,当您请求此URL并且有关于请求的错误/警告时,整行将记录在日志文件中.更糟糕的是:如果您忘记在生产服务器中禁用错误消息,则此信息仅在浏览器中以简单方式显示!现在,您刚刚将API密钥提供给所有人.
不幸的是,有真正的API以这种方式工作.
我不喜欢在日志中包含一些敏感信息或在浏览器中显示它们的想法.POST和GET不一样.在适当的地方使用.
京公网安备 11010802040832号 | 京ICP备19059560号-6 