随着Web的发展，现代Web应用程序正在迅速变化。现在，前端代码承担的责任几乎等于后端代码，甚至更多。

这意味着客户变得更加复杂，可以做更多的事情，因此功能更强大。但是，强大的力量伴随着巨大的责任。

为了安全地进行所有操作，我们需要一种更好的客户端代码安全模型。在这篇文章中，我们将讨论如何不使用户失败并使他们免受潜在的犯罪者的侵害。

我们将讨论各种安全问题，攻击类型，并针对他们的预防措施，以建立一个安全的前端。让我们深入研究它。

跨站点脚本（XSS）攻击— XSS是一种攻击类型，攻击者在其中将恶意脚本输入到Web应用程序中。当其他用户访问Web应用程序时，由于浏览器不知道它是由后端提供服务的恶意程序，因此将执行此恶意脚本。

让我们使用此图更好地了解它。

XSS攻击模型

a）具有恶意脚本的攻击者访问该应用程序。

b）他填写了一个表格，并在表格字段中输入了恶意脚本。

c）恶意脚本通过表单字段数据到达后端系统，并保存在数据库中。

d）当某些合法用户访问该应用程序时，该应用程序的后端将向他提供恶意脚本。浏览器不知道它是恶意脚本，然后执行它。

该脚本可以做任何事情，就像它可以公开并将用户的会话令牌，Cookie等发送给攻击者的远程服务器一样。

预防-

• 到达时过滤输入- 收到输入后，根据预期或有效输入过滤数据。
• 在输出上编码数据 -在HTTP响应中提供用户可控制的数据时，请对输出进行编码，以防止HTML解析器执行该输出。根据输出上下文，这可能需要应用HTML，URL，JavaScript和CSS编码的组合。
• 使用适当的响应标头- 为了防止HTTP响应中不包含任何HTML或JavaScript的XSS，我们可以使用Content-Type和X-Content-Type-Options标头来确保浏览器以您所使用的方式解释响应打算。例如。绝对不要将JSON数据编码为text / html，以防止意外执行。

跨站点请求伪造（CSRF） -CSRF是一种诱骗受害者提交恶意请求的攻击。

如果用户当前已通过某个网站的身份验证，则对该网站发出的任何HTTP请求都将具有与该网站相关联的任何凭据，例如用户的会话cookie，IP地址等会自动附加到该凭据。

如果请求是由攻击者发起的，则当此请求到达后端时，服务器将无法区分恶意请求和合法请求。

CSRF攻击的目标功能会导致服务器状态发生变化，例如更改受害者的电子邮件地址或密码或购买东西。

攻击如何进行？

假设用户John登录到他的网上银行网站（http://bank.com）。他收到了来自攻击者的恶意邮件：

使用GET请求-

• 该电子邮件可以包含伪装成普通链接的银行URL，当John单击该URL时，浏览器将使用John在其网上银行网站上的所有用户会话凭据进行GET调用。

• 或者，电子邮件可以简单地使用银行的URL渲染0 X 0图像，该URL会自动触发GET请求。

使用POST请求

• 如果银行不允许针对此类交易的GET请求，则攻击者可以诱使John单击恶意URL，从而诱使John发出POST请求。这会将John重定向到执行该恶意表格的网站。

用户只需要按下“提交”按钮，但这也可以使用javascript执行。

预防-

对于用户的每个会话，服务器应生成一个随机令牌（CSRF令牌）并将其发送给客户端。客户端可以保存令牌，而javascript可以从中读取令牌。

当Web应用程序发出HTTP请求时，该应用程序应在每个请求的标头中包含该随机令牌（CSRF令牌）。

该令牌的值应随机生成，以使攻击者无法猜测它的值。我们应该使用众所周知的哈希算法（例如SHA256 / 512）来生成令牌。

当从应用程序发出请求时，与用户会话中找到的令牌相比，服务器必须验证请求中令牌的存在和有效性。如果在请求中找不到令牌，或者提供的值与用户会话中的值不匹配，则应删除该请求，并将该事件记录为正在进行的潜在CSRF攻击。

DOS（拒绝服务）攻击 -DOS攻击是一种网络攻击，攻击者试图通过破坏连接到Internet的服务器的服务来使服务器资源对实际用户不可用。

这种攻击是通过在非常短的时间间隔（每毫秒）中使大量请求超载系统来进行的，从而阻止了合法请求的响应。

在分布式拒绝服务攻击（DDoS攻击）中，淹没受害者的传入流量来自许多不同的来源。这有效地使得仅通过阻止单个源/ IP地址就无法阻止攻击。

预防 -在面向公众的端点（登录，注册，联系）上使用验证码-验证码是一种旨在区分人与机器人的计算机程序或系统。

大多数DOS攻击都是使用漫游器进行的。验证码可识别机器人并阻止其发出请求。

Google的reCaptcha是一项高级服务，可防止机器人滥用您的应用程序。

内容安全策略（CSP）— CSP是一种机制，可以大大降低现代浏览器中XSS攻击的风险和影响。

XSS中出现的主要问题是浏览器无法区分旨在成为您自己的应用程序一部分的脚本。一个网站可以使用来自不同来源的多个脚本。浏览器将愉快地下载并执行所遇到的任何脚本。

CSP定义了Content-Security-Policy HTTP标头，而不是盲目地信任服务器提供的所有内容，该标头使您可以创建可信内容源的白名单，并指示浏览器仅执行或呈现这些源中的资源。即使攻击者可以找到一个漏洞来注入脚本，该脚本也不会与白名单匹配，因此不会被执行。

例如。 content-security-policy: script-src ‘self’ [https://apis.google.com](https://apis.google.com/)

在这里，应用程序仅信任来自apis.google.com和我们自己的脚本。对于其他来源，浏览器将在控制台中引发错误。

这里要注意的非常重要的一点是，CSP提供了针对基于来源的脚本的预防措施，因此它不会阻止任何内联脚本的执行。使用内联脚本注入，基于源的白名单无法解决对XSS攻击的最大威胁。

CSP通过完全禁止任何内联脚本来解决此问题。因此，我们将必须将script标记内的所有内联js移动到外部脚本文件。外部脚本已被视为最佳实践。它们使浏览器更易于缓存，对开发人员更有利，对压缩更有利。

令人遗憾的是，经常忽略前端代码的安全性。这应该被视为当务之急。不能讨价还价的东西。只有这样，我们才能确保用户和应用程序的安全生态系统。

作为这些应用程序的构建者，我们应该始终致力于安全第一的方法。我希望本文能为您提供有关Web安全性的有用见解。

参考

Understanding Frontend Security