前端开发人员_前端开发人员的10个安全提示

前端开发人员

Web安全是前端开发人员经常忽略的主题。 当我们评估网站的质量时,我们通常会查看性能,SEO友好性和可访问性等指标,而网站抵御恶意攻击的能力通常会受到关注。 即使敏感的用户数据存储在服务器端,后端开发人员也必须采取重要措施保护服务器,但最终,确保数据安全的责任在后端和前端之间共享。 虽然敏感数据可以安全地锁定在后端仓库中,但是前端将密钥保持在其前门上,窃取它们通常是获得访问权限的最简单方法。

“保护用户数据的责任在后端和前端之间共享。”

恶意用户可以采取多种攻击手段来破坏我们的前端应用程序,但是幸运的是,我们可以通过仅配置几个正确的响应头并遵循良好的开发实践,在很大程度上减轻此类攻击的风险。 在本文中,我们将介绍10种简单的操作,您可以通过这些简单的操作来改善对Web应用程序的保护。

测量结果

在我们开始改善网站安全性之前,重要的是要对我们所做更改的有效性提供一些反馈。 尽管很难量化构成“良好开发实践”的要素,但可以非常准确地测量安全头的强度。 就像我们使用Lighthouse获取性能,SEO和可访问性分数一样,我们可以使用SecurityHeaders.com根据当前响应标头获取安全性分数。 对于不完美的分数,它还将为我们提供一些有关如何提高分数并因此增强安全性的提示:

SecurityHeaders可以给我们的最高分数是“ A +”,我们应该始终为此努力。

注意响应头

处理响应标头曾经是后端的任务,但是如今,我们经常将Web应用程序部署到ZeitNetlify之类的“无服务器”云平台,并将它们配置为返回正确的响应标头成为前端责任。 确保了解您的云托管提供商如何使用响应标头,并进行相应配置。

安防措施

1.使用强大的内容安全策略

声音内容安全策略(CSP)是前端应用程序中安全性的基石。 CSP是浏览器中引入的一种标准,用于检测和缓解某些类型的代码注入攻击,包括跨站点脚本(XSS)和点击劫持。

强大的CSP可能会禁用潜在有害的内联代码执行,并限制从中加载外部资源的域。 您可以通过将Content-Security-Policy标头设置为以分号分隔的指令列表来启用CSP。 如果您的网站不需要访问任何外部资源,则标题的起始值可能看起来像这样:

Content-Security-Policy:default -src 'none' ; script-src 'self' ; img-src 'self' ; style-src 'self' ; connect-src 'self' ;

在这里,我们将script-srcimg-srcstyle-srcconnect-src指令设置为self以指示所有脚本,图像,样式表和fetch调用分别应限制为HTML文档的来源。 任何其他未明确提及的CSP指令将回退到default-src指令指定的default-src 。 我们将其设置为none表示默认行为是拒绝任何URL的连接。

但是,如今几乎没有任何Web应用程序是自包含的,因此您可能需要调整此标头以允许使用其他受信任的域,例如Google Fonts或AWS S3存储桶的域,但始终最好从以下开始最严格的政策,并在需要时稍后放宽。

您可以在MDN网站上找到CSP指令的完整列表。

2.启用XSS保护模式

如果确实从用户输入中注入了恶意代码,我们可以通过提供"X-XSS-Protection": "1; mode=block"标头来指示浏览器阻止响应。

尽管大多数现代浏览器默认情况下都启用了XSS保护模式,并且我们也可以使用内容安全策略来禁用内联JavaScript,但仍建议使用X-XSS-Protection标头,以确保不使用内置JavaScript的旧版浏览器具有更好的安全性不支持CSP标头。

3.禁用iframe嵌入以防止点击劫持攻击

点击劫持是一种攻击,其中欺骗了网站A上的用户对网站B进行某些操作。为此,恶意用户将网站B嵌入到不可见的iframe中,然后将其放置在网站A上毫无疑问的用户光标下方,因此当用户点击,或者认为他们点击了网站A上的元素,实际上是点击了网站B上的某个内容。

我们可以通过提供X-Frame-Options标头来防止此类攻击,该标头禁止在框架中呈现网站:

"X-Frame-Options" : "DENY"

另外,我们可以使用frame-ancestors CSP指令,该指令可以更好地控制父级可以或不能将页面嵌入到iframe中。

4.限制对浏览器功能和API的访问

良好安全实践的一部分是限制访问对正确使用我们的网站所不需要的任何内容。 我们已经使用CSP应用了此原理来限制允许网站连接的域数量,但也可以将其应用于浏览器功能。 我们可以使用Feature-Policy标头指示浏览器拒绝访问我们的应用程序不需要的某些功能和API。

我们将Feature-Policy设置为一串用分号分隔的规则,其中每个规则都是功能的名称,后跟其策略名称。

"Feature-Policy" : "accelerometer 'none'; ambient-light-sensor 'none'; autoplay 'none'; camera 'none'; encrypted-media 'none'; fullscreen 'self'; geolocation 'none'; gyroscope 'none'; magnetometer 'none'; microphone 'none'; midi 'none'; payment 'none';  picture-in-picture 'none'; speaker 'none'; sync-xhr 'none'; usb 'none'; vr 'none';"

Smashing Magazine上有一篇很棒的文章详细解释了Feature-Policy ,但是大多数时候,您不希望为所有不使用的功能设置none功能。

5.不要泄漏引荐来源网址的值

当您单击离开您的网站的链接时,目标网站将在referrer标头中收到您网站上最后一个位置的URL。 该URL可能包含敏感数据和半敏感数据(例如会话令牌和用户ID),这些数据永远都不应公开。

为了防止referrer值泄漏,我们将Referrer-Policy标头设置为no-referrer

"Referrer-Policy" : "no-referrer"

在大多数情况下,此值应该很好,但是如果您的应用程序逻辑要求您在某些情况下保留引荐来源,请查看Scott Helme的这篇文章,其中他分解了所有可能的标头值以及何时应用它们。

6.不要基于用户输入设置innerHTML值

跨站点脚本攻击可以通过许多不同的DOM API进行,其中恶意代码被注入到网站中,但是最常用的是innerHTML

您永远不应基于用户未过滤的输入来设置innerHTML 。 用户可以直接操作的任何值-输入字段中的文本,URL中的参数或本地存储条目-应该先进行转义和清理。 理想情况下,使用textContent而不是innerHTML可以完全避免生成HTML输出。 如果确实需要为用户提供富文本编辑,请使用建立良好的库,该库使用白名单而非黑名单来指定允许HTML标签。

不幸的是, innerHTML并不是DOM API的唯一弱点,而且容易受到XSS注入攻击的代码仍然难以检测。 这就是为什么始终具有禁止内联代码执行的严格内容安全策略很重要的原因。

将来,您可能希望关注新的Trusted Types规范 ,该规范旨在防止所有基于DOM的跨站点脚本攻击。

7.使用UI框架

诸如React,Vue和Angular之类的现代UI框架内置了良好的安全性,可以很大程度上消除XSS攻击的风险。 他们自动编码HTML输出,减少需要使用XSS敏感的DOM API,并给予明确和注意名称潜在危险的方法,如dangerouslySetInnerHTML

8.保持最新状态

快速浏览一下node_modules文件夹将确认我们的Web应用程序是由数百(如果不是数千)依赖关系构建而成的难题。 确保这些依赖项不包含任何已知的安全漏洞对于网站的整体安全非常重要。

确保依赖关系保持安全和最新的最佳方法是使漏洞检查成为开发过程的一部分。 为此,您可以集成DependabotSnyk之类的工具,这些工具将为过时或潜在脆弱的依赖项创建提取请求,并帮助您更快地应用修补程序。

9.添加第三方服务之前请三思

诸如Google Analytics(分析),Intercom,Mixpanel和其他一百种第三方服务可以为您的业务需求提供“一行代码”解决方案。 同时,它们会使您的网站更容易受到攻击,因为如果第三方服务受到损害,那么您的网站也会受到损害。

如果您决定集成第三方服务,请确保设置最强大的CSP策略,该策略仍将允许该服务正常运行。 大多数流行的服务都记录了它们所需的CSP指令,因此请务必遵循其准则。

使用Google跟踪代码管理器,细分或任何其他允许组织中任何人集成更多第三方服务的工具时,都应格外小心。 有权使用此工具的人员必须了解连接其他服务的安全隐患,并且最好与开发团队进行讨论。

10.将子资源完整性用于第三方脚本

对于您使用的所有第三方脚本,请确保在可能的情况下包括integrity属性。 浏览器具有“子资源完整性”功能,该功能可以验证您正在加载的脚本的加密哈希,并确保它未被篡改。

您的script标签如下所示:

< script src = "https://example.com/example-framework.js"
        integrity = "sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/ux..."
        crossorigin = "anonymous" >  </ script >

值得澄清的是,该技术对第三方库很有用,但对第三方服务的作用较小。 在大多数情况下,当您为第三方服务添加脚本时,该脚本仅用于加载另一个从属脚本。 无法检查依赖脚本的完整性,因为可以随时对其进行修改,因此在这种情况下,我们必须依靠严格的内容安全策略。

结论

保存浏览体验是任何现代Web应用程序的重要组成部分,并且用户希望确保其个人数据保持安全和私密。 而且,尽管这些数据存储在后端,但保护数据的责任也扩展到了客户端应用程序。

恶意用户可以利用多种UI优先攻击,但是,如果按照本文中的建议进行操作,则可以大大提高防御它们的机会。

要获得更多像这样的编程教程,请注册我的每月时事通讯

先前发布在https://konstantinlebedev.com/security-for-frontend/

翻译自: https://hackernoon.com/10-security-tips-for-frontend-developers-oi4624ld

前端开发人员

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值