「译」Web安全快速入门

Web安全快速入门

──几个Web开发人员必知的安全缩略语

原文：A quick introduction to web security

做者：Austin Tackaberry 发表时间：2018/8/15

译者：陈 昌茂 发表时间：2018/8/25

(转载请注明出处)

你有不少理由须要了解Web安全，好比：

• 你是一位关心我的隐私数据正被泄露的用户
• 你是一名Web开发人员，想要编写更加安全的Web应用
• 你是一位正在应聘Web开发岗位，准备面试有关Web安全问题。
• 诸如此类～

本文将通俗易懂的准确地解释一些经常使用的Web安全缩略语。

在此以前，咱们要了解两种模式，分别表明着两个极端，但又同属一个观念层次。

安全的两个模式

一种模式是追求绝对安全，结果不管如何努力也达不到绝对安全，而弄得本身痛苦不堪。

另外一种是在采起了必定的防御措施后，便知足地认为已达到绝对安全，因而放松警戒，最后遭受安全威胁的攻击，损失惨重。

你不能就说：

喔，由于实现了CSP，因此我是安全的。我能够在漏洞清单中划掉跨站脚本，由于它不会发生。

你会发现本身和其余人同样，也是按这种方式思考的。显而易见，程序员们很容易按这种方式思考：非黑即白，非0即1，非对即错。其实，安全远没有这么简单。

咱们在Web开发工做中初期就遇到会这些问题，并尝试从StackOverflow社区中能找到解决方案。

跨源资源共享（CORS）

你是否见到相似下面的错误信息？

No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'null' is therefore not allowed access.
复制代码

你不是一我的在战斗，你Google查询，有人说用这个方法，全部问题立刻解决。

太好了，不是吗？

CORS是来保护你而不是伤害你的

为了解释CORS是如何帮助你的，让咱们先从cookie提及，特别是认证cookie。认证cookie是用来告诉后台程序你的登陆状态，它们自动随任何请求发送给后台程序。

咱们来假设：你已经登陆了Facebook帐户，且Facebook使用cookie认证。你点击连接bit.ly/r43nugi，它重定向到恶意网站 superevilwebsite.rocks。恶意网站 superevilwebsite.rocks中的一段脚本代码向facebook.com 后台程序发起请求，你的认证cookie自动随请求发送给facebook.com 后台程序。

在非CORS的世界，黑客能够在你绝不知情的状况下变动你的帐户。只须要简单几步：一、黑客在你的时间线上发帖，帖子中包含bit.ly/r43nugi 恶意连接；二、你的朋友们点击了该恶意连接，恶意脚本程序又在他们的时间线上发帖，这个过程不断被重复，在广度优先模式下，直到黑客占领了所有的Facebook用户的时间线，世界充斥着恶意网站 superevilwebsite.rocks。 😆

然而在CORS的世界，Facebook将只容许来源自facebook.com的请求方可在后台程序中修改数据。换句话说，他们会限制跨源资源共享。你可能会问：

咱们能够修改请求文件头，这样请求不就看起来是来自facebook.com吗？

你能够试试，但不会成功的，由于浏览器会忽略你的修改，它会使用真正的来源信息。

好了，那若是恶意网站修改后台程序的请求呢？

在这种状况下，你想绕过CORS，但你仍是不会得逞，缘由后台程序不能同时发送你的认证cookie。脚本必须在浏览器上执行才能获取到你存在浏览器上的cookie。

内容安全策略（CSP）

为了便于理解CSP，咱们先谈一下最多见的Web漏洞：跨站脚本攻击（简称：XSS）

XSS即黑客在你的浏览器中注入JavaScript代码。你可能会想：

黑客会作什么，红变绿吗？

咱们假如黑客在你的浏览器成功中注入JavaScript代码到你正在访问的网站代码中。

他们可能会作哪些邪恶的事情？

• 他们能冒充你向其余网站发送HTTP请求。
• （这句不会翻，囧）
• 他们能加script标签，内嵌的一段JavaScript代码。
• 他们能加script标签，引用远程的JavaScript代码。
• 他们能内嵌一个网页覆盖正常网页之上，提示你输入密码。
• 罄竹难书，发挥你的想象力吧。

CSP经过限制功能提供保护：

• 什么能在框架内打开。
• 什么样式表能够被加载。
• 哪些请求能够发送，等等。

那它时怎么工做的呢？

等你点击连接或在浏览器地址栏输入网址的时候，浏览器发送GET请求。服务器返回HTTP头信息以及HTML内容。若是你对返回头信息是什么很好奇，（以谷歌Chrome浏览器为例，打开浏览器开发者模式。括弧内为译者补充，下同）切换到“网络”标签，访问网站facebook.com。

你可能会看到以下返回头信息：

content-security-policy: default-src * data: blob:;script-src *.facebook.com *.fbcdn.net *.facebook.net *.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:* 'unsafe-inline' 'unsafe-eval' *.atlassolutions.com blob: data: 'self';style-src data: blob: 'unsafe-inline' *;connect-src *.facebook.com facebook.com *.fbcdn.net *.facebook.net *.spotilocal.com:* wss://*.facebook.com:* https://fb.scanandcleanlocal.com:* *.atlassolutions.com attachment.fbsbx.com ws://localhost:* blob: *.cdninstagram.com 'self' chrome-extension://boadgeojelhgndaghljhdicfkmllpafd chrome-extension://dliochdbjfkdbacpmhlcpmleaejidimm;
复制代码

这些是facebook.com的安全内容策略。让咱们调整成可读性强的格式。

content-security-policy:
default-src * data: blob:;
script-src *.facebook.com *.fbcdn.net *.facebook.net *.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:* 'unsafe-inline' 'unsafe-eval' *.atlassolutions.com blob: data: 'self';
style-src data: blob: 'unsafe-inline' *;
connect-src *.facebook.com facebook.com *.fbcdn.net *.facebook.net *.spotilocal.com:* wss://*.facebook.com:* https://fb.scanandcleanlocal.com:* *.atlassolutions.com attachment.fbsbx.com ws://localhost:* blob: *.cdninstagram.com 'self' chrome-extension://boadgeojelhgndaghljhdicfkmllpafd chrome-extension://dliochdbjfkdbacpmhlcpmleaejidimm;
复制代码

如今，咱们逐条分解这些指令。

• **default-src** 限制全部其余没有显示列出的CSP指令。
• **script-src** 限制脚本加载。
• **style-src** 限制样式表加载。
• **connect-src** 限制可使用脚本接口（如获取、XHR、ajax等）的URL连接。

注意远不止这3条指令，还有更多的CSP指令。浏览器将读取CSP头信息并加载、渲染HTML文件时执行这些指令。若是恰当地设置指令，浏览器将仅容许必要的操做。

若是没有CSP头信息，那么全部的操做都不会被限制。你能够想象这些指令所有替换成通配符*，任何操做都将被容许。

HTTPS 或 HTTP安全

你确定据说过HTTPS。人们可能会这么说：

为什么我要关心一个我玩游戏的网站是否启用了HTTPS呢？

或者是这样滴。。。

太疯狂了，你的网站竟然没有启用HTTPS。都2018年了，别信其余人（潜台词：必须启用HTTPS）。

或许你据说谷歌Chrome浏览器（自7月24日发布的Chrome 68起）将把全部HTTP网站标记“不安全“。

重点是，HTTPS是加密的而HTTP不是。

若是你不发送敏感信息，（是否加密）有那么重要吗？

准备下一个缩写MITM，它表明中间人攻击。

若是你在咖啡馆使用无密码的公共Wi-Fi，任何人都很容易地冒充成路由器，使所有的请求和返回都经过该路由器。若是你的数据没有加密，那么他们能够作任何事。好比在HTML, CSS, 或 JavaScript到达你的浏览器以前修改。假如你已经知道XSS，那么能够作什么样的坏事。

那么怎样才能够实现个人电脑和服务器之间通讯加密而不被中间人攻击呢？

最初SSL协议就是为了解决这个问题而设计的，1999年，TLS协议取代SSL协议用在HTTPS上。至于TLS如何工做已经超出本文范围。

HSTS协议

让咱们还用Facebook的头信息为例，如下是一条很简洁的指令。

strict-transport-security: max-age=15552000; preload
复制代码

• max-age 标明HSTS在浏览器的生效时间。
• preload 对本文不重要。

这个头信息仅在用HTTPS访问时生效，在用HTTP访问时会被忽略。缘由很简单，HTTPS时如此不安全，很难被信任。

让咱们用Facebook的例子来描述下。你首次访问facebook.com，并且知道HTTPS比HTTP安全，因此你使用https://facebook.com。当浏览器接收到HTML，收到头信息，告知浏览器在后续访问中强制重定向到HTTPS网站。一个月后，有人经过HTTP给你发送一个Facebook的连接，好比http://facebook.com，在max-age时间范围内，浏览器会强制使用HTTPS，防止潜在的中间人攻击。

结论

不管你在Web开发旅程中的什么时候何地Web安全都很重要。你越重视它，安全威胁离你越远。安全时对每一个人都很重要的事情，而不只是对于工做中。👮