web前端安全攻防揭秘

web前端安全攻防揭秘

Web安全的关键点
1.数据与指令
2.浏览器的同源策略
3.信任与信任关系
4.社会工程学的作用
5.攻防不单一
6.场景很重要

web前端安全最受关注的三种前端攻击包括：XSS攻击、CSRF攻击、界面操作劫持

1. XSS攻击

1.1. Cross Site Script（跨站脚本攻击 ）
恶意攻击者往Web页面里插入恶意Script代码，当用户浏览该页之时，嵌入其中Web里面的Script代码会被执行，从而达到恶意攻击用户的目的。

1.2. XSS攻击可以分成两种类型：
1.非持久型XSS
2.持久型XSS

1.2.1. 非持久型XSS
非持久型XSS攻击：顾名思义，非持久型xss攻击是一次性的，仅对当次的页面访问产生影响。非持久型xss攻击要求用户访问一个被攻击者篡改后的链接，用户访问该链接时，被植入的攻

击脚本被用户游览器执行，从而达到攻击目的。

非持久型XSS漏洞攻击特征：
即时性，不经过服务器存储，直接通过 HTTP 的 GET 和 POST 请求就能完成一次攻击，拿到用户隐私数据
攻击者需要诱骗点击
反馈率低，所以较难发现和响应修复
盗取用户敏感保密信息

防止出现非持久型 XSS 漏洞，注意事项：

•  Web 页面渲染的所有内容或者渲染的数据都必须来自于服务端。
•  尽量不要从 URL，document.referrer，document.forms 等这种 DOM API 中获取数据直接渲染。
•  尽量不要使用 eval, new Function()，document.write()，document.writeln()，window.setInterval()，window.setTimeout()，
• innerHTML，document.creteElement() 等可执行字符串的方法。    
•  如果做不到以上几点，也必须对涉及 DOM 渲染的方法传入的字符串参数做 escape 转义。

       
前端渲染的时候对任何的字段都需要做 escape 转义编码。
       
escape 转义的目的是将一些构成 HTML 标签的元素转义，比如 <，>，空格 等，转义成 <，>，  等显示转义字符。有很多开源的工具可以协助我们做 escape 转义。

1.2.2 持久型XSS
持久型xss，会把攻击者的数据存储在服务器端，攻击行为将伴随着攻击数据一直存在。

持久型 XSS可以分为三类：
反射型XSS、存储型XSS、DOM型XSS

Reflected XSS (反射型XSS)：
基于反射的XSS攻击，主要依靠站点服务端返回脚本，在客户端触发执行从而发起Web攻击。Web客户端使用Server端脚本生成页面为用户提供数据时，如果未经验证的用户数据被包含在页
面中而未经HTML实体编码，客户端代码便能够注入到动态页面中

Stored XSS (存储型XSS)：
该类型是应用最为广泛而且有可能影响到Web服务器自身安全的漏洞，骇客将攻击脚本上传到Web服务器上，使得所有访问该页面的用户都面临信息泄漏的可能，其中也包括了Web服务器的管理员。

DOM XSS (DOM或本地的XSS)：
本地利用漏洞，这种漏洞存在于页面中客户端脚本自身。
DOM—based XSS漏洞是基于文档对象模型Document Objeet Model,DOM)的一种漏洞,dom - xss是通过url传入参数去控制触发的。

持久型 XSS 有以下几个特点 :
持久性，植入在数据库中
危害面广，甚至可以让用户机器变成 DDoS 攻击的肉鸡。
盗取用户敏感私密信息

持久型XSS攻击成功，需要同时满足以下几个条件 :
POST 请求提交表单后端没做转义直接入库。
后端从数据库中取出数据没做转义直接输出给前端。
前端拿到后端数据没做转义直接渲染成 DOM。

1.3. XSS防御

1.3.1. 完善的过滤体系(不要信任任何外部传入的数据)

永远不相信用户的输入:
防范Web前端攻击的一个重要的常识是：永远也不要相信用户输入的数据，一定要针对用户输入作相关的格式检查、过滤等操作，防止任何可能的前端注入。
只允许输入合法的值，其它值一概过滤掉。

不要信任任何传入的第三方数据
在前端开发设计中，经常会加载第三方传入的数据。但由于浏览器同源策略的限制，JavaScript是不能直接加载第三方域的数据的，不过，有几种常用的技术可以绕过这样的限制。其中，传统的方式是通过使用JSONP ，这项技术利用了浏览器可以加载第三方JavaScript脚本的特性。

不要仅仅靠JavaScript代码来阻止注入
如果用户输入的数据要保存到后端数据库中，则仅仅依靠JavaScript代码来校验用户输入的数据是不够的。因为JavaScript代码本身太容易被攻击者拦截和修改了，用户甚至可以不通过页面而直接和后端连接，所以在后端的代码中也需要进行必要的数据校验操作，并且检查校验的力度比前端要更严格。

1.3.2. 基于 Flash 的跨站 XSS攻击预防

基于 Flash 的跨站 XSS 也是属于反射型 XSS 的一种，FLASH中AS 脚本可以接受用户输入并操作cookie，攻击者可以配合其他XSS（持久型或者非持久型）方法将恶意 swf 文件嵌入页面中。主要是因为 AS 有时候需要和 JS 传参交互，攻击者会通过恶意的 XSS 注入篡改参数，窃取并操作cookie。

避免方法 :
严格管理 cookie 的读写权限
对 Flash 能接受用户输入的参数进行过滤 escape 转义处理

1.3.3. 未经验证的跳转 XSS攻击预防
有一些场景是后端需要对一个传进来的待跳转的 URL 参数进行一个 302 跳转，可能其中会带有一些用户的敏感（cookie）信息。如果服务器端做302 跳转，跳转的地址来自用户的输入，攻击者可以输入一个恶意的跳转地址来执行脚本。

通过以下方式来防止这类漏洞 :
对待跳转的 URL 参数做白名单或者某种规则过滤
后端注意对敏感信息的保护, 比如 cookie 使用来源验证。

2. CSRF攻击

2.1.CSRF（Cross-Site Request Forgery）跨站请求伪造攻击
攻击者可以盗用你的登陆信息，以你的身份模拟发送各种请求。攻击者只要借助少许的社会工程学的诡计，例如通过 QQ 等聊天软件发送的链接(有些还伪装成短域名，用户无法分辨)，攻击者就能迫使 Web 应用的用户去执行攻击者预设的操作。例如，当用户登录网络银行去查看其存款余额，在他没有退出时，就点击了一个 QQ 好友发来的链接，那么该用户银行帐户中的资金就有可能被转移到攻击者指定的帐户中。
所以遇到 CSRF 攻击时，将对终端用户的数据和操作指令构成严重的威胁。当受攻击的终端用户具有管理员帐户的时候，CSRF 攻击将危及整个 Web 应用程序。

2.2. CSRF 原理：
可以理解为有一个小偷在你配钥匙的地方得到了你家的钥匙，然后拿着要是去你家想偷什么偷什么。

2.3.CSRF 攻击必须要有三个条件 :

• 用户已经登录了站点 A，并在本地记录了 cookie    
• 在用户没有登出站点 A 的情况下（也就是 cookie 生效的情况下），访问了恶意攻击者提供的引诱危险站点 B (B 站点要求访问站点A)。
• 站点 A 没有做任何 CSRF 

2.4. CSRF防御

• 验证 HTTP Referer 字段
• 在请求地址中添加 token 并验证
• 在 HTTP 头中自定义属性并验
• 正确使用GET,POST和Cookie
• 在非GET请求中增加伪随机数

3. 界面操作劫持攻击
界面操作劫持攻击是一种基于视觉欺骗的Web会话劫持攻击，它通过在网页的可见输入控件上覆盖一个不可见的框（例如：css外观伪装，iframe嵌套），让用户以为在操作可见控件，但是实际上用户的操作行为被其不可见的框所劫持，执行不可见框中的恶意劫持代码，从而完成在用户不知情的情况下窃取敏感信息，篡改数据等攻击。

3.1. 劫持分类：
点击劫持、拖放劫持、触屏劫持

3.1.1.点击劫持
劫持用户的鼠标点击操作。

3.1.2.点击劫持
在浏览器中，拖放操作是不受同源策略限制的，用户可以把一个域的内容拖放到另一个不同的域。在现在的Web应用中，有一些需要用户采用鼠标拖放完成的操作，而且用户也经常在浏览器中使用鼠标拖放操作来代替复制粘贴。因此，拖放操作劫持很大程度的扩展了点击劫持的攻击范围，也将劫持模式从单纯的鼠标点击扩展到了鼠标拖放行为。

3.1.3.点击劫持
移动智能终端设备由于体积限制，一般都没有鼠标、键盘这些输入设备，用户更多的操作是依靠手指在触屏上的点击或滑动等动作完成。在移动设备上，类似点击劫持的攻击模式，实现了对用户触摸屏操作的劫持攻击。

3.2. 界面操作劫持技术原理分析

透明层+iframe：

• 透明层使用CSS样式实现
• 使用iframe来嵌入被劫持的页面

触屏劫持技术的实现：

• 桌面浏览器
• 可视区域viewport
• 隐藏URL地址栏
• 触屏函数

3.3.操作劫持攻击危害
界面操作劫持实际上突破了CSRF的防御策略，这是一种社工色彩很强的跨域操作，而这种跨域正好是浏览器自身的特性，他带来的危害可以很大，比如，篡改与删除数据，偷取隐私甚至爆发蠕虫。

3.4.操作劫持防御

针对传统的界面劫持，通过禁止iframe来防范：

HTTP头中有一个响应头X-Frame-Options，有三个值可以选择：

• DENY：该页面不允许加载任何 iframe页面。
• SAMEORIGIN：该页面可以加载相同域名的 iframe页面。
• ALLOW-FROM uri：该页面可以加载指定来源的 iframe页面。

4. HTML5安全
HTML5中新增的一些标签和属性，使得XSS等Web攻击产生了新的变化，在HTML5 Security Cheatsheet中总结了这些变化。

4.1. 隐藏URL恶意代码
反射型XSS中，会将恶意代码写在URL参数中，这样的话，用户也能看到恶意代码，例如下面的链接：
http://www.csrf.net/csrf.html?id=<script>111</script>
可以通过window.history来操作浏览器的历史记录。

pushState()有三个参数：状态对象、标题，可选的URL地址。
history.pushState({},"", location.href.split('?').shift());
执行上面那段代码后就会将参数隐藏。

“pushState”还可以伪造浏览器历史记录。
for(i=0; i<10; i++)
    history.pushState({},"", "/"+i+".html");

4.2.  HTML5下的僵尸网络
僵尸网络（Botnet）是指在大量的计算机中植入特定的恶意程序，使控制者能够通过若干计算机直接向其他计算机发送指令，进行网络攻击。
基于Web前端的僵尸网络可以用作DDOS攻击，这里涉及Web Worker技术和CORS处理机制，再通过Web蠕虫传播。
Web Worker是一种多线程机制，可以异步执行恶意JS代码，而不影响用户在浏览器中的正常操作。
CORS处理机制工作在浏览器层面，如果服务器不允许跨站，浏览器将拦截服务器返回的结果，也就是说跨域请求，服务器也会正常响应。
那么就可以事先写好一段异步请求的脚本（worker.js），然后通过Web Worker来执行这段脚本，不断的向目标服务器发起请求。

5. 其他web安全

5.1. SQL注入

SQL 注入漏洞（SQL Injection）是 Web 开发中最常见的一种安全漏洞。可以用它来从数据库获取敏感信息，或者利用数据库的特性执行添加用户，导出文件等一系列恶意操作，甚至有可能获取数据库乃至系统用户最高权限。
而造成 SQL 注入的原因是因为程序没有有效的转义过滤用户的输入，使攻击者成功的向服务器提交恶意的 SQL 查询代码，程序在接收后错误的将攻击者的输入作为查询语句的一部分执行，导致原始的查询逻辑被改变，额外的执行了攻击者精心构造的恶意代码。

5.2. 钓鱼攻击【重定向攻击】
攻击者会发送给受害者一个合法链接，当链接被点击时，用户被导向一个似是而非的非法网站，从而达到骗取用户信任、窃取用户资料的目的。

防御措施 :
对所有的重定向操作进行审核,以避免重定向到一个危险的地方。

常见解决方案是白名单,将合法的要重定向的url加到白名单中,非白名单上的域名重定向时拒之;
重定向token,在合法的url上加上token,重定向时进行验证。

5.3. Http Heads攻击
HTTP协议在Response header和content之间，有一个空行，即两组CRLF（0x0D 0A）字符。这个空行标志着headers的结束和content的开始。“聪明”的攻击者可以利用这一点。只要攻击者有办法将任意字符“注入”到headers中，这种攻击就可以发生。

防御措施 :
过滤所有的response headers，除去header中出现的非法字符，尤其是CRLF。

5.4. 文件上传攻击
用户上传一个可执行的脚本文件，并通过此脚本文件获得了执行服务端命令的能力。

文件上传攻击分类：
文件名攻击、文件后缀攻击、文件内容攻击

5.4.1. 文件名攻击
上传的文件采用上传之前的文件名,可能造成客户端和服务端字符码不兼容,导致文件名乱码问题;文件名包含脚本,从而造成攻击。

5.4.2. 文件后缀攻击
上传的文件的后缀可能是exe可执行程序,js脚本等文件,这些程序可能被执行于受害者的客户端,甚至可能执行于服务器上.因此我们必须过滤文件名后缀,排除那些不被许可的文件名后缀。

5.4.3. 文件内容攻击
IE6有一个很严重的问题 , 它不信任服务器所发送的content type，而是自动根据文件内容来识别文件的类型，并根据所识别的类型来显示或执行文件.如果上传一个gif文件,在文件末尾放一段js攻击脚本,就有可能被执行.这种攻击,它的文件名和content type看起来都是合法的gif图片,然而其内容却包含脚本,这样的攻击无法用文件名过滤来排除，而是必须扫描其文件内容，才能识别。

防御措施:

• 文件上传的目录设置为不可执行。
• 判断文件类型。在判断文件类型的时候，可以结合使用MIME Type，后缀检查等方式。因为对于上传文件，不能简单地通过后缀名称来判断文件的类型，因为攻击者可以将可执行文件的后缀名称改为图片或其他后缀类型，诱导用户执行。
• 对上传的文件类型进行白名单校验，只允许上传可靠类型。
• 上传的文件需要进行重新命名，使攻击者无法猜想上传文件的访问路径，将极大地增加攻击成本。
• 限制上传文件的大小。
• 单独设置文件服务器的域名。

6. 关于前端安全防御总结

6.1. 浏览器厂商的防御

HTTP相应的X-头部

防止网页被别人的网站iframe，我们可以通过在服务端设置HTTP头部中的X-Frame-Options信息。

X-Frame-Options 响应头有三个可选的值：

• DENY：页面不能被嵌入到任何iframe或frame中；
• SAMEORIGIN：页面只能被本站页面嵌入到iframe或者frame中；
• ALLOW-FROM：页面允许frame或frame加载。

在服务端设置的方式如下：

Java代码:
response.addHeader("x-frame-options","SAMEORIGIN");
Nginx配置:
add_header X-Frame-Options SAMEORIGIN
Apache配置:
Header always append X-Frame-Options SAMEORIGIN

迟到的CSP策略
CSP全称Content Security Policy ,可以直接翻译为内容安全策略,说白了,就是为了页面内容安全而制定的一系列防护策略. 通过CSP所约束的的规责指定可信的内容来源（这里的内容可以指脚本、图片、iframe、fton、style等等可能的远程的资源）。通过CSP协定，让WEB处于一个安全的运行环境中。

CSP有什么用?

我们知道前端有个很著名的”同源策略”,简而言之,就是说一个页面的资源只能从与之同源的服务器获取,而不允许跨域获取.这样可以避免页面被注入恶意代码,影响安全.但是这个策略是个双刃剑,挡住恶意代码的同时也限制了前端的灵活性,那有没有一种方法既可以让我们可以跨域获取资源,又能防止恶意代码呢?

答案是当然有了,这就是csp,通过csp我们可以制定一系列的策略,从而只允许我们页面向我们允许的域名发起跨域请求,而不符合我们策略的恶意攻击则被挡在门外，从而实现。
需要说明的一点是,目前主流的浏览器都已支持csp.所以我们可以放心大胆的用了。

指令说明
指令就是csp中用来定义策略的基本单位,我们可以使用单个或者多个指令来组合作用,功能防护我们的网站.

6.2. WEB厂商的防御
域分离：
不同的子域进行安全划分，防止相互任一子域安全风险影响到其他子域的安全。

安全传输：
安全传输可以有效第防止局域网内的明文抓包。

安全的cookie：
严格设置HTTPS传输，肯定是HttpOnly标志，这样XSS即使盗取了Cookie，也无法正确使用。

优秀的验证码：
Google的验证码公认是比较安全的（字母连着、扭曲变形、线条平滑、无噪等），包里破解很困难，也带来了用户体验的尴尬，经常会输错验证码。

谨防第三方内容：
<script>引用第三方js文件
<iframe>引用第三方HTML文件
<objet>等引入第三方Flash等资源

XSS防御方案：
输入校验
输出编码

CSRF防御方案：
1. 检查HTTP Referer字段是否同域
2. 限制Session Cookie的生命周期
3. 使用验证码
4. 使用一次性token

界面操作劫持防御：
X-Frame-Options防御
Frame Busting脚本防御
使用token进行防御

6.3 用户的防御
关于用户防御，我们一直强调的是意识为先。很多人对web前端攻击并不了解，缺少安全意识。

使用安全浏览器组合：

Firefox浏览器+NoScript插件

遵守信任最小原则

参考文档：
1.《web前端黑客技术揭秘》
2. https://www.jianshu.com/p/303206ae2471
3. https://blog.csdn.net/vivian_jay/article/details/58667283
4. https://www.cnblogs.com/heyuqing/p/6215761.html

本文固定链接: http://www.webzsky.com/?p=1345 | 蓝戒的博客