(SEED-LabCross-Site Scripting (XSS) Attack Lab跨站脚本攻击实验

(SEED-LabCross-Site Scripting (XSS) Attack Lab

跨站脚本攻击实验

欢迎大家访问我的GitHub博客

https://lunan0320.cn

一、实验目的

1. 掌握Cross-Site Scripting attack 的基本原理
3.应用XSS worm以及了解 self-propagation
4.掌握Session cookies的具体使用技巧
5.熟练使用HTTP GET and POST requests
6.了解JavaScript and Ajax的基本语法

二、实验步骤与结果

2 Lab Environment

2.1 The Elgg Web Application

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

由于实验环境已经在VM SeedUbuntu16.04上面配置完成，因此，直接在Firefox中访问即可。

也可以找到网站对应的文件夹目录。

2.2 DNS Confifiguration

查看DNS配置情况，直接查看/etc/hosts即可

2.3 Apache Confifiguration

本题目是使用的Apache服务器存储的所有web站点。根据题目提示，需要访问"/etc/ apache2/sites-available"目录，找到000-default.conf文件，该文件中的每个网站都有一个虚拟主机块，指定了站点的URL和文件系统中包含站点源的目录。

查看000-defult.conf文件，找到对应的VirtualHost块，可以找到需要访问的网站的信息包含其中，因此Apache Configuration已经完成。

3 Lab Tasks

3.1 Preparation: Getting Familiar with the “HTTP Header Live” tool

直接在firefox中安装HTTP Header Live插件

成功安装后

3.2 Task 1: Posting a Malicious Message to Display an Alert Window

3.2.1 直接JS代码

首先登录samy的个人账号

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

在firefox的无痕模式下，登录受害者Alice的账户。

在Alice的登录页内，看到Samy后，点开Samy的主页浏览。

可以看到，当Alice访问了攻击者Samy的主页之后，已经遭受了XSS的攻击。

3.2.2 保存JS文件XSS攻击

首先是需要修改/etc/hosts文件。在其中加入网站名和IP的映射。此处加入的是本机127.0.0.1到网站www.myXSS.com的映射关系。
这样做的原因是，当本机访问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攻击的效果。

3.3 Task 2: Posting a Malicious Message to Display Cookies

首先是修改Samy的个人profile，主要目的就是使其能够弹出自己的cookie。

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

3.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的界面是没有任何变化的。攻击成功！

3.5 Task 4: Becoming the Victim’s Friend

首先，为了构造一个合适的HTTP request，因此需要先了解在添加好友的时候需要对哪些部分做出改变。
根据文档中提供的代码，可以看到，需要修改的共两处。

第一处是需要send的url，这可以根据我们去尝试添加好友时候给出的request得出。

第二处是对文本类型的限制，设置为XMLHttpRequest的类型。

因此，构造之后可以得到如下的脚本文件。

接着将上述的JS脚本以HTML的方式添加到Samy个人主页的“About Me”专栏。

接着在Alice的主页上去搜索Samy，并查看Samy的profile。可以看到，在没有任何提示的情况下，Alice已经添加Samy为好友了。攻击成功！

Questions. Please answer the following questions:
• Question 1: Explain the purpose of Lines ➀ and ➁, why are they are needed?

答：这两行其实就是一种认证模式,，是为了防范CSRF攻击所采用的策略。正如浏览器中通常加的token一样。此处也是一种token来通过服务器验证的过程。该网站的Elgg服务器需要对用户认证，而这两行的代码就是绕过这中认证的过程，xss攻击中的代码是可以直接读时间戳timestamp以及秘密令牌secret
token的（CSRF中由于不是同源，因此无法访问）。直接自己构造处绕过验证的方式。

• Question 2: If the Elgg application only provide the Editor mode for the “About Me” fifield, i.e., you cannot switch to the Text mode, can you still launch a successful attack?

答：这是可以的。在文本编辑器中的话，会在之后转为HTML网页的时候对js代码的部分有所改变，即编辑器会向代码中添加格式化数据，这就破坏了代码的完整性，导致这种代码其实是无法正确当作js代码来正确在网页中执行的。但是，攻击者依然可以使用一个浏览器扩展来删除这些HTTP请求中的格式化数据，或使用其他客户端来发送请求，并非一定需要浏览器。

3.6 Task 5: Modifying the Victim’s Profile

该Task是要求当用户访问Samy的profile的时候，自己的Profile遭受Samy的XSS攻击，使得自己主页的Profile被恶意攻击者（Samy）篡改。
与Task4类似，此时也是需要查看一下修改用户Profile是怎样一个HttpRequest的格式。
此处，随意修改一下profile，在开发者工具中查看这个过程的HttpRequest的情况。
可以看到，发送的HttpRequest是POST请求，请求的RequestURL是http://www.xsslabelgg.com/action/profile/edit。

除此之外，查看Data中的数据，也就是在需要构造数据包的时候的Content的组成。必要组成部分如下图。
包括了token、ts、description、guid、name五项信息。从中也可以看到，Samy的guid为47。

需要注意到是此处的Content-Type已经不是Task4中的情况，因这个问题在本题目中做了好久，需要特别注意，没有观察到Conten-Type的变化。这是因为在POST请求中数据应该被编码。

根据上述信息，就可以构造Samy的xss脚本。

注：此处的content是data数据的组合，中间用&隔开。每一项都是一个键值对的映射。代码逻辑是只要该访问用户不是Samy，就对其的“About Me”字段做出修改。description中即是修改后的内容。

将上述代码用于Samy的AboutMe字段，且在HTML模式下编辑，保存。
使用Alice的账户访问Samy的Profile。可以看到，Alice在访问的过程中发送了POST请求，从右下角请求内容可以看出，即实现了对受害者Profile的修改。

回到Alice的Profile中，可以看到Alice的Profile的About me字段已经被恶意用户Samy篡改。攻击成功！

考虑更多用户是否均可以成功。因此登录Boby的账户，同样去访问Samy的账户。

同样，返回Boby的Profile，查看Boby的Profile是否被篡改。
可以看到，同样Profile被篡改，说明攻击是对其他用户也是有效的。攻击成功！

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

答：line 1如下，这是为了保证js代码不会攻击自身。

如果去掉后，在保存的过程中其实就是一次POST请求发送的过程，这个过程xss脚本同样会生效，因此攻击者自身的Profile也被篡改。

此时攻击者的Profile中就已经没有了xss脚本，此时别人的访问就不会收到影响，攻击失效。
可以看到，在保存的时候共有两次POST请求。

第一次POST请求即是对更改后内容的保存。

第二次POST请求即是攻击者xss代码生效，攻击自身的过程。

在这之后，其他用户如：Charlie去访问Samy的主页是不会被攻击的，攻击是失效的。
可以看到，Charlie去访问Samy的时候只有一个GET请求，并没有POST请求的发生。

查看Charlie也可以看到，并没有受到攻击。因此说明去掉line 1之后是不可以的，攻击是失效的。

3.7 Task 7: Countermeasures

3.7.1、only HTMLawed

如图所示是未开启HTMLawed的模式下的情况。

因此，先开启HTMLawed插件

开启之后，继续之前的代码。并通过Charile去访问Samy的主页，可以看到Samy的主页的About me部分已经是js代码了，而且需要注意的是这类标签已经被过滤了。
此时可以看到左下角只有一个GET请求，并没有出现POST请求，说明是没有执行XSS攻击的。

原因分析：开启了HTMLawed之后，该防御措施主要是对一些脚本标签的过滤，例如：

3.7.2、both countermeasures

根据文档要求，依次修改相关文件，取消对htmlspecialchars()函数的注释。
对/var/www/XSS/Elgg/vendor/elgg/elgg/views/default/output/目录下的text.php, url.php, dropdown.php and email.php做出修改。




修改之后，重启apache2服务器

重复之前的操作。可以看到效果是一样的。也是没有成功执行，以数据的形式展示出来了。

此时，乍一看感觉跟只开启HTMLawed是一个效果，似乎看不出有什么效果。
此时我查阅了htmlspecialchars（）的语法介绍。才了解到，此函数是对字符的转换，转换为了HTML实体，是需要查看源代码才可以发现的。

但实际上查看网页源码的时候可以发现不同。一些预定义的字符已经被替换。这就是htmlspecialchars()的防御方式。



查阅资料后发现，htmlspecialchars（）是将一些预定义的字符转换为HTML实体。比如说，将双引号转换为&quot，以及将&转换为&amp等

原因分析：htmlspecialchars()是PHP的一个内置函数，是将输入的特殊字符进行编码。因此，如果说用户输入的数据中出现了预定义的字符，此时通过该函数就会将其转换为其他的编码，这样对于注入的xss脚本就可以达到实际的抵御作用。

四、参考文献

[1] 前端安全系列（一）：如何防止XSS攻击？ - SegmentFault 思否
https://segmentfault.com/a/1190000016551188
[2]CSP内容安全策略总结及如何抵御 XSS 攻击 - 古兰精 - 博客园
https://www.cnblogs.com/goloving/p/11186176.html
[3]WEB安全之抵御Xss攻击_枸杞泡茶的博客-CSDN博客_抵御xss攻击
https://blog.csdn.net/weixin_42214548/article/details/102535447
[4]PHP htmlspecialchars() 函数 | 菜鸟教程 (runoob.com)
https://www.runoob.com/php/func-string-htmlspecialchars.html