> 文档中心 > 前端常见安全问题及解决方法

前端常见安全问题及解决方法

目录

一、XSS (Cross-Site Scripting)跨站脚本攻击

二、CSRF (Cross-site request forgery) 跨站请求伪造

三、iframe风险

四、点击劫持

五、第三方依赖包带来的问题

六、https 存在的风险

七、CDN劫持

八、本地存储数据泄露

防御措施总结


一、XSS (Cross-Site Scripting)跨站脚本攻击

定义:

XSS(Cross Site Scripting,跨站脚本),即攻击者往 Web 页面里嵌入恶意的客户端脚本,当用户浏览此网页时,脚本就会在用户的浏览器上执行,进而达到攻击者的目的。【获取用户的 Cookie、导航到恶意网站、携带木马】

解决方案

1、对输入和 URL 参数进行过滤,过滤掉会导致脚本执行的相关内容。
2、对动态输出到页面的内容进行 html 编码,使脚本无法在浏览器中执行。

二、CSRF (Cross-site request forgery) 跨站请求伪造

定义:

CSRF(Cross Site Request Forgery,跨站请求伪造),即在别的站点伪造了一个请求,在受害者访问一个网站时,其 cookie 还没有过期的情况下,攻击者伪造一个链接地址发送受害者并欺骗让其点击,从而形成 CSRF 攻击。

防御
1、验证 HTTP 的 Referer 字段。
2、在请求地址中添加 token 并验证。
3、在 HTTP 头中自定义属性并验证。
4、涉及到数据修改操作严格使用 post 请求而不是 get 请求。

get 的 URL 会被放在浏览器历史和 WEB 服务器日志里面,如果把关键数据放在 get 里面,被人偷窥了浏览器,会造成数据泄露。而 post 日志没有记录,也不会保留 URL,只要数据库服务器不被入侵,基本还是安全的。

三、iframe风险

        前端页面需要用到第三方提供的页面组件,通常会以 iframe 的方式引入,比如广告插件等。这些第三方提供的插件可以运行 js 脚本、flash 插件等,破坏用户体验。

防御
iframe 中有一个叫做 sandbox 的安全属性,通过它可以对 iframe 的行为进行各种限制,充分实现“最小权限”原则。

 ... 

四、点击劫持

        通过 iframe 使用别人提供的内容时,自己的页面也可能正在被不法分子放到他们精心构造的 iframe 中,进行点击劫持攻击。这是一种欺骗性强、用户参与高的攻击。

通常的攻击步骤是这样的:
1、攻击者构造一个诱导用户点击的内容,比如页面小游戏。
2、将我们的页面放入到 iframe 当中。
3、利用 z-index 等 CSS 样式将这个 iframe 叠加到小游戏的垂直方向的正上方。
4、把 iframe 设置为100%透明度。
5、受害者访问到这个页面后,肉眼看到的是一个小游戏,如果受到诱导进行了点击的话,实际上点击到的却是 iframe 中的我们自己的页面。

危害
攻击者利用了受害者的用户身份,在其不知情的情况下进行一些操作。如果是删除某个重要文件记录,或者窃取敏感信息,那么造成的危害就难以承受。

防御
1、使用 X-Frame-Options:DENY 这个 HTTP Header 来明确的告知浏览器,不要把当前HTTP响应中的内容在HTML Frame 中显示出来。
2、判断当前页面是否被嵌入到 iframe 中。

if(top.location != self.location){  // 强制跳转  top.location.href = 'http://www.baidu.com'}

五、第三方依赖包带来的问题

        现在绝大多数的开发都是在借助开发框架和各种类库进行快速开发。这样做虽然方便快速,但是与此同时也存在安全风险,如果这些来自第三方的代码有安全漏洞,那么对应用整体的安全性依然会造成严峻的挑战。
比如 Node.js 有一些已知的安全漏洞,比如 CVE-2017-11499,可能导致前端应用受到 DoS 攻击。

防御
使用 NSP(Node Security Platform)、Snyk 等等这类工具。

六、https 存在的风险

        即使是服务器端开启了 https,也还是存在安全隐患,黑客可以利用 SSL Stripping 这种攻击手段,强制让 https 降级回 http,从而继续进行中间人攻击。

过程
1、用户在浏览器里输入 URL 的时候往往不是从 https:// 开始的,而是直接从域名开始输入;
2、随后浏览器向服务器发起 http 通信;
3、攻击者把服务器端返回的跳转到 https 页面的响应拦截了,并且代替客户端和服务器端进行后续的通信。

防御
使用 HSTS(HTTP Strict Transport Security),通过 HTTP Header 以及一个预加载的清单,来告知浏览器在和网站进行通信的时候强制性使用 HTTPS,而不是通过明文的HTTP进行通信。并且当遇到证书或者链接不安全的时候,则首先警告用户,并且不再让用户继续进行不安全的通信。

七、CDN劫持

        出于性能考虑,前端应用通常会把一些静态资源存放到 CDN 上面,例如 JS 脚本和 Stylesheet 文件,可以显著提高前端应用的访问速度,但与此同时也隐含了一个新的安全风险。如果攻击者劫持了 CDN,那么前端应用拿到的就是有问题的 JS 脚本或者 Stylesheet 文件,使得攻击者可以肆意篡改前端页面,对用户实施攻击。

这种攻击方式和 XSS 跨站脚本攻击有些相似,不过不同点在于攻击者是从 CDN 开始实施的攻击,而传统的 XSS 攻击则是从有用户输入的地方开始攻击的。

防御
使用浏览器提供的 SRI(Subresource Integrity)功能。

每个资源文件都可以有一个 SRI值,它由两部分组成,“-” 左侧是生成 SRI 值用到的哈希算法名,右侧是经过Base64 编码后的该资源文件的 Hash 值。浏览器在处理这个 script 元素的时候,就会检查对应的 JS 脚本文件的完整性,看其是否和 script 元素中 integrity 属性指定的 SRI 值一致,如果不匹配,浏览器则会中止对这个JS脚本的处理。

八、本地存储数据泄露

        现在存储在前端也就是用户浏览器中的数据量逐渐增多。前端应用是完全暴露在用户以及攻击者面前的,在前端存储任何敏感、机密的数据,都会面临泄露的风险。

防御
加密,不要存储在前端本地

防御措施总结

1、谨慎用户输入信息,进行输入检查(客户端和服务端同时检查)

2、在变量输出到HTML页面时,都应该进行编码或转义来预防XSS攻击

3、该用验证码的时候一定要添上

4、尽量在重要请求上添加Token参数,注意Token要足够随机,用足够安全的随机数生成算法

5、当有时,合理设置X-Frame-Options HTTP响应头,添加sanbox属性等

6、检查验证请求来源,对每一个重要的操作都进行重新验证

7、不要将重要文件、备份文件存放在公众可以访问到的地方

8、安全防御的体系是相辅相成、缺一不可的