网络攻防技术-XSS攻击实验（Elgg）（Cross-Site Scripting (XSS) Attack Lab(Web Application: Elgg)）

作业题目

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

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

二、实验步骤及结果

1. Lab Environment

1.1 DNS Setup
由于实验环境已经在VM SeedUbuntu16.04上面配置完成，可直接进入Labsetup文件夹，运行dcbuild和dcup两条命令构建并启动容器。

 

 

 

当访问www.xsslabelgg.com可以看到如下的界面，已经是配置好的Elgg网站，需要使用的话可以直接从中输入用户名和密码登录即可。

 

 

 

2. Lab Tasks

2.1 Preparation: Getting Familiar with the "HTTP Header Live" tool
直接在firefox中安装HTTP Header Live插件，成功安装后如图：

 

 

2.2 Task 1: Posting a Malicious Message to Display an Alert Window
2.2.1 直接JS代码XSS攻击

首先登录samy的个人账号，进入samy的个人profile，在任意编辑框中编辑即可。只需应用输入的JS代码，然后保存文件。

 

 

 

然后登录受害者Alice的账户，在Alice的登录页内看到Samy，点开他的主页浏览，发现已经遭受了XSS攻击。

 

 

 

2.2.2 保存JS文件XSS攻击
修改/etc/hosts文件，在其中加入网站名和IP的映射。此处加入的是本机127.0.0.1到网站www.myXSS.com的映射关系。这样当本机访问这个网站时，会优先到本机中去查询网页，相当于是访问了在本机搭建的网站。

 

 

 

接着需要修改的文件是/etc/apache2/sites-available/000-default.conf文件。这个文件是apache2服务器的默认站点访问文件。在此文件中创建一个myXSS文件夹，与http://www.myXSS.com相对应。

这样做的原因是，需要设置一个虚拟主机块。当访问http://www.myXSS.com网站域名时候，即是访问的在/var/www/myXSS文件夹下的目录文件。在此文件夹下创建的文件就是本网站的网页资源。

 

 

 

操作流程如下：

 

 

除此之外，为了达到xss的攻击效果，应当在/var/www/myXSS文件夹下创建一个myJS.js文件。此文件即是需要嵌入到profile中需要访问的内容。然后对apache2网站托管平台进行重启，以使得修改生效。

 

 

 

此时，重新编辑Samy的profile，使用的是内部隐藏字段的方式，将src后面链接到刚刚创建的JS代码处即可。

 

 

 

此时，在Alice的主页上去查看Samy的profile，点击之后即可弹出。由此可知，无论是单独的直接XSS攻击还是保存到文字中，通过隐藏字段的方式跳到指定JS文件，均可达到XSS攻击的效果。

 

 

 

2.3 Task 2: Posting a Malicious Message to Display Cookies

修改Samy的个人profile，使其能够弹出自己的cookie

 

 

 

然后登录Alice的账户，访问Samy的个人profile，可以看到弹出了Alice的个人cookie。说明攻击成功。

 

 

 

2.4 Task 3: Stealing Cookies from the Victim’s Machine

为了将受害者的cookie发送到攻击者的主机。尝试对Samy的profile做出如下修改：

 

 此处，设置的是127.0.0.1作为攻击者的主机，这样就可以不用开启两个虚拟机，在一个虚拟机中即可完成。

在虚拟机中开启9090监听端口。当Alice再次访问Samy的个人profile时候，可以在终端中看到攻击者已经拿到了Alice的cookie，然而Alice对此是一无所知的，因为Alice的界面是没有任何变化的。攻击成功！

 

 

2.5 Task 4: Becoming the Victim’s Friend
要自己实现这样一个蠕虫病毒，首先分析一下添加好友的HTTP请求。点击add friend按钮，然后分析请求报文。

 

 

分析可知，添加好友的接口url为：http://www.seed-server.com/action/friends/add，

传递参数：

friend参数代表添加的好友编号

__elgg_ts是一个时间戳（timestamp），用于验证令牌的时效性。

__elgg_token是实际的令牌值，用于验证用户的身份和权限。

修改给定的JS脚本，并以HTML的方式添加到Samy个人主页的“About Me”专栏。

 

 

 

在Alice的主页上搜索Samy，并查看他的profile，可以看到，Alice在没有任何提示的情况下，添加了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.,

不可以。因为它会在代码中添加各种标签并转义一些符号，如把<变成<  所以攻击不可能成功。下面是一个例子，展现了变换前后的代码

 

 

 

2.6 Task 5: Modifying the Victim’s Profile

在Samy的主页修改一下About me然后保存的同时用插件捕捉抓包

 

 

 

可知接口地址为：http://www.seed-server.com/action/profile/edit，请求方式是POST

 

 

 

内容为：

__elgg_token=ed9jIlIo6DxL5oikyAechg

&__elgg_ts=1729914567

&name=Samy

&description=<p>Your Profile Have Been Attacked!</p> &accesslevel[description]=2

&briefdescription=Hello world!&accesslevel[briefdescription]=2

&location=&accesslevel[location]=2

&interests=&accesslevel[interests]=2

&skills=&accesslevel[skills]=2

&contactemail=&accesslevel[contactemail]=2

&phone=&accesslevel[phone]=2

&mobile=&accesslevel[mobile]=2

&website=&accesslevel[website]=2

&twitter=&accesslevel[twitter]=2

&guid=59

 

其中有删除线的部分都可不写，不重要，我们只需要改description也就是About me板块

内容格式和刚才抓包获取的内容形式一样，&description后为想要给别人添加的介绍This is from Samy，请求url改成http://www.seed-server.com/action/profile/edit

可以构造JavaScript代码：

 

 

 

Alice账户登录后访问Samy的主页，再看个人主页，发现已被修改：

 

 

• Question 3: Why do we need Line ➀? Remove this line, and repeat your attack. Report and explain your observation.

 

去掉if判断，那么Samy一保存回到profile界面就会触发代码，about me板块就会被修改，原js代码就没了，无法攻击他人。所以必须加上条件，guid不能是自己。

2.7 Task 6: Writing a Self-Propagating XSS Worm
Link Approach:

先在本地创建一个新的网站，名为 t.com, 用于托管恶意脚本。在/etc/hosts中添加下面一行用于DNS解析

 

 

 

再在命令行中输入下面命令启用apache自定义请求头

 

 

 

在/etc/apache2/sites-available/000-default.conf中添加一个网站配置，并允许跨站请求，如下：

 

 

 

最后用下面命令重启apache

 

 

 

创建 /var/www/t/malscript.js 文件，此文件即为script标签的src属性所指向的文件。内容如下，功能与之前类似，只是desciption的内容多了一个script标签，其指向我们的外部恶意脚本。

 

 

 

此时访问http://www.t.com/malscript.js可以看到恶意脚本的内容

 

在samy账号编辑自己的主页，介绍内容如下，与上面的脚本基本一样，就是将其放在script标签中。

 

 

 

Samy账号修改完主页后，直接可以看到主页变成如下页面

 

再用Boby账号去访问Samy主页，Boby主页变成如下所示

 

 

 

再用Alice帐号去访问Boby主页，Alice主页变成如下所示

 

 

 

至此实现了XSS攻击从Samy扩散到Boby再到Alice的过程。

具体过程就是当访问已被攻击的主页时会加载我们的恶意脚本，恶意脚本会修改受害者的主页为"Your Profile have been attacked" 和 一个指向我们恶意脚本的script标签。

这形成了一个递归的过程，当有人再访问此轮受害者的主页时，又会重复上面的过程。因而形成了自扩散的XSS攻击。

DOM Approach:

这部分我们尝试不使用外部脚本实现自扩散XSS攻击。所使用的脚本如下：

 

 

 

具体过程与之前的修改主页过程类似。只不过修改的内容包含整个我们的恶意脚本，这部分内容不可能静态的写成字符串放在脚本内，因此我们要用脚本从DOM中读取恶意脚本的内容，拼接起来在发送请求即可。其encodeURIComponent是用来将发送的数据用URL Encoding格式编码。

将上面的脚本放到Samy的主页中，用charlie的账号访问Samy的主页，结果如下：

 

 

再用Alice的账号访问Charlie的主页，结果如下。

 

 

说明攻击成功，至此实现了XSS攻击从Samy扩散到Boby再到Alice的过程。

3. Task 7: Defeating XSS Attacks Using CSP

1. Describe and explain your observations when you visit these websites.

 

& 2. Click the button in the web pages from all the three websites, describe and explain your observations.

32a都是OK，32b只有4和6是OK，其他是Failed，32c只有1，4，6是OK

 

 

 

32a可以显示alert窗口，32b和32c不行。原因是apache_csp.conf中设定了一些CSP限制了脚本的来源

 

从www.content-security-policy.com网站上可以了解CSP规则

 

 

 

default-src指定了默认的资源加载策略，script-src指定了JavaScript脚本的加载策略

 

self表示只允许从同一域名加载资源，*.example.com表示只允许加载该域名的子域名的资源，unsafe-inline允许内联脚本（一般指script标签的JS代码）、onclick等的执行

32a和32b的页面源代码都用的是index.html，而32c用的phpindex.php也引入了index.html

查看index.html，从index.html可知1-6所有都是红色的Failed，id分别为area1-area6，后面才在对id为area1-area6的内容分别修改于是让它们变成绿色的OK。 这6个修改脚本来自于不同的来源。

 

 

example32a没有限制，所以可以看到所有行都换成了OK，而且button可以使用。

 

example32b有CSP，default-src 'self' 规定了所有类型的资源只能从当前域名加载。

<script src="script_area4.js"> </script>满足条件，于是第四行4被改为OK。

script-src 'self' *.example70.com规定了当前域名和example70.com域名的脚本才能加载，

<script src="http://www.example70.com/script_area6.js"> </script> 满足条件，第6行被改为OK

由于CSP中没有包含'unsafe-inline'选项，οnclick="alert('JS Code executed!')"就不能执行

 

 

对于example32c，default-src 'self';指定了默认的资源加载策略，只允许从当前域名加载资源。

script-src 'self' 'nonce-111-111-111' *.example70.com;指定只允许从同源、指定的nonce值nonce="111-111-111"或者example70.com域名加载脚本。

 

 

phpindex.php：

 

同样其他的源包括'unsafe-inline'是不被允许的，这也是为什么32c只有1. Inline: Nonce (111-111-111): OK、4. From self: OK、6. From www.example70.com: OK，其他是Failed， onclick不能实现

 

3. Change the server configuration on example32b (modify the Apache configuration), so Areas 5 and 6 display OK. Please include your modified configuration in the lab report.

 

进入/etc/apache2/sites-available 下的apache_csp.conf修改，加上*.example60.com

 

 

保存，重启apache服务

 

 

 

刷新www.example32b.com网页，发现5也变成了OK

 

 

假如尝试再加上'unsafe-inline'，123都变成OK，按钮也生效

 

 

4. Change the server configuration on example32c (modify the PHP code), so Areas 1, 2, 4, 5, and 6 all display OK. Please include your modified configuration in the lab report.

 

在docker中的/var/www/csp文件夹修改phpindex.php，重启apache2服务

 

 

 

结果：

 

5. Please explain why CSP can help prevent Cross-Site Scripting attacks.

 

CSP Header限制可以被允许加载的资源（如JavaScript、CSS、图像等）以及可以加载的URL。当应用程序使用严格的CSP策略时，发现XSS漏洞的攻击者将无法强制浏览器在页面上执行恶意脚本。CSP一般只允许具有正确的nonce值的脚本执行，攻击者无法猜测这个值，因此无法注入自己的脚本。