最基础的XSS语句:

<script>alert(123)</script>
<img src=a onerror=alert(123)>
.....

当然基础语句还有很多,但这里总结更多讲述一下实战的XSS。

怎么寻找XSS点?

XSS一般会出现在输入框中,url的参数,post提交的参数又或者是HTTP头。

实际渗透测试中一般出现在查询框以及表单提交框。

但很多情况下会对输出语句进行编码处理。

一般的<input value="输入部分">框需要对其进行闭合
但如果后端使用了htmlspecialchars等其他对输出进行编码的函数,我们插入的XSS就会变成:
输入部分"><script>alert(123)</script>
拼接后会变成:
<input value="&quot;&gt;&lt;script&lt;alert(123)&lt;script&gt;

最麻烦的其实不是大小括号被html实体了最麻烦的是双引号变成了quot.

这样value不被闭合导致永远输入的语句不能单独成句也就是构成不了xss.

这里我们拿XSS-labs中的less2来做实验:

1

这里原题很简单我们可以看到直接闭合value再构造如下:

"><script>onerrror=alert(123)</script>
就这样即可成功弹窗,但我们对输出到页面中的加上htmlspecialchars
<?php 
ini_set("display_errors", 0);
$str = $_GET["keyword"];
echo "<h2 align=center>没有找到和".htmlspecialchars($str)."相关的结果.</h2>".'<center>
<form action=level2.php method=GET>
<input name=keyword  value="'.htmlspecialchars($str).'">
<input type=submit name=submit value="搜索"/>
</form>
</center>';
?>
<?php 
echo "<h3 align=center>payload的长度:".strlen($str)."</h3>";
?>

这样再次插入XSS就变成了:

2

这里可以看到已经是无法注入了。

所以平常渗透尽量寻找那种粗心的程序员使用value=’输入部分’

这里即使使用了htmlspecialchars函数也不会转义单引号,默认

对于input框中可以利用的姿势也多多了,可以用各种各样的事件,也就是on开头的。即使有WAF过滤也不怕:

绕Waf参考:黑白之道里面看到的文章-XSS过WAF

Tony大佬的Fuzz.

看了以上,自己XSS绕WAF的能力一下就提升了,前面刷XSS-Labs就发现到过滤用户输入始终是不可靠的,可以采用各种各样的方式进行绕过,因而输出编码比输入过滤更靠谱。

但一定要注意避免使用单引号闭合的情况。

平时测试输入框(常见搜索框)的时候可以到源码中先测试(以下为Tony大佬的实战小技巧)

123456>"'
然后再去源码中ctrl+f查找123456看双引号是否变成了&quot;

如果没有这样的变化那绝大部分都还可构造出XSS。

更多姿势进行-Xss

比如可以上传html的点,可以在html文件中放入Xss语句那么也可弹窗。

今天get到了一个更牛X的地方,这个需要思考后端处理方式。例如有些系统会允许上传word,excel类文件。其甚至会把这些文件的内容顺带存入数据库中或显示出来。

这里同样可以把XSS语句放入其中造成存储型XSS。

反正有一个可以传txt的地方,然后同事上传了一个XSS内容的txt成功弹窗。

真的是tql!

今天回顾白帽子web安全的时候也学到了一个好知识:

http头是通过:"\r\n"来进行分割的,因而如果服务器端没有过滤"\r\n"那么也会造成XSS
例如url中存在:email=a%0d%0a%0d%0a<script>alert(123)</script>
这个%0d%0a会使其在包中换行而变成:
POST
http://ip/?email=a%0d%0a%0d%0a<script>alert(123)</script> HTTP/1.1
而成功Xss

最后想补充一下XSS的存在验证不只是弹窗,还可以用console.log(1)

如果在控制台中输出了1那么也是存在XSS的。

以后还有XSS的新get点都放到这篇文章中了。

参考:黑白之道里面看到的文章-XSS过WAF

以及大佬Tony对我的帮助。