本文共 2624 字,大约阅读时间需要 8 分钟。
引入:
最近在tech audit别的团队的实现,发现他们代码中存在着一些XSS(跨站脚本攻击)的问题。回想以前我们团队的代码也被IBM的AppScan扫描出一些类似问题,基于很多人对于XSS没有非常清晰的了解,今天下午,我专门做了点小例子来详细阐述什么是XSS。
实践:
其实XSS,定义不重要,大家都知道,js能力很强大,所以我如果发一段恶意的js代码给受害者,在受害者的环境去中执行的话,就会得到许多不可估量的后果。从宏观上分,大概分2类,一类是来自内部的XSS攻击,一种是来自外部的XSS攻击。我们这文章主要讲解来自内部的XSS攻击。
其实来自内部的XSS攻击很容易理解,假设我是攻击者,A是受害者,那么我要攻击A,怎么办呢?
因为根据同源策略,我就算写一段javascript,这段JS是没有办法去操作A环境的,这种情况下,我没办法让A受到伤害,这时候我会这么做:
首先,我给A 发送一个恶意的Web URL,但是为了吸引B去点击,我可能在这个URL的表面放一些有吸引力的内容(比如美女图片等)
果不其然,A上当了,他点击并且查看了这个URL
而我给A的URL其实包含了一段javascript,而A并不知道这件事情。
因为我的JS无法直接操作A的机器,但是因为A点击了那个链接,于是这段JS 成功的在A的本地域执行。
因为JS在本地域有很大的权利,因此我可以做很多可怕的操作,大家都知道。
为了模拟上述操作,我们有如下的代码:
攻击者页面(假设是心怀不轨的我写的):
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 | <%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> < html > < head > < meta http-equiv = "Content-Type" content = "text/html; charset=UTF-8" > < title >恶意脚本发送方页面demo</ title > </ head > < body > < form action = "xss_victim1.jsp" method = "post" > < p align = "center" >< strong >恶意脚本发送方页面demo </ strong ></ p > < div align = "center" > < table width = "270" border = "0" > < tr > < td width = "130" >< strong >输入一段脚本:</ strong ></ td > < td width = "120" >< input name = "input" type = "text" id = "input" /></ td > </ tr > < tr > < td width = "100" > < input name = "submit" type = "submit" value = "点击触发恶意脚本" /> </ td > </ tr > </ table > </ div > </ form > </ body > </ html > |
然后这个页面提交到受害者页面,假如我就让他打出我们刚输入的脚本:
1 2 3 4 5 6 7 8 9 10 11 12 | <%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> < html > < head > < meta http-equiv = "Content-Type" content = "text/html; charset=UTF-8" > < title >恶意脚本结果展示页面</ title > </ head > < body > 你输入的内容是: <%=request.getParameter("input") %> </ body > </ html > |
现在我们来演示:
比如,我现在在一个恶意页面上有一个文本输入框,用户可以输入任何内容进去,如果是输入一般字符串,那么没问题,假设我们输入一段脚本(或者说这段脚本不是让用户输入的,而且是页面的背面我们拼凑上去的):
这时候在受害者页面xss_victom1.jsp中就会运行这段js.当然了,我们这里是善意的,只是弹出一个alert对话框,如果恶意的话,你懂的。。。
我刚测试了,非常幸运的是,Chrome在XSS的安全防范方面做的非常好,如果我吧刚才的例子运行在Chrome浏览器中,在受害者页面会显示:
拒绝执行这段脚本
总结:
所以从这里可以看出,对于来自内部的xss攻击,其本质是吧有毒的东西(比如一段恶意js脚本)送到受害者内部,让其在内部影响受害者的系统。因为同源策略,我没办法直接侵犯,所以采取这种方式,打个不恰当的比方,我(入侵者)要侵略某国家(受害者),我没办法让我的炸弹(恶意代码)直接炸那个国家(受害者),因为他们防护措施(同源策略)太好了,怎么办呢?我先买通他们国家某个官员(比如色情图片的链接),然后让这个官员携带了我要放的炸弹(恶意脚本代码) ,然后这个官员很轻松的通过外交通道免按键入境,然后这个官员到达他国家之后引爆这个炸弹(脚本代码执行在受害者本地机器上)