-
-
web前端安全基础与攻防(续篇)
-
发表于: 2015-4-21 10:02
-
还记得在前篇中有一段针对使用 IE 浏览器用户的攻击载荷，如下所示 ：
<script>function XSS(){
a = new ActiveXObject('Microsoft.XMLHTTP');
a.open('get', 'http://www.baidu.com', false);
a.send();
b = a.responseText;
document.write(b);
}
XSS();
</script>这是因为 IE 的同源策略没有很好地对XMLHttpRequest进行约束，例如，上述代码可能位于本地硬盘的一个HTML文本中（C:\Users\shayi\Desktop\XssPayloadTest.html）
我们已经在上一篇博文中看到，IE 默认允许XHR跨域加载并读写资源；对于其它浏览器（FireFox 与 chrome）而言，本地文件系统路径与“百度首页”是不同源的，因此它们会限制当前HTML文本所在源中的javascript读写从百度首页返回的数据，换言之，这两个浏览器的同源策略默认仅允许XHR加载，读写相同源中的数据，除非对浏览器以及目标站点的web服务器配置为启用HTML5规范中引入的“跨域资源共享”（CORS）。
下面的示例代码，通过使用非 IE 浏览器支持的XHR对象，尝试跨域加载资源并写入至当前页面DOM中的一个节点：
（引用自《白帽子讲web安全一书》，略作修改）
<!DOCTYPE html>
<html lang="en">
<head>
<meta http-equiv="Content-type" content="text/html;charset=utf-8" />
<title>XssPayloadTest</title>
<script type = "text/javascript">
var xmlhttp;
function LoadXMLDoc(url)
{
xmlhttp = null;
if (window.XMLHttpRequest)
{
xmlhttp = new XMLHttpRequest();
}
else if (window.ActiveXObject)
{
xmlhttp = new ActiveXObject("Microsoft.XMLHTTP");
}
if (xmlhttp != null)
{
xmlhttp.onreadystatechange = state_Change();
xmlhttp.open("GET", url, true);
xmlhttp.send(null);
}
else
{
alert("your browser does not support XMLHTTP");
}
}
function state_Change()
{
if (xmlhttp.readyState == 4)
{
if (xmlhttp.status == 200)
{
document.getElementById('T1').innerHTML = xmlhttp.responseText;
}
else
{
alert("problem retrieving data:" + xmlhttp.statusText);
}
}
}
</script>
</head>
<body onload = "LoadXMLDoc('http://bbs.pediy.com/index.php')">
<div id = "T1" style = "border:1px solid black;height:40;width:300;padding:5"></div><br />
<button onclick = "LoadXMLDoc('http://shayi1983.blog.51cto.com')">Click</button>
</body>
</html>state_Change()检查对方web服务器返回的HTTP响应状态码，然后决定是读取响应数据的内容并写入当前页面（状态码为200）；还是给出服务器端返回的错误信息（除200以外的其它状态码）。
在HTML文档体（body元素内），通过实际调用LoadXMLDoc()来对看雪论坛首页发起跨域请求（注意，当前“源”是本地文件系统上的测试用HTML页面），然后尝试将对方返回的“响应文本”（responseText）写入当前页面DOM的T1节点的内部HTML文本中，并且在文档体中添加一个按钮，用户点击时将再次通过XHR对象，发起对我的51cto博客页面的跨域请求。
上面代码在FireFox中的测试结果如下所示：
为了更清楚说明XHR询问是否可以CORS的场景，假设一个HTML页面所属域为
http://www.webSite.com（即该页面通过这个URL加载），在该页面中，有一段生成跨域HXR的 javascript 代码如下：
var xhr = new XMLHttpRequest();
xhr.open("PUT", "http://www.friendlySite.com/index.html", true);
xhr.send();
xhr.open() 的第三个参数为 true，表明请求为异步发送，这是默认值，有些浏览器为了性能上的考量，甚至拒绝将该参数设置为 false（同步），如果你这么做了， Firebug 将会给出类似下面的提示：
OPTIONS http://www.friendlySite.com/index.html HTTP/1.1 Host: www.friendlySite.com User-Agent: Mozilla/5.0(Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20150101 Firefox/37.0 Accept: text/html,application/xhtml+xml,applicatiin/xml;q=0.9,*/*;q=0.8 Accept-Language: zh-CN,zh;q=0.5 Origin: http://www.webSite.com Accept-Control-Request-Method: PUT
如果目标域 www.friendly.com 允许 CORS ，其返回的HTTP 响应头应该如下所示：
HTTP/1.1 200 OK Date: Wed, 13 Apr 2015 06:51:53 GMT Server: Tengine Access-Control-Allow-Origin: http://www.webSite.com Access-Control-Allow-Methods: PUT Access-Control-Allow-Credentials: true Access-Control-Max-Age: 10 Content-Length: 0
的 CORS ，如此一来，浏览器将允许 www.webSite.com 域页面中的XHR对象和后续的 javascript 代码读取，操纵和显示来自 www.friendly.com 域返回的数据，例如读写 xhr.responseText 的内容时，才不会发生错误。
另外，Access-Control-Max-Age 响应头的含义为，该响应的有效期，以秒为单位，例如其值为 3600 时，浏览器在一小时内对目标域的每次跨域访问，都不需要使用 Preflight 请求，这就减少在请求头中增加多余的头部造成的客户端与服务器端处理负担，以及链路带宽的浪费（每次少传输几十到上百字节总是好的）；但是一小时后，浏览器必须再次发送 Preflight 请求至服务器，以更新目标域的 CORS 许可策略，一般而言，目标域为了其自身数据的安全考量，Access-Control-Max-Age 的值不会设的太长，但是像上例中的10秒那么短也不太实际，各位可以自行访问其它互联网上的站点，通过工具来测试这个值。
Access-Control-Allow-Credentials 请求头的值如果为 true，那么 www.webSite.com 域页面中的 XHR 对象以及 javascript 脚本代码，将能够读写
由目标域 www.friendly.com 设置的 cookie，HTTP 基本认证字串（base-64 格式的用户名与密码，即目标域赋予的用户会话令牌），摘要认证字串（MD5 或其它摘要算法加密的用户名与密码），以及由目标域 www.friendly.com 设置的客户端 SSL 证书（假设目标域是电子商务网站或网上银行，需要验证企业用户的身份，就有可能用到客户端 SSL 证书），以上这些证书和认证信息，以及 cookie 形式的会话令牌，都将能够被 www.webSite.com 域页面中的 XHR 对象以及 javascript 脚本代码读写访问；一般而言，如果目标域和源始域之间没有很好的友情和信任关系，Access-Control-Allow-Credentials 响应头的值应该为 false 会比较安全。
（作为对比，前面的本地文件系统上的测试HTML页面中的 javascript 代码无法将来自看雪以及51cto域的 xhr.responseText 写入至测试页面，就是因为浏览器没有收到来自看雪以及51cto域允许与“本地域”进行CORS的响应头。）
浏览器根据HTML文档起始处的“<!DOCTYPE xxxx>”来判断应该使用何种解析模式，当xxxx的值为“html”时，表示为HTML解析模式，该模式对文档的语法要求比较宽松，浏览器的HTML解析引擎会容许并且自动修正绝大多数的语法错误，例如下面这个例子：
<!DOCTYPE html>
<htMl lang="en">
<head>
<meta http-equiv="Content-type" content="text/html;charset=utf-8" />
<title>XssPayloadTest</title>
</head>
<body>
' " `
<a href = http://www.baidu.com>百度首页。。。
</oops>
<IMG src = #>
</hTml>a元素的href属性的值（百度首页的URL）没有用双引号包含；存在一个没有起始（标签）的oops元素；img元素使用全大写而且没有闭合。。。。这些语法错误都可以在浏览器中得到修正，前提是使用HTML解析模式，以 IE 为例，打开上述文档，IE 会在其进程地址空间中构建DOM节点时，修正错误，缺少的元素：
再者，采用HTML解析模式，遇到“<script>”，“<style>”，“<textarea>”，“<xmp>”等元素标签，都会致使浏览器切换到特殊解析模式，例如碰到script标签，调用javascript解析引擎；碰到style标签调用CSS解析器等等。
而在XML类文档中（包括XHTML），这些标签内部还需要嵌套一个前后不对称格式的数据标签，如下所示：
<script type="text/javascript"> <![CDATA[ //将此处注释掉的内容改成javascript代码，其它类型的特殊解析模式标签，以此类推 ]]> </script>
例如，BurpSuite Proxy 模块拦截到的从“博文视点”站点首页，返回的HTTP响应体的HTML文档中，就包含了对“<![CDATA[]]>”的使用：
使用XHTML解析时，仅遇到 script 或 style 标签，还无法切换进入到对应的解析模式（调用 javascript 或 css 解析引擎），而是必须添加“<![CDATA[....]]>”数据标签，并且将脚本代码或样式表放在其中以实心句点表示的位置处，才能正常工作。
<img src= "http://www.baidu.com" title=""onerror="alert('xss')" class=examples>
如果将包含javascript语句的双引号改成“反引号”（`），则三种浏览器在解析时，都会自动在反引号外侧再添加双引号，换言之，无论img元素属性的值为何，总是使用双引号包含，而这会导致添加反引号的javascript代码无法执行：
但是，如果属性的值为以左尖括号开始的元素，例如script，并且原始文档中没有将其用双引号包含，那么浏览器在解析的时候会产生混乱（对于三大浏览器而言都一样），虽然这样并不会导致执行script标签中的javascript代码，但是浏览器会给出一些错误提示（IE），或者会干扰到对img元素其它属性值的正常解析（FireFox 与 chrome），例如原始文档中的代码：
<img src = "#" title = <script>alert('xss in value of element properties');</script> class = examples>
（img元素与第一个属性之间的空格符不会被省略，而且是必须的）
以下面代码为例，其在body元素内部存在错误的标签嵌套：
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-type" content="text/html;charset=utf-8" />
<title>XssPayloadTest</title>
</head>
<body>
<i <b>xss
</body>
</html>
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-type" content="text/html;charset=utf-8" />
<title>XssPayloadTest</title>
</head>
<body>
<i<"<b>">xss
</body>
</html>来看看浏览器们会如何解析这个文档：
在chrome的解析截图中，看到了将特殊字符进行HTML实体编码的用法，其实，
浏览器的HTML解析引擎应该都能识别在HTML文档的文本节点与元素属性值内，以HTML实体编码的字符序列，并将其解码，还原成可打印的ASCII字符。
这就是chrome将文本节点中的左尖括号编码的原因——它可以解码成明文字符。
这里隐含了一条重要的安全规则，浏览器在解析时应该遵守，否则就有可能在客户端产生xss漏洞，假设经由服务器端返回的HTML文档中，已经对文本节点与元素属性值进行了HTML实体编码（或者10进制，16进制编码），意味着这些被编码的字符是具有危害性的（一般而言，普通字符不需要编码）
那么浏览器就不能将解码后的危害性字符序列（如“<script>”）当成指令执行，只能作为数据或字符串显示，或者索性不解码，在HTML文档中显示编码字符。
因为服务器端的xss过滤器已经意识到，危害性字符出现在文本节点与元素属性值中，可能导致xss漏洞，因此将其编码，而浏览器能做的就是，仅显示解码后的内容，而不是执行，或者保持原样输出。
为了更好地说明其中的微妙之处，来看一看下面的几个实例：
[CODE]<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-type" content="text/html;charset=utf-8" />
<title>XssPayloadTest</title>
</head>
<body>→
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
实现逻辑如下： <!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-type" content="text/html;charset=UTF-8" />
<title>XssPayloadTest</title>
</head>
<body>
<script>
document.write(navigator.userAgent);
document.write("<br><br>");
var isIE = navigator.userAgent.indexOf('Trident') > 0;
var isChrome = navigator.userAgent.indexOf('Chrome') > 0;
var isFirefox = navigator.userAgent.indexOf('Firefox') > 0;
var isOpera = navigator.userAgent.indexOf('OPR') > 0;
if (isIE){
document.write('<b>您使用的是IE浏览器</b>');
}else if (isChrome){
if (isOpera){
document.write('<b>您使用的是Opera浏览器</b>');
}else{
document.write('<b>您使用的是Chrome浏览器</b>');
}
}else if (isFirefox){
document.write('<b>您使用的是Firefox浏览器</b>');
}else{
document.write('<b>您使用的是其它浏览器</b>');
}
</script>
</body>
</html>第8行直接在当前页面输出打开该页面的浏览器的用户代理字串；第11~14行分别查找各种浏览器的用户代理字串中，能够唯一识别浏览器类型的关键词，这是由于，在早期的“浏览器世界大战”中，许多 web 页面的特定内容仅支持 Netscape Navigator 浏览器（网景公司的产品，其 “Mozilla” 字串就是它首创的，含义为“Mosaic Killer”，即浏览器鼻祖 Mosaic 的杀手），而其它品牌浏览器为了提高自身市场份额与竞争力，也在其用户代理中添加了“Mozilla”字串，用于告诉目标站点：“我是与 Mozilla 兼容的浏览器”，如此一来，站点就会返回原本仅响应给 Mozilla 浏览器的页面内容，而这个内容通常是比较丰富的； 最终效果就是， IE 浏览器的用户访问某站点获得的内容与 Netscape Navigator 浏览器的用户获得的内容一致，因为 IE 在它的用户代理字串中，添加了“Mozilla”字串。 其它浏览器相继模仿这个做法，导致通过“Mozilla”字串根本无法实际识别浏览器类型，所以，必须找到用户代理字串中，每个浏览器都不一样的关键词，这就是第11~14行代码的工作，例如第11行查找用户代理字串中的“Trident”，后者是 IE 浏览器的 HTML 渲染引擎内核代号，然后保存在一个变量中，第15~16行代码通过判断这个变量的值来输出用户使用的是 IE 浏览器（在实际开发时，应该把这里的内容替换成仅 IE 浏览器支持的页面代码，其它类型浏览器以此类推）。 另一方面，当前的 chrome 与 Opera 浏览器的用户代理字串中，都包含了“Chrome”关键词，所以仅凭它无法区分这2个浏览器，需要检查在包含“Chrome”关键词的用户代理字串中，是否含有“OPR”字串，如果有，则能识别出 Opera 浏览器，反之，则为 chrome 浏览器；而这就是第17~22行的嵌套 if-else 语句的工作。顺便提一下，这2个浏览器的 HTML 解析引擎内核都源于苹果公司开发 Safari 浏览器时的内核 WebKit；google 公司在 WebKit 的基础上开发出新的内核称为 Blink；这2个浏览器厂商“饮水思源”的做法导致你在使用这2个浏览器打开上述文档时，看到了各自的用户代理字串都包含“AppleWebKit”：     |
|
|
|
|
|
假设用于生成短信链接的输入框的初始 HTML 代码如下： <a href="></a> 1。双引号元素属性闭合； 2。 onmouseover 事件结合 eval 函数执行任意代码； 3。对 URL 进行 UTF-16 编码绕过 XSS 防火墙； 4。利用社会工程学攻击来引诱用户点击链接； http://t.co@" style="font-size:99px;" onmouseover="eval(location.href='http:\u002f\u002fwww.baidu.com\u002f')" class/ 为了增强链接的视觉诱惑性，我在 a 元素的 innerHTML 中，添加了名为“邀请码发放页面”的文本节点（请勿在论坛中尝试！），最终的注入效果（即存储到服务器上的漏洞页面）如下所示： <!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-type" content="text/html;charset=UTF-8" />
<title>XssPayloadTest</title>
</head>
<body >
<a href="http://t.co@" style="font-size:99px;" onmouseover="eval(location.href='http:\u002f\u002fwww.baidu.com\u002f')" class/">邀请码发放页面</a>
</body>
</html>
|
|
|
|
|
|
unicode 字符的转义序列，“\u”后面的4个 ASCII 字符（或2个16进制数），可以采用 UTF-8/16/32 等编码形式；这里使用的是 UTF-16 编码（三种编码都是 unicode 编码的子集），使用这些编码是为了支持一些不能正常显示 unicode 字符的计算机系统。实际上，unicode 字符转义使用与 ASCII 字符的16进制编码相同的 映射；例如，对于字符串“alert”，其 ASCII 16进制编码形为“\61\6c\65\72\74”；其 unicode UTF-16 编码转义形式为“\u0061\u006c\u0065\u0072\u0074” ，第2个16进制数与 ASCII 字符的16进制编码相同，第1个16进制数在编码 ASCII 字符时为 00；在编码其它 unicode 字符时不为 00。 javascript 语言核心（以及实现它的浏览器内部的 javascript 解释引擎）直接支持 unicode 字符转义序列，这意味着，只有这些转义字符出现在页面中与 javascript 执行上下文相关的环境中时，才能被浏览器正确解码，这些环境包括但不限于（其它上下文各位可以自行挖掘）： 1。 script 元素内部； 2。 支持绑定事件处理程序的元素内部； 3。支持在属性值中使用 javascrip 伪协议的元素； 如果直接在 HTML 文档中（例如普通的元素内）使用 unicode 字符转义序列 ，浏览器可能无法识别并解码成相应的 unicode 字符，下面通过例子演示： <!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-type" content="text/html;charset=utf-8" />
<title>XssPayloadTest</title>
</head>
<body>
\u0061\u006c\u0065\u0072\u0074
<div>
<a href = "javascript:\u0061\u006c\u0065\u0072\u0074('xss!')">百度首页</a>
<input type = "text" name ="search" id ="search" value = ""onfocus = \u0061\u006c\u0065\u0072\u0074('利用事件处理程序的xss!')//" class = "text_area"/>
<script>
document.write("\u0061\u006c\u0065\u0072\u0074");
</script>
</body>
</html>第10行在 a 元素的 href 属性值中使用 javascript 伪协议，其中的“alert”保留字使用 unicode UTF-16 编码转义形式，浏览器会解码并还原成 “alert”，导致在点击名为“百度首页”的超链接时，弹出显示“xss!”的信息框； 第11行给 input 元素的 onfocus （鼠标点击聚焦输入框）事件绑定的回调函数正是采用 unicode UTF-16 编码转义形式的 “alert”，浏览器会解码并还原，导致用户点击输入框时触发事件处理程序，弹出提示框； 第13行在 script 元素内调用 document.write()，作为其参数传递的正是 unicode UTF-16 编码转义形式的 “alert”，浏览器会解码并还原，最终在页面输出 alert 字符串。 下面的截图验证了浏览器的 javascript 解析引擎在上述三种 javascript 执行上下文中，遇到 unicode 字符转义序列时，所表现出的行为：  |
|
|
|
|
|
|
|
|
|
。
