《Web漏洞防护》读书笔记——第9章，XSS防护

《Web漏洞防护》读书笔记——第7章，XSS防护

XSS

跨站脚本攻击，注入型攻击，攻击者使用Web应用将恶意代码发送给不同终端用户，造成恶意代码在用户端的执行。由于用户的浏览器无法判断脚本是否应该被新人，人为脚本来自可信的源，直接执行脚本。

核心：Web应用直接将用户的输入作为输出，且对输出未进行任何的编码和验证。

极易出现XSS的地方

1.搜索域：直接将用户的搜索内容不加处理的返回给用户。
2.输入域：直接将用户输入的内容不加处理的返回给用户。
3.错误信息：直接将用户提供的内容不加处理的防止在错误消息中，返回给用户。
4.隐藏域：包含用户提供的未经处理的数据。
5.任何展示用户提供的未经处理的数据的地方，如留言板，评论区等。

XXS主要危害

窃取用户Cookie、登录凭证一级保存浏览器中的与网站相关的其他敏感信息。
构建错误请求，造成服务端的错误。
篡改网页内容。
重定向网站到恶意站点。
伪造有效用户的请求，可与CSRF结合，对关键信息及服务端状态进行篡改。
在终端用户系统上执行恶意代码，如挖矿脚本。
插入不适当的甚至敌对的内容，影响网站声誉。
此外，XSS还能增加其他攻击方式的成功率，如与钓鱼攻击结合，通过篡改页面内容，使的钓鱼页面呈现在受信任的域中；或与CSRF结合，使得CSRF攻击能够自动执行。

XXS分类

分为反射性、DOM型、存储型，3种类型。

反射型XXS

非持久型XSS，通常发生在将用户的部分输入或全部输入作为请求的一部分发动到服务端的情况，服务端会将其作为响应信息返回，并将未经处理的响应消息直接呈现在用户的浏览器上。

反射型XXS特点

而已内容来自用户的请求，并被呈现在用户的浏览器上。
恶意内容通过服务器的响应消息写入到网页中。
攻击时一般需要结合社会工程学，以提高攻击的成功率。
使用用户权限在浏览器中运行。

反射型XXS的攻击过程

1.攻击者发送一个恶意链接给受害者
2.受害者点击链接加载恶意网页
3.嵌入到恶意网页中的恶意脚本在受害者的浏览器中执行，窃取用户隐私书或执行其他恶意操作。
整个攻击过程用户是无感知的状态。

DOM型XXS

与传统反射型XSS不同的在于整个数据的流转过程都发生在浏览器内，不与服务器进行交互。
恶意数据既可以来自于URL，也可以是HTML中的DOM节点，触发咯咚的地方是某些敏感方法的调用处，如document.write

DOM型XXS特点

来自用户输入的恶意数据被客户端脚本写入自身HTML中。
使用用户权限在浏览器中运行。
具有与反射型XSS类似的特点。

DOM型XXS的攻击过程

1.攻击者发送一个恶意的URL给受害者。
2.受害者点击URL。
3.URL加载一个恶意Web页面或用户使用的存在漏洞Web页面。
4.如果是一个恶意页面，它将使用自己的脚本攻击存在漏洞的Web页面。
5.存在漏洞的页面加载脚本。
6.攻击者的恶意脚本使用用户的权限在浏览器中运行，并在该页面上执行攻击。
整个攻击过程用户是无感知的状态。

DOM型XSS通常会处在在客户端代码的路由配置中，寻找那些将用户输入直接呈现到页面的路由，一般就是DOM型XSS的所在之处，代码中的测试路由是DOM型XSS的高发地。

存储型XXS

持久型XSS，危害性极大。
攻击者的恶意输入存储在目标服务器中，如数据库、日志、评论区等。或者借助HTML5及其他浏览器技术，将恶意数据存储在受害者的浏览器中，不需要发送到服务器，受害者通过应用获取存储的恶意数据，在未经任何处理的情况下直接呈现到用户的浏览器中。

存储型XXS特点

恶意数据存储在服务器端，再呈现给用户的浏览器中。
不需要结合社会工程学就可以发动攻击。

存储型XXS的攻击过程

1.攻击者提交恶意数据到评论区、留言板等可能存在数据存储的区域。
2.消息被提交到服务端并进行存储。
3.受害者浏览包含恶意数据的网页。
4.嵌入浏览器中的恶意数据以应用的权限被执行，并进行恶意的操作。
整个攻击过程用户是无感知的状态。

检测XXS——反射型XSS

3个步骤：
1.确定页面中所有可能的输入，包括哪些隐藏的、不明显的输入，如HTTP请求参数、POST参数、HTTP头、隐藏表单、预定义值、可选值等，一般通过HTML编辑器、中间人工具进行分析。
2.构造测试向量，通常是无害的测试，但是会在浏览器中出发漏洞。测试向量可以通过自动化工具进行生产，也可以预先定义，如< script>alert(123)< script>alert(document.cookie)
3.将每一个可能的输入替换成构造的测试向量，分析响应消息中是否包含未经过任何处理的测试向量，如果包含，则表明可能存在反射型XSS漏洞。

检测XXS——存储型XSS

于反射型XSS的检测相似，存储型XSS漏洞不仅要检测本程序对于存储数据的展示，还需要注意其他应用程序对用户输入数据的存储及展示，防止将存储型XSS引入到其他应用之中。
特别需要注意管理员访问的页面是否会被引入存储型XSS。

检测XXS——DOM型XSS

与反射型、存储型XSS的检测不同，DOM型XSS的数据流转都发生在客户端，无法通过中间人工具进行检测，需要构造一个特殊的环境，使整个页面及页面中的脚本都能够进行动态的加载，如使用Qt Webkit以无界面的方式构建动态加载环境。
分4个步骤进行检测：
1.构建动态加载环境。
2.确定页面中所有可能的输入，包括隐藏的、不明显的输入。
3.构造测试向量。
4.将每一个可能的输入替换为构造的测试向量，分析页面是否会产生预期的行为，该行为随着测试向量的不同而不同，最简单的行为就是产生一个弹窗。

XXS的防护——反射型XSS、存储型XSS

需要仔细分析数据在页面中的输出位置，采取相应的安全策略，在数据输出到页面前，进行相应的编码。
1.插入数据到HTML元素内容前进行HTML编码：
如常见的

标签，需要对数据进行HTML编码，常见的编码工具一般会转义&、<、>、"、’ 这5个字符。

2.插入数据到HTML安全属性前进行属性的编码
将不可信任的数据插入典型的属性值中，如width、name、value等，需要进行属性的转义。设置属性值时，可以将属性值通过单引号或双银行进行包裹，也可以不进行包裹直接使用。

3.将不可信任数据插入JavaScript前需要进行JavaScript编码
4.将数据插入到CSS属性前需要进行CSS编码
5.将数据插入到HTML URL参数前要进行URL编码
6.对HTML标签进行过滤
7.其他防护措施：
a.Cookie中使用HttpOnly属性，客户端就无法通过document.cookie的方式来访问cookie
b.使用内容安全策略CSP，是一种浏览器机制，允许为Web应用程序的客户端创建资源调用的白名单，限制客户端资源的加载。
c.使用X-XSS-Protection响应头
这个HTTP响应头可以启用浏览器内置的XSS过滤器，使得浏览器自身对XSS有一定的防御能力，是默认开启的。
d.使用自动转义模板的系统，许多应用程序框架提供上下文自动转义功能，如AngularJS

XXS的防护——DOM型XSS

由于DOM型的XSS数据并不总是由服务端返回，因此基于服务端的编码策略对于防御DOM型的XSS不再有效。因为DOM型XSS是由客户端脚本将数据写入HTML页面中的，所以在客户端脚本中对将要输出到页面的数据进行编码时，将会起到与服务端编码一样的防御效果。

核心：在客户端脚本中对将要输出到页面的数据进行编码。

XXS防护工具

OWASP Java Encoder（作用于服务端）
OWASP Java HTML Sanitizer（作用于服务端）
AnjularJS SCE（作用于客户端，防御DOM型XSS）
ESAPI4JS（作用于客户端，防御DOM型XSS）
jQuery Encoder（作用于客户端，防御DOM型XSS）