查看原文
其他

面试官:POST 比 GET 安全吗?你理解就是错的

技术最TOP 2022-08-26

作者:南柯之石
链接:http://www.cnblogs.com/nankezhishi/archive/2012/06/09/getandpost.html
如果有人问你,GET和POST,有什么区别?你会如何回答?

我的经历

前几天有人问我这个问题。我说GET是用于获取数据的,POST,一般用于将数据发给服务器之用。

这个答案好像并不是他想要的。于是他继续追问有没有别的区别?我说这就是个名字而已,如果服务器支持,他完全可以把GET改个名字叫GET2。他反问道,那就是单纯的名字上的区别喽?我想了想,我觉得如果说再具体的区别,只能去看RFC文档了,还要取决于服务器(指Apache,IIS)的具体实现。但我不得不承认,我的确没有仔细看过HTTP的RFC文档。于是我说,我对HTTP协议不太熟悉。这个问题也就结束了。

基本区别
GET和POST是HTTP请求的两种基本方法,要说它们的区别,接触过WEB开发的人都能说出一二。

最直观的区别就是GET把参数包含在URL中,POST通过request body传递参数。

你可能自己写过无数个GET和POST请求,或者已经看过很多权威网站总结出的他们的区别,你非常清楚知道什么时候该用什么。

当你在面试中被问到这个问题,你的内心充满了自信和喜悦。

这不小伙美团一面就被问到了这个问题,一顿操作猛如虎。






你轻轻松松的给出了一个“标准答案”:

1. GET在浏览器回退时是无害的,而POST会再次提交请求。

2. GET产生的URL地址可以被Bookmark,而POST不可以。

3. GET请求会被浏览器主动cache,而POST不会,除非手动设置。

4. GET请求只能进行url编码,而POST支持多种编码方式。

5. GET请求参数会被完整保留在浏览器历史记录里,而POST中的参数不会被保留。

6. GET请求在URL中传送的参数是有长度限制的,而POST么有。

7. 对参数的数据类型,GET只接受ASCII字符,而POST没有限制。

8. GET比POST更不安全,因为参数直接暴露在URL上,所以不能用来传递敏感信息。

9. GET参数通过URL传递,POST放在Request body中。

(本标准答案参考自w3schools)

“很遗憾,这不是我们要的回答!”


请告诉我真相。。。

如果我告诉你GET和POST本质上没有区别你信吗? 

让我们扒下GET和POST的外衣,坦诚相见吧!


GET和POST是什么?HTTP协议中的两种发送请求的方法。
 
HTTP是什么?HTTP是基于TCP/IP的关于数据如何在万维网中如何通信的协议。
 
HTTP的底层是TCP/IP。所以GET和POST的底层也是TCP/IP,也就是说,GET/POST都是TCP链接。GET和POST能做的事情是一样一样的。你要给GET加上request body,给POST带上url参数,技术上是完全行的通的。 
 
 
好了,现在你知道,GET和POST本质上就是TCP链接,并无差别。但是由于HTTP的规定和浏览器/服务器的限制,导致他们在应用过程中体现出一些不同。 
 
你以为本文就这么结束了?


我们的大BOSS还等着出场呢。。。
 
这位BOSS有多神秘?当你试图在网上找“GET和POST的区别”的时候,那些你会看到的搜索结果里,从没有提到他。他究竟是什么呢。。。

最普遍的答案

回来之后寻思了很久,他到底是想问我什么?我一直就觉得GET和POST没有什么除了语义之外的区别,自打我开始学习Web编程开始就是这么理解的。


可能很多人都已经猜到了,他要的答案是:

1. GET使用URL或Cookie传参。而POST将数据放在BODY中。

2. GET的URL会有长度上的限制,则POST的数据则可以非常大。

3. POST比GET安全,因为数据在地址栏上不可见。

4. 并不是所有浏览器都会在POST中发送两次包,Firefox就只发送一次。

但是很不幸,这些区别全是错误的,更不幸的是,这个答案还是Google搜索
的头版头条,然而我根本没想着这些是答案,因为在我看来他们都是错的。我来一一解释一下。

GET和POST与数据如何传递没有关系

GET和POST是由HTTP协议定义的。在HTTP协议中,Method和Data(URL, Body, Header)是正交的两个概念,也就是说,使用哪个Method与应用层的数据如何传输是没有相互关系的。

HTTP没有要求,如果Method是POST数据就要放在BODY中。也没有要求,如果Method是GET,数据(参数)就一定要放在URL中而不能放在BODY中。

那么,网上流传甚广的这个说法是从何而来的呢?我在HTML标准中,找到了相似的描述。这和网上流传的说法一致。但是这只是HTML标准对HTTP协议的用法的约定。怎么能当成GET和POST的区别呢?

而且,现代的Web Server都是支持GET中包含BODY这样的请求。虽然这种请求不可能从浏览器发出,但是现在的Web Server又不是只给浏览器用,已经完全地超出了HTML服务器的范畴了。

知道这个有什么用?我不想解释了,有时候就得自己痛一次才记得住。

HTTP协议对GET和POST都没有对长度的限制

HTTP协议明确地指出了,HTTP头和Body都没有长度的要求。而对于URL长度上的限制,有两方面的原因造成:

1. 浏览器。据说早期的浏览器会对URL长度做限制。据说IE对URL长度会限制在2048个字符内(流传很广,而且无数同事都表示认同)。但我自己试了一下,我构造了90K的URL通过IE9访问live.com,是正常的。网上的东西,哪怕是Wikipedia上的,也不能信。

2. 服务器。URL长了,对服务器处理也是一种负担。原本一个会话就没有多少数据,现在如果有人恶意地构造几个几M大小的URL,并不停地访问你的服务器。服务器的最大并发数显然会下降。另一种攻击方式是,把告诉服务器Content-Length是一个很大的数,然后只给服务器发一点儿数据,嘿嘿,服务器你就傻等着去吧。哪怕你有超时设置,这种故意的次次访问超时也能让服务器吃不了兜着走。有鉴于此,多数服务器出于安全啦、稳定啦方面的考虑,会给URL长度加限制。但是这个限制是针对所有HTTP请求的,与GET、POST没有关系。

安全不安全和GET、POST没有关系

我觉得这真是中国特色。我讲个小段子,大家应该可以体会出这个说法多么的可笑。

觉得POST数据比GET数据安全的人会说

  “防君子不防小人;中国小白多,能防小白用户就行了。”

“哼,”我不以为然,“那你怎么不说,URL参数都Encode过了,或是Base64一下,小白也看不懂啊。”

那人反驳道,“Encode太简单了,聪明点儿的小白很容易就可以Decode并修改掉。”

我笑道,“五十步笑百步耳,再聪明点儿的小白还会截包并重发呢,Opera就有这功能。”

那人阴险地祭出神器——最终解释权,说,“这个不算小白。”

我日啊。

最后一点儿感想

我之前一直做Windows桌面应用,对Web开发无甚了解,直到一年多前转做服务器端开发,才开始接触到HTTP。(注意,我说的是HTTP,不是HTML。服务器开放接口是基于REST理念设计的,使用的协议是HTTP,但是传输的内容不是HTML。这不是Web Server,而是一个Web Service)

所以我对于GET和POST的理解,是纯粹地来源于HTTP协议。他们只有一点根本区别,简单点儿说,一个用于获取数据,一个用于修改数据。具体的请参考RFC文档。

如果一个人一开始就做Web开发,很可能把HTML对HTTP协议的使用方式,当成HTTP协议的唯一的合理使用方式。从而犯了以偏概全的错误。

可能有人会觉得我钻牛角尖。我只是不喜欢模棱两可,不喜欢边界不清、概念不明,不喜欢“拿来主义”,也不喜欢被其它喜欢钻牛角尖的人奚落得无地自容。

“知之为知之,不知为不知,是知也。”


---END---


推荐阅读:
从0开始在鸿蒙OS中制作一个APP!
再见,Navicat!同事安利的这个IDEA的兄弟,真香!
升级了,Android 11 正式发布,偏重3大主题!
支付宝二面:Mybatis接口Mapper内的方法为啥不能重载吗?我直接懵逼了...
Android RecyclerView自定义LayoutManager
知乎高赞:iOS 为什么感觉比 Android 流畅?
Android | 自定义上拉抽屉+组合动画效果


更文不易,点个“在看”支持一下👇

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存