渗透学习-XSS-基础知识部分（持续更新中）

---

前言

跨站脚本攻击（XSS）是客户端脚本安全中的头号大敌。 OWASP TOP 10威胁多次吧XSS列在榜首。本文将接下来具体的探讨XSS攻击的原理，以及如何正确的防御它。

---

一、XSS跨站攻击的原理分类以及攻击的手法

XSS 跨站脚本攻击，英文称之为 Cross Site Script， 为了与层叠样式CSS进行区分，在安全领域中就将其命名为XSS。

一般来说，XSS攻击通常都是指黑客通过“HTML/PHP 的注入”从而篡改了网页，插入了恶意的脚本，这就可以使得用户在进行正常浏览网页时，可以进行控制用户浏览器的一种攻击。换句话说就是：程序对输入和输出没有做合适的处理，导致“精心构造”的字符输出在前端时被浏览器当作有效代码解析执行从而产生危害。

在一开始，这一种攻击是进行跨域的，但随着现在攻击技术以及浏览器功能的越发成熟，这里是否跨域已经不那么重要了。但由于历史原因，我们仍然沿用XSS这个名字。以下呢，将具体详细述说一下比较经典的大致攻击原理。

攻击者会构造一个跨站页面，利用javascript脚本等，使得用户进行浏览这个页面时，能够触发对该站点的一次http请求。此时，若此时用户已经在该被攻击的页面中登录了，那么黑客就可以利用xss获取到其用户登录的凭证（cookie）。至此，用户就可以利用该用户凭证进行直接登录，而不需要密码账户等等！！

具体的XSS是什么样的呢？下面我们先展示一个简单的例子：

假设一个页面把用户输入的参数直接输出在页面上：

$input = $_GET['param'];
echo "
".$input."
";
?>
1
2
3
4

那么，我们只要向参数输入任何东西，都会都会被展示到页面之中。为了，方便理解，我们看看这展示的源代码：

那么，试想一下，如果我们提交一个html的页面代码进入其中会发送什么？

http://192.168.10.129:8080/xsstest.php?param=%3Cscript%3Ealert(document.cookie)%3C/script%3E
1

就可以很明显的看出我们能够获取对方当前用户登录的用户凭证了！！

在这种情况下，假设我们查询messi这个人名，那么页面就会

二、危害

基本上，凡是js脚本能够运行出来得出的结果，都可能会作为xss所造成的危害。其大致可以分为以下几种：

1、钓鱼欺骗

2、网站挂马

3、身份盗用

4、盗取网站用户信息

5、垃圾信息发送

6、劫持用户Web行为

7、XSS蠕虫

三、XSS的大致分类

反射型

这一类xss只会简单的把攻击者输入的数据反射给浏览器。其只能是一次性的，非持久化的。攻击者想要用户触发此漏洞，需要诱使用户点击hacker构造好的链接才能触发。

但是需要注意一点的是，就算是反射型的也会发到服务器端，由服务器端解析一下这个含有该参数的php文件。

存储型

该类型主要将用户输入的数据存在服务器中，这样子的话用户只要访问到该被注入的页面后就会直接的触发，不需要刻意构造一个恶意的url。其是持久化的，，具有超强的稳定性。

DOM型

这里借用小迪的课上的图来表示一下dom节点。

这一类的XSS是将脚本语句注入到html的DOM节点之中。可以直接在本地浏览器的静态前端代码中直接触发，而不需要发至服务器中！！

具体的攻击利用过程参考：
pikachu-XSS

四、有关XSS的一些其他知识

cookie与session

cookie 与 session 都是用于浏览器与服务端进行验证用户身份的会话凭据。但是两者还是有些微妙的区别的：

• cookie： 是存储在本地的（浏览器当中），存活时间一般较久 ；
• session：是存储在服务器端的，存活时间一般较端。相对来说使用session的安全性更高！！！

这两者，都是在用户登录以后存放一个token在其中，以此来记录用户的状态信息。而后，服务器只需根据其token值进行匹配查找，来读取对应用户的信息即可。

工具

shell箱子

这里，我们可以利用shell箱子进行收集对应的后台信息。也就是说，我们可以在一个木马里植入一些语句，使得我们可以获得该webshell对应的密码信息，以及所处的后台位置。这样子，当别人将你这个有后门的webshell，上传到某个网站服务器上时，你就可以坐享其成获得别人攻下的网站（俗称黑吃黑。。。。）

beef

一款linux上强大的xss管理工具，十分的好用！

具体的使用过程，请参考：xss

五、XSS的代码和httponly绕过

一般来说，如果http包中开启了httponly的话，那么客户端脚本就无法读取cookie了。因此，纵使该站点存在着XSS漏洞，也无法利用起直接读取cookie的。

我们可以直接在php.ini中，开启全局的httponly设置：

当然，我们也可以直接在setcookie的第七个参数进行设置HTTP only的开启。 当值为ture时，就是设置开启：

让我们来看看效果，开启与不开启httponly的对比图：

首先，我们关闭全局设定，以及在setcookie中进行关闭httponly的属性：

然后，设置脚本获取到cookie：

接下来我们先开启setcookie的第七个参数，或者直接开启全局设定后，我们在输入脚本语句，就可以看出我们已经无法获取到对应的httponly了：

---

参考文献

[1] 小迪课程
[2] 白帽子讲web安全