该材料的作者（我们今天出版的翻译）说，研究网络安全的原因很多。 例如，担心个人数据被盗的网站用户对安全问题感兴趣。 安全问题涉及寻求提高项目保护级别的Web开发人员。 正在寻找工作并准备面试的新手程序员也可以这样说。 本文的目的是以一种易于理解的语言来理解一些重要的Web安全技术。 在我们开始讨论通常被缩写为CORS，CSP和HSTS等缩写的这些技术之前，我们将介绍一些基本的安全概念。
两个基本的Web安全概念
protection100％的保护是神话
在安全世界中，没有“ 100％防止黑客入侵”这样的事情。 如果有人告诉您这种保护级别，请注意他是错的。
▍仅仅一个防护等级是不够的
假设有人相信通过实施CSP，他可以完全保护自己的项目免受XSS攻击。 也许有人认为绝对保护不存在，但是上述想法可以访问任何人。 如果我们谈论的是决定了解安全性问题的程序员，那么产生这种想法的原因可能是这样的事实，即在编写程序代码时，他们主要使用“黑色”和“白色”等概念进行操作， 1和0，“ true”和“ false”。 但是安全并不是那么简单。
网络安全技术
让我们开始讨论有关使用技术的Web安全性的问题，例如，开发人员通常在其职业生涯的一开始就非常注意。 顺便说一句，如果您想绕过此保护方法，可以在StackOverflow上找到大量有关如何执行此操作的信息。 关于CORS。
▍CORS
您见过这样的错误：
No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'null' is therefore not allowed access.
面对这样的情况，您认为您当然不是第一个遇到这种情况的人。 谷歌搜索，您发现为了解决此问题，安装某种扩展程序就足够了。 好吧，这不是很好吗？ 但是，不存在CORS技术（跨源资源共享，即在不同来源之间共享资源）是为了干扰开发人员，而是为了保护其项目。
为了了解CORS如何保护网络项目，我们首先讨论Cookie，尤其是用于验证用户身份的Cookie。 当使用某些Web资源时，将使用这些cookie，以通知服务器用户已登录。 它们会随请求一起发送到相应的服务器。
假设您已登录Facebook帐户，并且Facebook使用身份验证cookie。 在Internet上，您单击链接
bit.ly/r43nugi ，您将被重定向到一个恶意网站，例如
superevilwebsite.rocks 。 与该站点上的页面一起下载的脚本会使用您的身份验证cookie向
facebook.com执行客户端请求。
在没有CORS的世界中，
superevilwebsite.rocks的脚本可能会秘密更改您的FB配置文件，它可能会窃取一些信息，并随之而来。 在这样的世界中，当捕获用户帐户管理的脚本在其页面上发布链接，单击该用户的朋友“自身被感染”，并通过其页面上发布的链接，流行起来时，很容易出现“流行性superevilwebsite.rocks”最终涵盖了整个Facebook。
但是，在存在CORS的世界中，Facebook仅允许修改来自
facebook.com帐户数据的请求。 换句话说，站点的管理将限制不同源之间的资源共享。
在这里，您可能会遇到以下问题：“但是superevilwebsite.rocks可以仅在其请求中更改源标头，它们看起来像来自facebook.com吗？”
欺诈性网站可能会尝试这样做，但不会成功，因为浏览器会忽略此类标头并使用真实数据。
“如果superevilwebsite.rocks从服务器发出类似请求怎么办？”，您问。
在类似的情况下，可以绕开CORS，但不会使用CORS，因为通过执行来自服务器的请求，将无法将身份验证Cookie传输到Facebook。 因此，为了成功完成这样的请求，脚本必须在客户端执行，并且有权访问存储在客户端的cookie。
▍CSP
为了了解什么是CSP（内容安全策略，内容保护策略），您首先需要谈论最常见的Web漏洞之一。 它与XSS（跨站点脚本，跨站点脚本）有关。
进行XSS攻击时，攻击者会将特殊的JavaScript代码注入某个站点的客户端部分。 您可能会想：“那么，此脚本将做什么？ 更改页面元素的颜色？”
假设某人成功地将其JS脚本嵌入到您正在访问的网站的页面中。 类似的脚本可以做什么？ 实际上，很多事情：
- 它可以向其他站点发出HTTP请求，假装您正在这样做。
- 他可以将您重定向到一个看起来与您登录的网站完全相同的网站，但该网站的目的是例如窃取凭据。
- 它能够向包含一些JavaScript代码或旨在加载某种JS文件的页面添加
<script>标记。 - 他可以在页面上添加
<iframe>元素，例如，该元素看上去将与用于输入名称和用于输入站点的密码的字段完全相同。 在这种情况下，用于输入此类数据的这些字段将被隐藏。
实际上，为攻击者成功执行XSS攻击打开了无限的可能性。
内容保护策略试图通过应用以下限制来防止这种情况：
- 在
<iframe>可以打开的内容的限制。 - 可以加载样式表的限制。
- 可以执行哪些查询的限制。
CSP如何工作？
当您单击链接或在浏览器的地址栏中输入网站URL时，浏览器将执行GET请求。 请求到达服务器，服务器将一些HTML代码以及HTTP标头传递给浏览器。 如果您有兴趣查看这些标题，请在浏览器开发人员工具中打开“网络”选项卡，并访问多个站点。 响应头可能看起来像这样：
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;
考虑一下此处介绍的CSP指令：
default-src禁止所有未明确设置的内容。script-src引入了对可下载脚本的限制。style-src对加载的样式表施加限制。connect-src引入了对URL的限制，可以使用脚本接口（例如fetch ， XHR ， ajax等）从中加载资源的URL。
注意，实际上，有许多这样的指令。 浏览器读取CSP标头，并在加载的HTML文件中应用适当的规则。 正确配置的伪指令仅允许页面正确操作所需的那些操作。
如果该页面没有CSP标头，则没有禁止应用于它。 CSP标头中的*字符是通配符。 这样的标志可以用任何东西代替，发生的事情将被允许。
▍HTTPS
当然，您已经听说过HTTPS（HTTP安全）。 也许您遇到过这样的事情：“如果我只是在网站上玩游戏，为什么还要担心HTTPS？” 或者，也许您想出了以下想法：“如果没有HTTPS，那就太疯狂了。 在院子里的2018年！ 不要相信任何说HTTPS的人都可以免除。”
您可能听说过，如果Chrome现在不使用HTTPS，则会将其标记为不安全。
HTTPS和HTTP之间的主要区别在于，当通过HTTPS传输数据时，它们是加密的，但是当通过HTTP传输时，它们不是加密的。
传输有价值的数据时为什么值得关注？ 问题是，通过不安全的通信渠道组织数据交换时，可能会发生MITM攻击（中间人，中间人攻击或中间人）。
如果您坐在咖啡馆里，通过开放的Wi-Fi接入点访问Internet，那么很简单，有人会假装成路由器，您的所有请求和答案都将通过该路由器。 如果您的数据未加密，那么中介可以随心所欲地对其进行处理。 假设他可以编辑HTML，CSS或JavaScript代码，然后再将其从浏览器中的服务器接收到。 鉴于我们对XSS攻击的了解，您可以想象可能会有什么后果。
“这怎么可能：我的计算机和服务器知道如何加密和解密我们交换的数据，但是恶意中介却不知道？”，您问。 这要归功于SSL（安全套接字层）协议和最新的TLS（传输层安全性）协议的使用。 TLS在1999年取代SSL成为HTTPS中使用的加密技术。 TLS功能的讨论不在本文讨论范围之内。
▍HSTS
HSTS技术（HTTP Strict-Transport-Security，通过HTTPS协议强制激活安全连接的机制）非常简单。 例如，再次考虑相应的Facebook标头：
strict-transport-security: max-age=15552000; preload
让我们来分析一下：
max-age设置浏览器必须强制用户通过HTTPS使用网站的时间。preload -对于我们而言，这并不重要。
仅当您使用HTTPS访问站点时，此标题才适用。 如果您通过HTTP使用该站点，则将忽略此标头。 这样做的原因很简单：HTTP通信太弱，以至于无法信任此类标头。
让我们再次使用Facebook示例来演示HSTS机制的实用性。 假设您是第一次登录facebook.com，并且知道HTTPS比HTTP安全，因此您使用此链接：
https://facebook.com :
https://facebook.com 。 当您的浏览器收到HTML代码时，它还会收到一个标头，该标头告诉浏览器在发出以后的请求时应强制您切换到HTTPS。 一个月后，有人将HTTP链接发送给您
http://facebook.com ，然后单击它。 由于该月份少于
max-age指令指定的15552000秒，因此浏览器将通过HTTPS发送请求，从而防止了潜在的MITM攻击。
总结
今天，我们讨论了一些普遍用于确保Web项目安全的技术。 我们认为安全性问题非常重要，因为它们绝对关系到连接到Internet的每个人。 网络安全的主题非常广泛，因此您不能说阅读了几篇文章后，就会有人成为该领域的专家，或者至少学到了足以有效保护您的网络项目或个人数据的知识。 但是，与任何其他领域一样，如果希望获得安全领域的知识，则它们会积累起来，并且其数量会逐渐变成质量。 我们希望这些材料对您的网络安全知识有所帮助。
亲爱的读者们！ 您是否遇到了来自Web开发人员的不一致的安全问题？
