前端开发人员是否需要了解有关 Web 安全的任何信息？

从 OWASP 前十名开始
分类：OWASP 十大项目 [ https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project ]
之后，最好深入了解威胁模型。
遵循 OWASP 威胁建模指南
应用程序威胁建模 [ https://www.owasp.org/index.php/Application_Threat_Modeling ]
Microsoft 有一个很好的 Web 应用程序安全指南
提高 Web 应用程序安全性：威胁和对策 [ https://msdn.microsoft.com/en-us/library/ms994921.aspx ]
最后你…


照片由 Philipp Katzenberger 在 Unsplash 上拍摄
无论您是 React.js、Angular、Vue.js，还是仅仅是前端开发人员，您的代码都可以成为黑客的大门。
作为前端开发人员，我们最关心的是性能、SEO 和 UI/UX——安全性经常被忽视。
您可能会惊讶地发现大型框架让您对跨站点脚本 (XSS) 攻击敞开心扉。有风险操作名称，例如 React 中的 dangerouslySetInnerHTML 或 Angular 中的 bypassSecurityTrust API。
我们应该记住，在安全性方面，前端现在与后端或 DevOps 分担相同的责任。前端可能会发生数以千计的恶意攻击。
让我们了解最常见的——这些将涵盖这些类型的攻击的很大一部分。






照片由 vipul uthaiah 在 Unsplash 上拍摄
1.无限制的文件上传
这是一种将恶意文件上传到服务器然后执行，对系统进行攻击的攻击。攻击可能包括：过载的文件系统或数据库、完整的系统接管、客户端攻击、向后端系统转发攻击或简单的破坏。
2.点击劫持
这是一种攻击，用户被欺骗点击网页或不属于该站点的元素。这种攻击可能会导致用户在不知情的情况下提供凭据或敏感信息、下载恶意软件、访问恶意网页、在线购买产品或转账。
3. XSS 攻击
这是一种将恶意脚本以浏览器端脚本的形式注入网页的攻击。网站上的缺陷使这些攻击得以成功并传播开来。
4、SQL注入
这是一种攻击，其中注入 SQL 语句中的恶意代码以通过输入字段破坏您的数据库。
5.拒绝服务攻击（DoS攻击）
这是一种攻击，通过用流量轰炸您的服务器，使目标用户无法使用服务器或其资源。
6. 中间人攻击或会话劫持
这是一种攻击，其中客户端和服务器之间的通信被拦截以窃取密码、帐号或任何个人详细信息。

攻击者总是会尝试在前端找到一些漏洞以到达服务器并完成他的工作。在本文中，我们将看到一些在编写前端时要始终牢记的常见最佳实践。

1.严格的用户输入（第一个攻击点）
用户输入在本质上应该始终是严格的，以避免 SQL 注入、点击劫持等漏洞。因此，在将用户输入发送到后端之前验证或清理用户输入非常重要。
可以通过删除或替换上下文危险的字符来清理数据，例如通过使用白名单和转义输入数据。
但是，我意识到对于所有现有可能性而言，清理和编码并不是一件容易的事，因此我们可以使用以下开源库：
DOM 净化。这是最简单的使用方法，并且有一种方法可以清理用户的输入。它具有自定义规则的选项，并且支持 HTML5、SVG 和 MathML。
安全过滤器。一个 Salesforce 库，提供清理 HTML、JavaScript、内联 CSS 样式和其他上下文的方法。如果您想在其他地方使用用户输入，例如生成 CSS 或 JavaScript，这将特别有用。
在文件上传的情况下，请始终检查文件类型并使用文件过滤功能并仅允许某些文件类型上传。有关更多信息，请参阅此。

2.小​​心隐藏字段或存储在浏览器内存中的数据
如果我们添加 input type=”hidden” 来隐藏页面中的敏感数据或在浏览器中添加它们 localStorage、sessionStorage、cookies 并认为这是安全的，我们需要再考虑一下。
攻击者可以轻松访问添加到浏览器的所有内容。攻击者可以打开开发工具并更改所有内存变量。如果您根据 localStorage、sessionStorage 和 cookie 值隐藏了身份验证页面怎么办？
如果攻击者找到注入脚本的方法，则可以使用 ZapProxy 之类的工具甚至是浏览器中的检查工具将这些值暴露给攻击者，然后他们就可以使用它们进行进一步的攻击。
因此，请避免使用 type=”hidden” 并尽可能避免在浏览器内存存储中存储密钥、身份验证令牌等。

3. 使用强大的内容安全策略 (CSP)
永远不要信任服务器发送的所有内容——始终定义一个强大的 Content-Security-Policy HTTP 标头，它只允许某些受信任的内容在浏览器上执行或呈现更多资源。
最好有一个白名单——允许的来源列表。现在，即使攻击者注入脚本，该脚本也不会匹配白名单，也不会被执行。
例如：
content-security-policy: script-src ‘self’ https://apis.xyz.com
在这里，应用程序只信任来自 apis.xyz.com 和我们自己（self）的脚本。对于其余的源，控制台中会抛出一个错误。
注意：强大的内容安全策略并不能解决内联脚本执行的问题，因此 XSS 攻击仍然有效。
您可以在 MDN 网站上阅读 CSP 指令的完整列表。

4.启用XSS保护模式
如果攻击者以某种方式从用户输入中注入恶意代码，我们可以通过提供 “X-XSS-Protection”: “1; mode=block” 标头来指示浏览器阻止响应。
大多数现代浏览器默认启用 XSS 保护模式，但仍建议包含 X-XSS-Protection 标头。这有助于确保为不支持 CSP 标头的旧浏览器提供更好的安全性。

5. 避免典型的 XSS 错误
XSS 攻击通常追溯到 DOM API 的 innerHTML。例如：
document.querySelector(‘.tagline’).innerHTML = nameFromQueryString
任何攻击者都可以使用上面的代码注入恶意代码。
考虑使用 textContent 而不是 innerHTML 来完全防止生成 HTML 输出。如果您不生成 HTML，则无法插入 JavaScript — 您可能会看到内容但不会发生任何事情。
请留意新的可信类型规范，该规范旨在防止谷歌员工进行的所有基于 DOM 的跨站点脚本攻击。
在 react.js 的情况下，dangerouslySetInnerHTML 是明确的和警示性的，并且可以产生与 innerHTML 类似的影响。
注意：不要根据用户输入设置innerHTML值，尽量使用textContent代替innerHTML。
此外，应正确设置 HTTP 响应标头 Content-Type 和 X-Content-Type-Options 以及它们的预期行为。例如，JSON 数据不应该被编码为文本/HTML，以防止意外执行。

6.禁用iframe嵌入
禁用 iframe 可以使我们免受点击劫持攻击。我们应该始终在请求中使用“X-Frame-Options”：“DENY”标头，以禁止在框架中呈现网站。
此外，我们可以使用 frame-ancestors CSP 指令，它可以更好地控制哪些父母可以将页面嵌入到 iframe 中。

7. 保持错误的通用性
像“您的密码不正确”这样的错误可能对用户有帮助，但对攻击者也有帮助。他们可能会从这些错误中找出有助于他们计划下一步行动的信息。
在处理帐户、电子邮件和 PII 时，我们应该尝试使用诸如“登录信息不正确”之类的模棱两可的错误。

8. 使用验证码
在面向公众的端点（登录、注册、联系）上使用验证码。 Captcha 是一种计算机程序或系统，旨在将人类与机器人区分开来，可以帮助阻止 DoS（拒绝服务）攻击。

9. 始终设置推荐人策略
每当我们使用锚标签或导航离开网站的链接时，请确保您使用标题策略“Referrer-Policy”：“no-referrer”，或者在锚标签的情况下，设置 rel = noopener 或 noreferrer。
当我们不设置这些 headers 和 rel 时，目标网站可以获得会话令牌和数据库 ID 等数据。
10. 使用有限的浏览器功能和 API
与 CSP 一样，受限域可以连接到网站，同样的原理也可以应用于浏览器功能和 API。我们可以添加一个 Feature-Policy 标头来拒绝访问某些功能和 API。阅读更多。
提示：为您不使用的所有功能设置无。

11. 定期审计依赖
定期运行 npm audit 以获取易受攻击的软件包列表并对其进行升级以避免安全问题。
GitHub 现在标记易受攻击的依赖项。我们还可以使用 Snyk 自动检查您的源代码并打开拉取请求以提升版本。

12. 划分你的应用程序
与后端一样，我们有一个微服务架构，其中单体应用程序被拆分为较小的独立组件，每个组件单独运行。
同样的原理也可以应用于前端。例如，一个应用程序可以分为公共、认证和管理部分，每个部分都托管在单独的子域上，例如 https://public.example.com、https://users.example.com 和 https://admin .example.com 。
这将确保更少的客户端漏洞。
注意：适当的划分还可以防止应用程序的公共部分出现 XSS 漏洞，从而防止它自动泄露用户信息。

13.避免第三方服务
Google Analytics、Google Tag Manager、Intercom、Mixpanel 等第三方服务的一行代码可以使您的 Web 应用程序易受攻击。想想这些第三方服务受到威胁的情况。
制定强有力的 CSP 政策很重要。大多数第三方服务都有定义的 CSP 指令，因此请始终添加它们。
此外，请确保在添加脚本标记时尽可能包含完整性属性。子资源完整性功能可以验证脚本的加密哈希并确保它没有被篡改。