XSS 介绍

XSS（跨站）攻击的概念

XSS 又叫 CSS (Cross Site Script) ，跨站脚本攻击。它指的是恶意攻击者往 Web 页面里插入恶意 html 代码，当用户浏览该页之时，嵌入其中 Web 里面的 html 代码会被执行，从而达到恶意用户的特殊目的。XSS 属于被动式的攻击，因为其被动且不好利用，所以许多人常呼略其危害性。而本文主要讲的是利用 XSS 得到目标服务器的 shell。技术虽然是老技术，但是其思路希望对大家有帮助。

跨站攻击的方式

跨站攻击有多种方式，由HTML语言允许使用脚本进行简单交互，入侵者便通过技术手段在某个页面里插入一个恶意HTML代码——例如记录论坛保存的用户信息（Cookie），由于Cookie保存了完整的用户名和密码资料，用户就会遭受安全损失。当然，攻击者有时也会在网页中加入一些以.JS或.VBS为后尾名的代码时，在我们浏览时，同样我们也会被攻击到。

如何寻找XSS漏洞

XSS攻击分成两类，一类是来自内部的攻击，主要指的是利用程序自身的漏洞，构造跨站语句，如:dvbbs的showerror.asp存在的跨站漏洞。另一类则是来来自外部的攻击，主要指的自己构造XSS跨站漏洞网页或者寻找非目标机以外的有跨站漏洞的网页。如当我们要渗透一个站点，我们自己构造一个有跨站漏洞的网页，然后构造跨站语句，通过结合其它技术，如社会工程学等，欺骗目标服务器的管理员打开。

XSS 攻击漏洞原理

XSS 的触发条件

了解 XSS 的触发条件就先得从 HTML（超文本标记语言）开始，我们浏览的网页全部都是基于超文本标记语言创建的，如显示一个超链接：

  1. <A HREF="http://safe.it168.com">IT168安全频道</A>

而 XSS 的原理也就是往 HTML 中注入脚本，HTML 指定了脚本标记 <script></script>。在没有过滤字符的情况下，只需要保持完整无错的脚本标记即可触发 XSS，假如我们在某个资料表单提交内容,表单提交内容就是某个标记属性所赋的值，我们可以构造如下值来闭和标记来构造完整无错的脚本标记：

  1. "><script>alert('XSS');</script><"

结果形成了 <A HREF=""><script>alert('XSS');</script> <"">茄子宝的博客在这里</A> 这样一个标记，：）这里和 SQL 注入很像！

测试闭和表单赋值所在的标记，形成完整无错的脚本标记可触发 XSS，但是没有脚本标记怎么触发 XSS 呢？呵呵，我们只好利用其他标记了，假如要在网页里显示一张图片，那么就要使用一个 <img> 标记，示例如下：

  1. <img src=" http://safe.it168.com /xss.gif">

img标记并不是真正地把图片给加入到Html文档把两者合二为一，而是通过src属性赋值。那么浏览器的任务就是解释这个img标记，访问src属性所赋的值中的URL地址并输出图片。问题来了！浏览器会不会检测src属性所赋的值呢？答案是否！那么我们就可以在这里大做文章了，接触过javascript的同志应该知道，javascript有一个URL伪协议，可以使用“javascript：”这种协议说明符加上任意的javascript代码，当浏览器装载这样的URL时，便会执行其中的代码.于是我们就得出了一个经典的XSS示例：

  1. <img src="javascript:alert('XSS');">

当然并不是所有标记的属性都能用，细心的你应该发现标记的属性在访问文件才触发的XSS，这里我就不再深入，因为离开标记的属性还有事件能帮助我们触发XSS.那什么是事件呢？只有达到某个条件才会引发事件，正巧img标记有一个可以利用的onerror()事件，当img标记内含有一个onerror()事件而正好图片没有正常输出便会触发这个事件，而事件中可以加入任意的脚本代码，其中的代码也会执行.现在我们又得到了另外一个经典的XSS示例：

  1. <img src=" http://xss.jpg" onerror=alert('XSS')>

综合这一部分，我们知道XSS的触发条件包括：完整无错的脚本标记，访问文件的标记属性和触发事件。

XSS 转码引发的过滤问题

有攻就有防，网站程序员肯定不会放任大家利用 XSS，所以他们常会过滤类似 javascript 的关键字符，让大家构造不了自己的 XSS，我这里就捡两个被忽略惯了的字符来说，它们是 “&” 和 “\”。首先来说说 “&” 字符，玩过 SQL 注入的都知道，注入的语句可以转成 16 进制再赋给一个变量运行，XSS 的转码和这个还真有异曲同工之妙，原因是我们的 IE 浏览器默认采用的是 UNICODE 编码，HTML 编码可以用 &#ASCII 方式来写，这种 XSS 转码支持 10 进制和 16 进制，SQL 注入转码是将 16 进制字符串赋给一个变量，而 XSS 转码则是针对属性所赋的值，下面我就拿 <img src="javascript:alert('XSS');"> 示例：

  1. <img src="&#106&#97&#118&#97&#115&#99&#114&#105&#112&#116&#58&#97&#108&#101&#114&#116&#40&#39&#88&#83&#83&#39&#41&#59"> //10进制转码
  2. <img src="&#x6a&#x61&#x76&#x61&#x73&#x63&#x72&#x69&#x70&#x74&#x3a&#x61&#x6c&#x65&#x72&#x74&#x28&#x27&#x58&#x53&#x53&#x27&#x29&#x3b"> //16进制转码。

这个 &# 分隔符还可以继续加 0 变成 “&#0106”、“&#00106”、“&#000106”、“&#0000106”等形式。
而这个”\”字符却暴露了一个严重的XSS 0DAY漏洞，这个漏洞和CSS（Cascading Style Sheets）层叠样式表有很大的关联，下面我就来看看这个漏洞，先举个javascript的eval 函数的例子，官方是这样定义这个函数：

我们的 JavaScript 中的 “\” 字符是转义字符，所以可以使用 “\” 连接 16 进制字符串运行代码：

  1. <SCRIPT LANGUAGE="JavaScript">
  2. eval("\x6a\x61\x76\x61\x73\x63\x72\x69\x70\x74\x3a\x61\x6c\x65\x72\x74\x28\x22\x58\x53\x53\x22\x29")
  3. </SCRIPT>

恐怖的是样式表也支持分析和解释 “\” 连接的 16 进制字符串形式，浏览器能正常解释。下面我们来做个实验：

  1. <html>
  2.     <body>
  3.         <style>
  4.             BODY { background: url(http://127.0.0.1/xss.gif) }
  5.         </style>
  6.     <body>
  7. <html>

保存为 HTML，浏览器打开显示正常。转换 background 属性值为 “\” 连接的 16 进制字符串形式，浏览器打开同样显示正常。

  1. <html>
  2.     <body>
  3.         <style>
  4.             BODY { background: \75\72\6c\28\68\74\74\70\3a\2f\2f\31\32\37\2e\30\2e\30\2e\31\2f\78\73\73\2e\67\69\66\29 }
  5.         </style>
  6.     <body>
  7. <html>

在前面部分我已经说过 XSS 的触发条件包括访问文件的标记属性，因此我们不难构造出

  1. <img STYLE="background-image: url(javascript:alert('XSS'))">

这样的 XSS 语句。有了实验的结果，我们又能对 CSS 样式表的标记进行 XSS 转码，浏览器将帮我们解释标记内容，XSS 语句示例：

  1. <img STYLE="background-image: \75\72\6c\28\6a\61\76\61\73\63\72\69\70\74\3a\61\6c\65\72\74\28\27\58\53\53\27\29\29">

防范 XSS 攻击

XSS 攻击以及的可怕性及灵活性深受黑客的喜爱。争对 XSS 攻击，编者给普通浏览网页用户及 WEB 应用开发者给出以下的安全建议：

Web 用户

  1. 在电子邮件或者即时通讯软件中点击链接时需要格外小心：留心可疑的过长链接，尤其是它们看上去包含了 HTML 代码。如果对其产生怀疑，可以在浏览器地址栏中手工输入域名，而后通过该页面中的链接浏览你所要的信息。
  2. 对于 XSS 漏洞，没有哪种 Web 浏览器具有明显的安全优势。也就是 Firefox 也同样不安全。为了获得更多的安全性，可以安装一些浏览器插件：比如 Firefox 的 NoScript 或者 Netcraft 工具条。
  3. 世界上没有“100%的有效”。尽量避免访问有问题的站点：比如提供 hack 信息和工具、破解软件、成人照片的网站。这些类型的网站会利用浏览器漏洞并危害操作系统。

Web应用开发者

  1. 对于开发者，首先应该把精力放到对所有用户提交内容进行可靠的输入验证上。这些提交内容包括 URL、查询关键字、http 头、post 数据等。只接受在你所规定长度范围内、采用适当格式、你所希望的字符。阻塞、过滤或者忽略其它的任何东西。
  2. 保护所有敏感的功能，以防被 bots 自动化或者被第三方网站所执行。实现 session 标记（session tokens）、CAPTCHA 系统或者 HTTP 引用头检查。
  3. 如果你的 Web 应用必须支持用户提供的 HTML，那么应用的安全性将受到灾难性的下滑。但是你还是可以做一些事来保护 Web 站点：确认你接收的 HTML 内容被妥善地格式化，仅包含最小化的、安全的 tag（绝对没有 JavaScript），去掉任何对远程内容的引用（尤其是样式表和 JavaScript）。为了更多的安全，请使用 httpOnly 的 cookie。

Ref