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

目录

一、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 sandbox src="..."> ... </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脚本的处理。

<script src="https://example.js"
 integrity="sha384-eivAQsRgJIi2KsTdSnfoEGIRTo25NCAqjNJNZalV63WKX3Y51adIzLT4So1pk5tX"></script>

八、本地存储数据泄露

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

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

防御措施总结

1、谨慎用户输入信息，进行输入检查（客户端和服务端同时检查）

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

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

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

5、当有<frame><iframe><object>时，合理设置X-Frame-Options HTTP响应头，添加sanbox属性等

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

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

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