get和post的区别
1.GET请求的数据会附在URL之后(就是把数据放置在HTTP协议头中),以?分割URL和传输数据,参数之间以&相连,如:login.action?name=hyddd&password=idontknow&verify=%E4%BD%A0%E5%A5%BD。如果数据是英文字母/数字,原样发送,如果是空格,转换为+,如果是中文/其他字符,则直接把字符串用BASE64加密,得出如:%E4%BD%A0%E5%A5%BD,其中%XX中的XX为该符号以16进制表示的ASCII。
POST把提交的数据则放置在是HTTP包的包体中。
简而言之:GET把参数包含在URL中,POST通过request body传递参数。
2.根据HTTP规范,GET用于信息获取,而且应该是安全的和幂等的。
(1).所谓安全的意味着该操作用于获取信息而非修改信息。换句话说,GET 请求一般不应产生副作用。就是说,它仅仅是获取资源信息,就像数据库查询一样,不会修改,增加数据,不会影响资源的状态。
* 注意:这里安全的含义仅仅是指是非修改信息。
(2).幂等的意味着对同一URL的多个请求应该返回同样的结果。这里我再解释一下幂等这个概念:
3.GET请求在URL中传送的参数是有长度限制的,而POST没有
(1).首先是"GET方式提交的数据最多只能是1024字节",因为GET是通过URL提交数据,那么GET可提交的数据量就跟URL的长度有直接关系了。而实际上,URL不存在参数上限的问题,HTTP协议规范没有对URL长度进行限制。这个限制是特定的浏览器及服务器对它的限制。IE对URL长度的限制是2083字节(2K+35)。对于其他浏览器,如Netscape、FireFox等,理论上没有长度限制,其限制取决于操作系统的支持。
注意这是限制是整个URL长度,而不仅仅是你的参数值数据长度。[见参考资料5]
(2).理论上讲,POST是没有大小限制的,HTTP协议规范也没有进行大小限制,说“POST数据量存在80K/100K的大小限制”是不准确的,POST数据是没有限制的,起限制作用的是服务器的处理程序的处理能力。
简而言之:GET请求发送数据更小。
4.GET请求会被浏览器主动cache,而POST不会,除非手动设置。
5.GET请求只能进行url编码,而POST支持多种编码方式。
6.GET请求参数会被完整保留在浏览器历史记录里,而POST中的参数不会被保留。
7.对参数的数据类型,GET只接受ASCII字符,而POST没有限制。
8.POST的安全性要比GET的安全性高。注意:这里所说的安全性和上面GET提到的“安全”不是同个概念。上面“安全”的含义仅仅是不作数据修改,而这里安全的含义是真正的Security的含义,比如:通过GET提交数据,用户名和密码将明文出现在URL上,因为(1)登录页面有可能被浏览器缓存,(2)其他人查看浏览器的历史纪录,那么别人就可以拿到你的账号和密码了,除此之外,使用GET提交数据还可能会造成Cross-site request forgery(注释1)攻击。
9.GET产生一个TCP数据包;POST产生两个TCP数据包。
长的说:
对于GET方式的请求,浏览器会把http header和data一并发送出去,服务器响应200(返回数据);
而对于POST,浏览器先发送header,服务器响应100 continue,浏览器再发送data,服务器响应200 ok(返回数据)。
也就是说,GET只需要汽车跑一趟就把货送到了,而POST得跑两趟,第一趟,先去和服务器打个招呼“嗨,我等下要送一批货来,你们打开门迎接我”,然后再回头把货送过去。
因为POST需要两步,时间上消耗的要多一点,看起来GET比POST更有效。因此Yahoo团队有推荐用GET替换POST来优化网站性能。但这是一个坑!跳入需谨慎。为什么?
1. GET与POST都有自己的语义,不能随便混用。
2. 据研究,在网络环境好的情况下,发一次包的时间和发两次包的时间差别基本可以无视。而在网络环境差的情况下,两次包的TCP在验证数据包完整性上,有非常大的优点。
3. 并不是所有浏览器都会在POST中发送两次包,Firefox就只发送一次。
注释1:跨站请求伪造(Cross Site Request Forgery (CSRF))
跨站请求伪造(Cross Site Request Forgery (CSRF))也被称为:one click attack/session riding,缩写为:CSRF/XSRF,是一种挟制终端用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法。攻击人员通过一些手段让终端用户点击存在攻击的链接或者页面,例如攻击人员通过xss漏洞在终端用户的页面中执行,或者将这个代码放在一个具有诱惑性的页面中,亦或者将链接直接放在论坛帖子中。
CSRF攻击原理
1. 用户登录可信任的网站A(存在缺陷的交易网站);
2. 网站A返回登录session信息并将session存储在本地cookie;
3. 用户访问其他网站B(论坛、好友发送页面),网站B中包含执行网站A相关操作的请求操作(转账URL、退款URL)并且能够直接执行;
4. 网站B页面加载过程中携带网站A的cookie将请求发送到网站A的服务器;
5. 网站A服务器根据请求校验用户信息后执行具体操作(资金损失),从而达到了模拟用户在网站A的相关操作使用户或者网站A遭受伤害或损失。
下图为一具体的流程:
图1 CSRF原理示例
用户被攻击的两个条件是:
1. 登录了网站A并在本地保存了cookie;
2. 在未退出网站A或者清除cookie的情况下访问了网站B,并且在网站B帮助用户向网站A提交了请求。
CSRF防御
1. token校验
用户进行操作交互前先构造一个token值(随机数),后续每次操作请求必须带上token值,服务器校验token合法后才进行相关操作,这样黑客因为无法提前获知用户的token,就无法构造出正确的操作URL。加上token后操作URL必须带上一随机值,如下:
http://www.xxxxx.com/changeprice?orderId=123456789&fromprice=100.00&toPrice=0.01&t=rand()
按照之前的攻击执行结果如下:
坏人因为没有小白的token信息,因此伪造的URL是不能被服务器处理的,从而导致阴谋无法得逞。
这个方法已经可以杜绝99%的CSRF攻击,由于用户的Cookie很容易由于网站的XSS漏洞而被盗取,这就另外的1%。一般的攻击者看到有需要算token值,基本都会放弃了,某些除外,所以如果需要100%的杜绝,这个不是最好的方法。
(2).验证码
这个方案的思路是:每次的用户提交都需要用户在表单中填写一个图片上的随机字符串,这个方案可以完全解决CSRF,但在易用性方面似乎不是太好。