通过朱棣篡位的故事告诉你当今互联网上的信息是如何传递的

话说明朝建文帝登基以后，为了削弱各藩王势力，稳固自己的皇权，开始了削藩活动，一年内便干掉了五个王爷。

然而此时势力最大燕王朱棣却不甘心这么被自己的侄子干掉，于是派长史葛城到朱允炆身边做了间谍，以监视朱允炆的行动。

那么葛城远在南京，如何安全的把信息传递到身在北京的朱棣手中呢？

葛城给朱棣传递信息的过程，我们就可以看成是一个http请求。

当今的互联网系统在传递信息的手段上绝大多数都是通过http请求完成的。如我们登录的时候是把用户名和密码通过http请求发送到了服务器，我们查看图片的时候是通过http请求让图片从服务器传递到了我们的浏览器中。本质上来说，互联网的各种业务都是在进行着信息的传递。

和朱棣一样，我们的信息传递一样面临着安全的挑战问题。那么当今的技术是如何去实现安全交换信息的呢？

传输的安全

话说朱棣的王府作为办事机构，开设了各种各样的窗口，这些窗口的作用主要就是为外面的老百姓服务。

比如告状的呀，给朱棣表白的呀，新生儿要注册一个户口呀，都需要到对应的窗口去办事。

朱棣的政府就是一个网站，他的王府就是我们现在的服务器，服务器可以理解为一台高配的个人电脑。服务器为了对外服务也一样提供了很多窗口，我们称之为端口。

葛城为了把信件送到朱棣的王府，需要用一个信封把信件包起来，然后写上收件人的地址，寄件人的信息，投递给送信的衙门，送信的衙门会像送快递一样把这些信件投递到对应的地址中。

同样的，当我们在一个网站上发布一篇文章的时候，我们的文字内容也会被计算机包裹起来，称之为HTTP包，收件人的地址就是访问网站时网址，寄件人信息通常包含我们电脑的IP地址和我们在网站的用户信息。送信的衙门就是我们的网络运营商如电信宽带、移动宽带等，我们的手机通过wifi连接到运营商的网络中，把我们的信息发给他们进行传递。

这个时候问题来了：当朱棣通过窗口收到一个寄件人为葛城的信件后，他如何知道这个信件一定是葛城投递的呢？

聪明如朱棣的你应该也已经想到，朱棣可以在派葛城去之前给他一段密文如小鸡炖蘑菇之类，葛城把这段密文附在信封中，朱棣收到后验证一下这个密文是否正确，从而就知道了信件是否确实来自葛城之手了。

一样的，我们在登录网站或者手机app的时候，会有一个登录的过程，登录后服务器也会给我们一段密文，保存到我们的浏览器里。这段密文就是我们在网站上身份的唯一标识，每个用户的密文都不一样，服务器通过这段密文就知道提交的文章是否真正出自我们的手中。

安稳的日子通常不会太久

就这样，葛城通过不断的给朱棣投递信件传递朱允炆的动态，朱棣通过密文过滤掉了那些假信件。直到有一天一个不速之客的出现。

话说朱允炆也不是傻蛋，他派人去送信衙门截断了葛城的信件，拆开信封获得了密文，并伪造了另外一份信件，附上同样的密文投递给了朱棣。而且葛城的给朱棣的信息也被朱允炆全部偷窥，朱棣和葛城的信息交流将会完全暴露在朱允炆的眼皮底下。

这种事情在我们的互联网中也很常见。比如我们在逛街的时候连接了一个免费wifi，这个wifi的控制者就能在电脑上查看我们发给服务器的数据包，拆开数据包得到我们的密文，从而伪造我们的身份在服务器上任意妄为。是的，如果没有数据加密，你的银行卡密码一样可以被wifi控制者截获！

这可急坏了朱棣，那朱棣要怎样才能让朱允炆无法偷窥他和葛城之间的信件呢？

数据加密传输

朱棣为了防止朱允炆的偷窥，赶紧给葛城送去一本密码本，这本密码本把他们交流要用到的汉字进行了编码，如皇对应的是数字1，帝对应的是数字2，要对应数字3，杀对应数字4，你对应数字5。这样当需要发送皇帝要杀你的时候就只需要发送12345，就算朱允炆截取了信件，也看不懂内容是啥。而且也很难伪造信件的内容，因为他没有密码本，就没办法知道某个汉字对应的数字。

这种通过密码本加密的方法被称为对称加密，即双方都有一本密码本，通过相同的密码本进行加密和解密。

但是这种加密方式并不够高级，因为密码本是有可能会被盗取的。因此在现代密加密手段中，我们使用了一种被称为非对称加密的更高级的加密算法，这个算法通过巧妙的数学原理使得我们不依赖密码本去加密，可以保证我们的数据在传输过程中是通过密文来传送，就算被中间商截取也无法去篡改。由于非对称加密算法略微复杂，我们在这里就不进行展开讨论。当我们在访问网站的时候看到浏览器地址栏左侧有一个钥匙的图标，就代表我们的传输是加密的，无法被篡改的，如果没有这个图标，则我们和服务器之间的信息传输是没有经过加密的，有可能被中间商窃取。

到现在为止，朱允炆已经很难有办法去破解葛城与朱棣之间的信息交流了。

就这样，通过安全的信息传输取到，朱棣最终掌握了朱允炆的各种动向，为后面的篡权行动打下了坚实的基础。从而才有了后来的明成祖，也才有了我们今天的北京城。

注：本文所描述的各种技术均为虚构，历史上并没有这么发达的加密技术。

HTTP作为一个无状态的协议，服务器要判断来自客户端的请求是否安全并不简单，需要考虑很多方面的问题。

对于一个独立服务器来说，收到的每一条请求都是独立的。那么这条请求是否是真正的客户端发送的？

HTTP安全包括了太多内容。如cookie的安全、xss攻击、跨站请求攻击、密码破解。

这里简要的罗列跟安全相关的一些内容。

• 传输安全，使用https保证server收到的信息在传输工程中没有被篡改，且为用户的浏览器设置始终通过https访问本站防止http伪造的网站被打开。

• 传输安全了，谁传过来的并不安全，因此对client的鉴权必不可少。这时候就需要：

  • 一旦使用cookie，就要防止cookie被盗取(配置好httponly防止xss读取到、配置Secure保证网站被劫持的不是https的url无法读取到cookie)，防止跨站提交携带cookie(配置SameSite防止三方跨域提交的时候读取到cookie)。可以通过prefixes头保证设置cookie的时候不忘记设置samesite和secure等。

  • 即使对cookie进行了正确的设置，老的浏览器有可能不支持这些安全设置。因此最好通过token来保证不受跨站攻击的风险。

• client安全了，业务有可能不安全。

  • 暴力破解： 密码、验证码要防止暴力破解。

  • ssrf攻击：防止用户填写内网地址利用网站攻击服务器集群。

  • 二次验证：对应敏感操作进行二次验证，就算密码被破解掉也还有一层关卡。

• 业务和client都安全了，难以保证用户的输入数据安全。即xss。可以通过csp的设置来限制页面上资源的加载和执行策略保证就算xss了也无法执行不安全的代码。

MDN的安全配置推荐文档：https://infosec.mozilla.org/guidelines/web_security

安全配置完成后，可以到这个mdn的天眼网站监测https://observatory.mozilla.org/

X-Content-Type-Options

通过设置X-Content-Type-Options: ‘nosniff’,浏览器只能选择相信content-type，不能对文件进行扫描。如果没有设置content-type，也不能扫描。

• 对于js和css设置了这个头，有可能不会下载文件

• 对于html、plain、json、xml开启CORB，详见CORB

X-Frame-Options

• deny 不能被任何地方作为frame

• sameorigin 同域名下可以作为frame(注意端口不同也ok)

X-XSS-Protection

基本已经废弃，改为使用Content-Security-Policy禁止行内javascript

ssrf攻击

利用server提供的proxy服务，把proxy的地址填写成server集群的某个内网地址，从而把server机器作为跳板机访问到集群里的内网地址。