当前位置:   article > 正文

前端所有安全问题总结_前端安全问题

前端安全问题

一、XSS 攻击

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

防御

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

二、CSRF 攻击

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>
  • 1

四、点击劫持

通过 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'
}
  • 1
  • 2
  • 3
  • 4

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

现在绝大多数的开发都是在借助开发框架和各种类库进行快速开发。这样做虽然方便快速,但是与此同时也存在安全风险,如果这些来自第三方的代码有安全漏洞,那么对应用整体的安全性依然会造成严峻的挑战。
比如 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

八、本地存储数据泄露

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

防御

尽量不在前端存储信息。

参考文章:https://www.cnblogs.com/zhengzhaoxiang/p/13977075.html

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/凡人多烦事01/article/detail/164462
推荐阅读
相关标签
  

闽ICP备14008679号