web安全之XSS

一、浏览器安全

1、同源策略（SOP）

     在浏览器中，<script>、<img>、<iframe>、<link>等标签都可以跨域加载资源，而不受同源限制。这些带src属性的标签每次加载时，实际上是有浏览器发起了一次GET请求。不同于XMLHttpRequest（通过目标域返回的HTTP头"Access-Control-Allow-Origin:*  *允许访问自己的域"来授权是否允许跨域访问，因为HTTP头对JavaScript来说一般是无法控制的）的是，通过src属性加载的资源，浏览器限制了JavaScript的权限，使其不能读、写返回的内容。

2、浏览器沙箱（Sandbox）

3、恶意网站拦截

二、跨脚本***（XSS）

2.1 XSS***类型

2.1.1、反射型XSS

     通过用户输入的数据反射给浏览器，反射型XSS也叫“非持久型XSS”（Non-persistent XSS）

     假设一个页面把用户输入的参数直接输出的页面上：

    正常情况下，用户想param提交的数据会展示在页面里，如：

    此时查看源码：

    但如果提交一段HTML代码：

    再查看源码：

2.1.2、存储型XSS

    ***会把用户的数据存储在服务器端。

    比较常见的场景是：***写了一篇包含有恶意JavaScript代码的博客文章，只要用户访问改文章，就会在他们的浏览器中执行这段恶意代码，***会把恶意代码保存到服务器端。所以这种方式也叫持久型XSS（Persistent XSS）。

2.1.3、DOM Based XSS

    通过修改页面的DOM节点形成XSS，称之为DOM Based XSS

    代码如例：

     正常构造数据，www.a.com。

     点击write按钮：页面显示www.a.com链接

     非正常构造如下数据: 

     点击write按钮，页面显示testlink，点击testlink，弹出/xss/警告框

     这里首先一个单引号闭合掉href第一个单引号，然后插入一个onclick事件，最后再用注释符注释掉第一个单引号。

     这段代码也可以通过闭合掉<a>的方式***：

     此时页面代码变成了：

2.2 XSS防御

2.2.1 HttpOnly

      设置cookie httponly标记，可以禁止JavaScript访问带有该属性的cookie，目前主流的浏览器已经支持HttpOnly

2.2.2 输入检查

2.2.3 输出检查

      安全的编码函数：在数据添加到DOM时候，我们可以需要对内容进行HtmlEncode或JavaScriptEncode，以预防XSS***。 JavaScriptEncode 使用“\”对特殊字符进行转义，除数字字母之外，小于127的字符编码使用16进制“\xHH”的方式进行编码，大于用unicode（非常严格模式）。除了HTMLEncode、JavaScriptEncode外还有XMLEncode、JSONEncode等编码函数，在php中有htmlentities()和htmlspcialchars()两个函数可以满足要求。

      XSS***主要发生在MVC架构的view层，大部分的XSS漏洞可以在模板系统中解决。

      在python的开发框架Django自带的模板系统中，可以使用escape进行htmlencode，比如：

      这样写的变量，会被HtmlEncode

2.2.4 正确防御XSS

场景一：在HTML标签中输出

      所有在标签中输出的变量，如果未做任何处理，都会导致直接产生XSS

      在这种场景下，XSS的利用方式一般构造一个<script>标签，或者是任何能够产生脚本的执行方式。比如：

     或者

防御的方式是对变量使用HtmlEncode

场景二：在HTML属性中输出

 与在HTML标签中输出类似，可能的***方式

防御的方法也是HtmlEncode。

在OWASP ESAPI中推荐课一个更严格的HTMLEncode--除了字幕、数字外，其他所有字符都被编码成HTMLEntities。

String safe=ESAPI.encoder().encodeForHTMLAttribute(request.getParameter("input"));

场景三：在<script>标签中输出 

在<script>标签中输出时，首先应该确保输出的变量在引号中

 ***者需要闭合引号才能实施***

 防御时使用JavascriptEncode。

场景四：在事件中输出

在事件中输出和在<script>标签中输出类似：

可能***方法是：

防御时使用JavascriptEncode。

场景四：在CSS中输出

      尽可能禁止用户可控制的变量在"<style>标签"，如果一定有这样的需求，则推荐使用OWASP ESAPI中的encodeForCSS()函数

场景五：在地址中输出

      在地址中输出比较复杂。一般来说，在URL的path或参数中输出，使用URLEncode即可。URLEncode会将字符转换为"%HH"形式，比如空格就是"%20","<"符号是"<%3c>"。

可能的***方法是： 

经过URLEncode后，变成了：

     还有一种情况，如果变量是整个URL (href="$var")，此时***者可能会构造伪协议实施***：

      一般来说，如果变量是整个URL，则应该先检查变量是否是以http开头（如果不是则自动添加），以保证不会出现伪协议类的XSS***。在此之后，再对变量进行URLEncode，以保证不会出现伪协议类的XSS***。

2.2.4 处理富文本

     允许用户提交一些自定义的HTML代码，称之为"富文本",如论坛帖子里发表的图片、视频、表格等。在处理富文本的时候还是要回到"输出检查"的思路上来。

2.2.5 防御DOM Based XSS

    DOM Based XSS 是一种比较特别的XSS漏洞，前文提到的几种防御方法都不太适用，需要特别对待。

   以以下案例：

     这段代码最终输出弹框1，被XSS***。原因在于，第一次执行JavaScriptEscape后只保护了：  

      但是当document.write输出数据到Html页面时，浏览器重新渲染了页面。在<script>标签执行时，已经对x进行了解码，气候在document.write再运行时，其参数变成了：

     预防方式是：首先在$var输出到<script>时，应该执行一次JavaScriptEncode；其次在document.write输出到html页面时要分具体情况看待：如果输出到事件或脚本，则要做一次JavaScriptEncode；如果输出到Html内容或者属性，则要做一次HTMLEncode。