聊聊大前端网络安全那些事

网络安全对前端童鞋来说大多数时候都是听其有之，闻之则无，毕竟在现如今前端如火如荼的时代，大多数东西日益成熟，开箱即用，云服务、框架等已经帮我们做了安全方面的防范，不需要我们去太过于关心前端网络安全，作为一个前端爱好者，最近温习一下这部分知识，做了个简单的总结，顺道呈现给各位看官，请注意查收。

xss攻击

Cross-Site Scripting（跨站脚本攻击）简称 XSS，是一种代码注入攻击。攻击者通过在目标网站上注入恶意脚本，使之在用户的浏览器上运行。利用这些恶意脚本，攻击者可获取用户的敏感信息如 Cookie、SessionID 等，进而危害数据安全。

根据攻击的来源，XSS 攻击可分为存储型、反射型和 DOM 型三种

存储型攻击常发生在微博论坛等用户发帖、提交文章评论等地方

1. 将恶意代码提交到数据库

2. 数据库将其保存

3. 他用户查看帖子或者评论

4. 服务端返回恶意代码并被拼接到客户端页面

5. 恶意代码可能通过自执行或者用户点击执行来弹出广告或者获取用户的cookie等个人隐私并上报到攻击者数据库

反射型攻击主要发生在一些带有诱导性的链接的按钮邮件等

1. 攻击者在一些链接的参数中加入恶意代码并诱导用户点击

2. 用户通过点击将请求参数传入服务端

3. 服务端获取参数并拼接返回给客户端

4. 客户端执行恶意代码冒充用户进行权限操作或者盗取用户的cookie等个人隐私并上报攻击者数据库

1. 攻击者构造出特殊的 URL，其中包含恶意代码。

2. 用户打开带有恶意代码的 URL。

3. 用户浏览器接收到响应后解析执行，前端 JavaScript 取出 URL 中的恶意代码并执行。

4. 恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。

DOM型和反射性都是通过诱导用户点击链接执行，并且都是临时型的，但是反射型属于服务端安全漏洞而DOM型属于客户端安全漏洞

• 客户端对用户输入的内容进行安全符转义，服务端对上交内容进行安全转义

• 服务端渲染开启模板引擎自带的 HTML 转义功能。

• 避免内联事件，尽量不要使用 onLoad="onload('{{data}}')"、onClick="go('{{action}}')" 这种拼接内联事件的写法。在 JavaScript 中通过 .addEventlistener() 事件绑定会更安全。

• 避免拼接 HTML，前端采用拼接 HTML 的方法比较危险，如果框架允许，使用 createElement、setAttribute 之类的方法实现。或者采用比较成熟的渲染框架，如 Vue/React 等。

• 时刻保持警惕在插入位置为 DOM 属性、链接等位置时，要打起精神，严加防范。

• 通过 CSP、输入长度配置、接口安全措施等方法，增加攻击的难度，降低攻击的后果。

• 主动检测和发现，可使用 XSS 攻击字符串和自动扫描工具寻找潜在的 XSS 漏洞。

• 尽量避免三方跨域提交内容到服务端

• HTTP-only Cookie: 禁止 JavaScript 读取某些敏感 Cookie，攻击者完成 XSS 注入后也无法窃取此 Cookie。

• 验证码：防止脚本冒充用户提交危险操作。

CSRF攻击

CSRF（Cross-site request forgery）跨站请求伪造：攻击者诱导受害者进入第三方网站，在第三方网站中，向被攻击网站发送跨站请求。利用受害者在被攻击网站已经获取的注册凭证，绕过后台的用户验证，达到冒充用户对被攻击的网站执行某项操作的目的。

1. 受害者访问a.com并在自己浏览器留下a.com的登录态

2. 攻击者诱导受害者访问三方网站b.com

3. 三方网站b.com植有访问a.com接口的恶意代码（删除/增加/修改等）

4. 受害者点击b.com时候，b.com带着a.com的登陆凭证冒充受害用户执行对a.com的恶意操

1. 攻击者在a.com发布带有恶意链接的帖子或者评论（提交对a.com带有增删改的诱导型img/form/a标签）

2. 当其他拥有登录态的受害者点击该评论的恶意链接冒用受害者登录凭证发起攻击

CSRF主要是冒用受害者登录凭证发起恶意的增删改并不会窃取受害者隐私信息

1. 禁止三方网站获取cookie,比如设置Chrome的SameSite属性

弊端：SameSite试用阶段，兼容性不是很理想

2. 服务端通过Referer Header 和 Origin Header来进行同源验证

弊端1：攻击者可以部分修改或者隐藏referer

<img src="http://bank.example/withdraw?amount=10000&for=hacker" referrerpolicy="no-referrer">

弊端2: 某些浏览器或者操作会丢失origin头部，比如302重定向

弊端3：HTTPS页面跳转到HTTP页面，所有浏览器Referer都丢失。

弊端4：对于被动性攻击并不能识别

其他：某些低版本浏览器对origin和referer并不是很稳定，各种意想不到的结果，极其不稳定

3. 利用token来鉴别，三方跨站请求并不能获取到头部的token，本站的接口在请求前都会在请求头增加token用于身份鉴权，三方请求并不会携带token

弊端1：token鉴权对服务端压力较大，许专门开辟服务器用于token鉴权，耗费服务器成本并且增加请求时间

弊端2：对于页面ajax,fetch等异步请求外的其他请求如form提交，a链接等需要去挨个加token，不能形成统一的token增加入口，存在部分疏漏

相对而言token鉴权算是比较好的一种防护措施

4. 利用双重cookie来认证，在每个请求的参数都附加scrfCookie='随机数'防御参数，并在cookie中混入该防御参数值，服务端将请求头部的cookie中防御cookie参数和请求参数所带的该参数进行比对

弊端：前后分离的代码，后端接口和前端可能不同源，比如前端www.xx.com,后端接口为api.xx.com,前端要拿到后端接口域下的cookie必须将cookie都放在xx.com下面才能保证所有子域都可以拿到，这样反而增加xss攻击风险得不偿失

DOS攻击

DOS攻击通过在网站的各个环节进行攻击，使得整个流程跑不起来，以达到瘫痪服务为目的。最常见的就是发送大量请求导致服务器过载宕机

• 扩容服务器【有钱公司玩的】

• 进行实时监控，封禁某些恶意密集型请求IP段

• 增加接口验证，对于某些敏感接口，进行单个IP访问次数限制

• 进行静态资源缓存，隔离源文件的访问，比如CDN加速

页面劫持

攻击者通过请求的数据传输过程进行数据修改，或者对网站域名进行泛域名解析以重定向网站，在网站中注入广告等

• 最有效且暴力的直接换成HTTPS，建立安全通道

• 进行漏洞监控，根据实际情况做出调整

原文链接:https://juejin.im/post/5e84b14151882573be11b795

【历史文章】：

【入门教程】常见的Web漏洞--XSS

【入门教程】常见的Web漏洞--SQL注入

sql注入--入门到进阶

短信验证码安全常见逻辑漏洞

最全常见Web安全漏洞总结及推荐解决方案

常见的Web应用的漏洞总结（原理、危害、防御）

代码审计常见漏洞总结

Web安全漏洞的靶场演示

13 款 Linux 比较实用的工具

xss攻击、绕过最全总结

学习更多技术，关注我：

觉得文章不错给点个‘再看’吧

原文始发于微信公众号（编码安全研究）：聊聊大前端网络安全那些事