XSS攻击实验（Elgg）

 

 

 

作业题目

跨站点脚本（XSS）是一种常见于web应用程序中的计算机安全漏洞。此漏洞使攻击者有可能将恶意代码（如JavaScripts）注入受害者的web浏览器。

为了演示攻击者可以做什么，我们在预先构建的Ubuntu VM映像中设置了一个名为Elgg的web应用程序。我们已经注释掉了Elgg的一些保护方法，故意使其容易受到XSS攻击。学生们需要利用这些漏洞发动攻击，就像Samy Kamkar在2005年通过臭名昭著的Samy蠕虫对MySpace所做的那样。此攻击的最终目标是在用户之间传播XSS蠕虫，这样无论谁查看受感染的用户配置文件都会受到感染，无论谁受感染都会将您（即攻击者）添加到他/她的好友列表中。

实验步骤及结果

0 Lab Environment Setup

1. 设置DNS

更改系统配置文件/etc/hosts:

1. 开启docker

解压项目文件，进入labset文件夹，创建docker:

开启docker:

出现错误：

重装虚拟机，重复上诉步骤，没有出现问题：

查看状态:

开启成功。

打开www.seed-server.com，还是不行：

更改默认引擎为必应：

览器输入 about:config ，点击Accept the Risk and continue，跳转后搜索：security.ssl.enable_ocsp_stapling。

双击将true改为false。

访问成功。

根据实验提供的用户和密码，尝试登录samy账号：

登录成功：

1. 熟悉"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"进行抓包，得到结果：

可以发现：

1. 目标URL为http://www.seed-server.com/action/friends/add，URL包含三个参数：friend，时间戳和秘密令牌。
2. 添加好友请求要指明添加用户的ID，samy的用户ID是59。
3. URL中还有两个额外的参数__elgg_ts和__elgg_token，这是Elgg应对CSRF攻击的对策，这两个参数的值和具体的页面有关。
4. 没有会话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"进行抓包，得到结果：

可以发现：

1. 目标URL是http://www.seed-server.com/action/profile/edit。
2. URL的参数name是用户名，从被攻击者的网站中获取。
3. description是About me字段对应的区域，是这次的攻击目标。
4. accesslevel[description]用于指明谁能看到description区域，把它设置为2表示所有人都能看到该区域（pubic）。
5. 用于编辑个人资料的请求都要包含一个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

实现蠕虫的自我传播首先要实现自我复制，实现自我复制有两种方法：一种是从外部获取（把程序放在文件中或者网络中，需要时从那些地方读取）；另一种是完全靠自身输出一份一模一样的程序拷贝。

使用从外部获取的方法，有两种典型的方法：

1. 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。

1. 链接方法

修改/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会告诉该浏览器哪些代码可以执行，哪些不可以执行，攻击者即使发现了漏洞，也无法注入脚本。