高级之路篇十二：全面解析web安全及防御方法

web安全常见的8大板块：

• 老生常谈的XSS跨站脚本攻击
• 警惕iframe带来的风险
• 别被点击劫持了
• 错误的内容推断
• 防火防盗防猪队友：不安全的第三方依赖包
• 用了HTTPS也可能掉坑里
• 本地存储数据泄露
• 缺失静态资源完整性校验

XSS跨站脚本攻击

1.绕过XSS-Filter，利用<>标签注入Html/JavaScript代码；

2.利用HTML标签的属性值进行xss攻击。例如：<img src=“javascript:alert(‘xss’)”/>；（当然并不是所有的Web浏览器都支持Javascript伪协议，所以此类XSS攻击具有一定的局限性）

3. 空格、回车和Tab。如果XSS Filter仅仅将敏感的输入字符列入黑名单，比如javascript，用户可以利用空格、回车和Tab键来绕过过滤，例如：<img src=“javas  cript:alert(/xss/);”/>；

4. 利用事件来执行跨站脚本。例如：<img src=“#” onerror= “alert(1)”/>，当src错误的视乎就会执行onerror事件；

5. 利用CSS跨站。例如：Body {backgrund-image: url(“javascript:alert(‘xss’)”)}；

6. 扰乱过滤规则。例如：<IMG SRC=“javaSCript: alert(/xss/);”/>；

7.利用字符编码，透过这种技巧，不仅能让XSS代码绕过服务端的过滤，还能更好地隐藏Shellcode；（JS支持unicode、eacapes、十六进制、十进制等编码形式）

8.拆分跨站法，将xss攻击的代码拆分开来，适用于应用程序没有过滤 XSS关键字符（如<、>）却对输入字符长度有限制的情况下；

9.DOM型的XSS主要是由客户端的脚本通过DOM动态地输出数据到页面上，它不依赖于提交数据到服务器，而是从客户端获得DOM中的数据在本地执行。容易导致DOM型的XSS的输入源包括：Document.URL、Location(.pathname|.href|.search|.hash)、

Document.referrer、Window.name、Document.cookie、localStorage/globalStorage；

如何防御：

原则：不相信客户输入的数据

注意:  攻击代码不一定在<script></script>中

1、输入过滤

2、HttpOnly Cookie

将重要的cookie标记为http only,   这样的话当浏览器向Web服务器发起请求的时就会带上cookie字段，但是在脚本中却不能访问这个cookie，这样就避免了XSS攻击利用JavaScript的document.cookie获取cookie：

过滤: JavascriptEncode ,CSSEncode ,HTMLEncode ,URLEncode

function HTMLEncode(html) 
{ 
    var temp = document.createElement ("div"); 
    (temp.textContent != null) ? (temp.textContent = html) : (temp.innerText = html); 
    var output = temp.innerHTML; 
    temp = null; 
    return output; 
} 

function HTMLDecode(text) 
{ 
    var temp = document.createElement("div"); 
    temp.innerHTML = text; 
    var output = temp.innerText || temp.textContent; 
    temp = null; 
    return output; 
}

iframe带来的风险

既不安全也非常耗性能。

容易被其他第三方恶意网站以精确的iframe盗取我们的用户信息。

防御检测：

1.方式一

if (self.frameElement && self.frameElement.tagName == "IFRAME") {
　　alert('在iframe中');
}

2.方式二
if (window.frames.length != parent.frames.length) {
　　alert('在iframe中');
}

3.方式三
if (self != top) { 
　　alert('在iframe中');
}

还好在HTML5中，iframe有了一个叫做sandbox的安全属性，通过它可以对iframe的行为进行各种限制，充分实现“最小权限“原则。使用sandbox的最简单的方式就是只在iframe元素中添加上这个关键词就好，就像下面这样：

<iframe sandbox src="..."> ... </iframe>

sandbox还忠实的实现了“Secure By Default”原则，也就是说，如果你只是添加上这个属性而保持属性值为空，那么浏览器将会对iframe实施史上最严厉的调控限制，基本上来讲就是除了允许显示静态资源以外，其他什么都做不了。比如不准提交表单、不准弹窗、不准执行脚本等等，连Origin都会被强制重新分配一个唯一的值，换句话讲就是iframe中的页面访问它自己的服务器都会被算作跨域请求。

另外，sandbox也提供了丰富的配置参数，我们可以进行较为细粒度的控制。一些典型的参数如下：

• allow-forms：允许iframe中提交form表单

• allow-popups：允许iframe中弹出新的窗口或者标签页（例如，window.open()，showModalDialog()，target=”_blank”等等）

• allow-scripts：允许iframe中执行JavaScript

• allow-same-origin：允许iframe中的网页开启同源策略

更多详细的资料，可以参考iframe中关于sandbox的介绍。

别被点击劫持了

最常见的是恶意网站使用 <iframe> 标签把我方的一些含有重要信息类如交易的网页嵌入进去，然后把 iframe 设置透明，用定位的手段的把一些引诱用户在恶意网页上点击。这样...

防御方法：

1、不允许被iframe嵌套，

if (top.location.hostname !== self.location.hostname) {
    alert("您正在访问不安全的页面，即将跳转到安全页面！");
    top.location.href = self.location.href;
}

2、使用 HTTP 头防范

通过配置 nginx 发送 X-Frame-Options 响应头，这样浏览器就会阻止嵌入网页的渲染。更详细的可以查阅 MDN 上关于X-Frame-Options 响应头的内容。

add_header X-Frame-Options SAMEORIGIN;

错误的内容推断

比如在上传文件时在文件数据里面动了手脚，嵌入脚本文件或语句。

防火防盗防猪队友：不安全的第三方依赖包

前面圣诞老人的雪花不陌生吧，嘻嘻嘻～～～

用了HTTPS也可能掉坑里

解决这个安全问题的办法是使用HSTS（HTTP Strict Transport Security），它通过下面这个HTTP Header以及一个预加载的清单，来告知浏览器在和网站进行通信的时候强制性的使用HTTPS，而不是通过明文的HTTP进行通信：

Strict-Transport-Security: max-age=; includeSubDomains; preload

本地存储数据泄露

在前端存储敏感、机密信息始终都是一件危险的事情，推荐的做法是尽可能不在前端存这些数据。

缺失静态资源完整性校验

出于性能考虑，前端应用通常会把一些静态资源存放到CDN（Content Delivery Networks）上面，例如Javascript脚本和Stylesheet文件。这么做可以显著提高前端应用的访问速度，但与此同时却也隐含了一个新的安全风险。

如果攻击者劫持了CDN，或者对CDN中的资源进行了污染，那么我们的前端应用拿到的就是有问题的JS脚本或者Stylesheet文件，使得攻击者可以肆意篡改我们的前端页面，对用户实施攻击。

防御这种攻击的办法是使用浏览器提供的SRI（Subresource Integrity）功能。顾名思义，这里的Subresource指的就是HTML页面中通过浏览器在处理这个script元素的时候，就会检查对应的JS脚本文件的完整性，看其是否和script或link元素中integrity属性指定的SRI值一致，如果不匹配，浏览器则会中止对这个JS脚本的处理。

<link crossorigin="anonymous" integrity="sha256-+hDz/gVbhp24mhOmoIT4Du4F3K5fs9fjjoe0rP5gSLs=" rel="stylesheet" href="/assets/css/home.css" />

这个 integrity 属性的值来 指定浏览器提取的资源（文件）的base64编码的加密哈希值。如果资源匹配其中一个哈希值，它将被加载。

<script> <link> 的 integrity 值 至少一个字符串，每个串包括指示特定散列算法（目前允许的前缀的前缀 sha256 ， sha384 和 sha512 ），然后用短划线，并与实际base64编码散列结束。例如：

sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC