作业题目
跨站点脚本(XSS)是一种常见于web应用程序中的计算机安全漏洞。此漏洞使攻击者有可能将恶意代码(如JavaScripts)注入受害者的web浏览器。
为了演示攻击者可以做什么,我们在预先构建的Ubuntu VM映像中设置了一个名为Elgg的web应用程序。我们已经注释掉了Elgg的一些保护方法,故意使其容易受到XSS攻击。学生们需要利用这些漏洞发动攻击,就像Samy Kamkar在2005年通过臭名昭著的Samy蠕虫对MySpace所做的那样。此攻击的最终目标是在用户之间传播XSS蠕虫,这样无论谁查看受感染的用户配置文件都会受到感染,无论谁受感染都会将您(即攻击者)添加到他/她的好友列表中。
实验步骤及结果
0 Lab Environment Setup
- 设置DNS
更改系统配置文件/etc/hosts:
- 开启docker
解压项目文件,进入labset文件夹,创建docker:
开启docker:
出现错误:
重装虚拟机,重复上诉步骤,没有出现问题:
查看状态:
开启成功。
打开www.seed-server.com,还是不行:
更改默认引擎为必应:
览器输入 about:config ,点击Accept the Risk and continue,跳转后搜索:security.ssl.enable_ocsp_stapling。
双击将true改为false。
访问成功。
根据实验提供的用户和密码,尝试登录samy账号:
登录成功:
- 熟悉"HTTP Header Live" tool
"HTTP Header Live" 是火狐浏览器上的插件,可以帮助我们捕捉和分析HTTP请求。插件已经在浏览器中下好。
Task 1: Posting a Malicious Message to Display an Alert Window
访问一个网页时,网页中的JavaScript代码会在用户的浏览器上运行,利用社交媒体中可以允许用户修改的地方,嵌入我们想要浏览器执行的JavaScript代码,就可以让浏览器执行我们想让它做的事。
在Elgg用户的profile中嵌入一个JavaScript程序,当另一个用户(Alice)查看samy的profile时,将执行JavaScript程序,并显示一个警报窗口。
对于较短的js代码,我们可以在profile里的Brief Description直接插入xss代码:
对于长一点的js代码,可以把代码存储在一个独立的文件中,然后调用它们。
登录Alice的账号,查看Samy,弹出弹框:
Task 2: Posting a Malicious Message to Display Cookies
在Elgg用户的profile中嵌入一个JavaScript程序,这样当另一个用户(Alice)查看profile时,他的Cookie将显示在警报窗口中。
登录samy账号,在profile里的Brief Description直接插入xss代码:
登录Alice账号查看,可以看到Cookie显示在弹窗中:
Task 3: Stealing Cookies from the Victim’s Machine
在Elgg用户的profile中嵌入一个JavaScript程序,这样当另一个用户(Alice)查看profile时,他会向攻击者(samy)发送一个HTTP请求,并将自己的cookie附加到请求中。
当浏览器加载网站时,会向<img>的src发送GET请求,我们可以利用这一点伪造请求。
查看攻击者的ip,为172.17.0.1:
登录samy账号,在profile里的Brief Description直接插入xss代码:
监听端口5656:
攻击端接收到包含cookie数据的HTTP请求信息:
Task 4: Becoming the Victim’s Friend
登录Alice账号,合法添加Samy为好友,同时使用"HTTP Header Live"进行抓包,得到结果:
可以发现:
- 目标URL为http://www.seed-server.com/action/friends/add,URL包含三个参数:friend,时间戳和秘密令牌。
- 添加好友请求要指明添加用户的ID,samy的用户ID是59。
- URL中还有两个额外的参数__elgg_ts和__elgg_token,这是Elgg应对CSRF攻击的对策,这两个参数的值和具体的页面有关。
- 没有会话cookie,Elgg不会处理这个请求,而浏览器会自动填写cookie字段。
如果发送一个普通的HTTP请求会导致浏览器离开当前页面引起用户的警觉,所以,我们使用Ajax后台发送HTTP请求。
因此,我们构造攻击代码:
注意,实验给的代码里没有Ajax.setRequestHeader("X-Requested-With","XMLHttpRequest");,如果服务器期望这个请求是AJAX请求,但并没有收到 X-Requested-With: XMLHttpRequest 的头部,那么服务器可能会返回一个错误或者一个完全不同的响应。
登录Samy账号,将攻击代码插入About me字段,此字段提供了两种编辑模式:编辑器模式(默认模式)和文本模式。编辑器模式将向输入的文本添加额外的HTML代码,而文本模式则不会。由于我们不希望在我们的攻击代码中添加任何额外的代码,所以启用文本模式(点击Edit HTML)。
登录Boby账号,这时候还没有添加Samy:
访问Samy主页后,查看friends,已经添加Samy:
• Question 1: Explain the purpose of Lines ➀ and ➁, why are they are needed?
ts 和 token 是用于防范 CSRF 攻击的秘密令牌,它们在发送请求时会一并发送到服务器进行验证。只有通过验证的请求才会被视为有效。因此,当我们模拟发送添加好友请求时,必须在请求中包含这些令牌值。
• Question 2: If the Elgg application only provide the Editor mode for the "About Me" field, i.e., you cannot switch to the Text mode, can you still launch a successful attack?
不可以。
因为它会在代码中添加格式数据,插入各种标记并转义某些特殊字符,导致JavaScript代码出现问题。
Task 5: Modifying the Victim’s Profile
编写一个XSS蠕虫修改受害者的About me字段,这种蠕虫不会自传播。
登录Samy账号,合法修改About me字段,同时使用"HTTP Header Live"进行抓包,得到结果:
可以发现:
- 目标URL是http://www.seed-server.com/action/profile/edit。
- URL的参数name是用户名,从被攻击者的网站中获取。
- description是About me字段对应的区域,是这次的攻击目标。
- accesslevel[description]用于指明谁能看到description区域,把它设置为2表示所有人都能看到该区域(pubic)。
- 用于编辑个人资料的请求都要包含一个guid字段用于指明谁的资料需要被更新,这个值就是被攻击用户的guid,可以从网站的js变量中获取。
因此,我们构造攻击代码:
将攻击代码插入Samy的About me字段:
登录Alice账号,此时主页为空:
访问Samy主页后,再查看Alice主页,出现修改的About me:
• Question 3: Why do we need Line ➀? Remove this line, and repeat your attack. Report and explain your observation.
这行代码判断当前用户的guid是否是Samy(攻击者本人)的guid,可以避免自己被攻击。
去掉这一行这,Samy主页的About me会被修改:
原来的代码被覆盖了,其他用户访问Samy主页后,不再被攻击,攻击就失效了。
Task 6: Writing a Self-Propagating XSS Worm
实现蠕虫的自我传播首先要实现自我复制,实现自我复制有两种方法:一种是从外部获取(把程序放在文件中或者网络中,需要时从那些地方读取);另一种是完全靠自身输出一份一模一样的程序拷贝。
使用从外部获取的方法,有两种典型的方法:
- DOM方法
当一个页面加载完毕时,浏览器会把页面内容存放在一个树的数据结构(DOM)中,并提供API让JavaScript访问和修改这些结点。
JavaScript代码也会被存成树的一个结点,我们可以使用DOM API从结点获取该代码。
因此,我们构造攻击代码:
为了便于寻找结点,设置id=worm,使用document.getElementById
("worm")找到该节点,然后用innerHTML属性获得其内容。
innerHTML只能提供结点内部内容,不包含scrip标签,所以我们自己加上一头一尾的script标签,这样就构成了完整的相同恶意代码。
注意:要使用"</" + "script>"来构造"</script>",不然火狐浏览器会认为"</script>"是这个代码块的结束符而忽略剩下的代码。
必须把访问等级设置为2(public),这样蠕虫才能传播下去。
登录Samy账号,在About me中插入恶意代码:
登录Alice账号,查看Samy主页后查看自己主页:
已被更改。
登录Boby账号,查看Alice主页后查看自己主页和Edit profile:
已被更改,说明蠕虫成功感染Alice。
- 链接方法
修改/etc/hosts,添加:
然后配置Apache。
在/var/www目录下创建/test.com/html目录,再在html目录下创建test.js(恶意代码):
在/etc/apache2/site-available下创建新的配置文件test.com.conf:
配置文件内容:
启用使用a2ensite工具创建的配置文件并重启Apache服务::
测试是否存在任何配置错误:
在浏览器中打开www.test.com/test.js:
开始实验。
登录Samy账号,修改主页About me:
登录Charlie账号,查看自己主页:
访问Samy主页后再次查看:
登录Alice账号,访问Charlie主页,查看自己主页:
Edit profile:
证明xss蠕虫成功攻击并感染Charlie和Alice。
Task 7: Defeating XSS Attacks Using CSP
XSS漏洞的基本问题是HTML允许JavaScript代码与数据混合。因此,为了解决这个基本问题,我们需要将代码和数据分开。
通过一种称为内容安全策略(CSP)的安全机制可以实现告诉浏览器哪个代码源代码是可信的。
example60和example70站点用于托管JavaScript代码,example32a, example32b和example32c是有不同CSP配置的三个网站。
三个网站有相同的index.html:
但因为CSP不同,能成功被执行的JavaScript代码不同,最终显示在浏览器上的网页会有所不同。
访问www.example32a.com:
全部OK,点击按钮弹出弹窗,因为没有任何防护措施。
访问www.example32b.com:
只有4,6是OK的,点击按钮不弹出弹窗,这是因为配置了CSP:
访问www.example32c.com:
只有1,4,6是OK的,点击按钮不弹出弹窗,是因为通过php文件导入了CSP:
修改image_www/apache_csp.conf,添加*.example60.com :
暂停容器,重新配置docker,重新开启docker,再次查看www.example32b.com:
Area5变成了OK.
修改image_www/csp/phpindex.php文件,添加'nonce-222-222-222' *.example60.com :
暂停容器,重新配置docker,重新开启docker,再次查看www.example32c.com:
Areas 1, 2, 4, 5, 和 6都OK。
解释CSP原理:
CSP是白名单机制,当浏览器请求一个网站时,CSP会告诉该浏览器哪些代码可以执行,哪些不可以执行,攻击者即使发现了漏洞,也无法注入脚本。
标签:XSS,浏览器,主页,攻击,Elgg,代码,Alice,Samy,com From: https://www.cnblogs.com/wxrwajiez/p/18516119