时隔半年终于也应该更新了，之前说的每周更新也因为懒散这个借口变得遥遥无期。之所以叫这个标题，是在Freebuf上看到一篇文章，开头作者问到：“网上大多的文章标题都是XXX从0开始，可我们到底什么时候能从1开始呢？”所以我决定写一些关于XSS的东西，具体能坚持多少，我也不知道。
正文：XSS——实际指CSS（Cross Site Scripting）,为了区别与层叠样式表将C写为X。一般我们将XSS称之为，跨站脚本攻击。之前我写的文章中提到过，凡是利用提交恶意代码的攻击都可以称之为注入，所以实际上XSS也是一种注入攻击。所以实际上，XSS造成原因是由于对< script>以及其他敏感关键词的忽视，没有进行适当的过滤而使得攻击者在页面中提交恶意代码形成攻击。如果你学过javascript下面引用的代码就很好理解，如果你并没有学过也不用担心，我会简单解释。之所以刻意说到javascript（下文简写js），是因为现在流行的浏览器100%的支持js，但实际上我们也可以利用flash等进行XSS攻击（不过负责任的说flash正慢慢退出市场），而且我们不一定非要利用到<>或者引号等等符号才能发起XSS更多的东西大家可以百度。后面我也应该会写。
对于XSS的分类，其实在写文前我看了一些网上流行的一些分类大致是反射型和持久型，这两种分法其实是基于依赖Web应用的。个别也有提到DOM XSS，这种方法是不依赖Web应用处理的，是一种纯粹的客户端XSS类型。其实XSS分类方法很多，除了上述的三种，我仅仅提出一个通用型 XSS的攻击方法，这个方法特殊的地方是在于不受SOP的限制（SOP：同源策略）。对于XSS的历史这里就不多赘述了，在这里我说一下如何查找XSS漏洞，这里提出的是利用工具的方法，手动的方法在介绍这4种攻击的时候，它的应用原理其实就是查找漏洞的方法。利用工具我推荐Pangolin，之前的文章我提到过这个工具，国产的，十分强大，多余就不解释了。还有一款国外的软件，BruteXSS，在Kali Linux下有这款工具。（学黑客必会Kali，我之前就在推荐啦！）
1.反射型XSS
它是将不安全的用户数据提交至Web应用上，当数据响应就会返回不可信的内容。因为浏览器直接反映的是服务器给出的代码，所以不会验证其安全性直接执行。一般这种方法的利用是通过在URL里面注入恶意代码，通过用户单击执行。因为这种方法只有单击通过后才会执行，所以这种方法也称为非持久型XSS，而且每次需要通过构建含有恶意代码的URL，所以十分不便。没听懂？没事！下面给大家看一下一些恶意的URL：
http：//www.baidu.com/search.php?key="><script>alert（“XSS”）</script>
http://www.baidu.com/userhome.jsp?user=<script%20src=http://www.baidu.com/hook.js></script>
<script>是js代码书写的标志，在第一个URL中，通过利用alert命令，当用户打开该URL时，页面中就会显示一个带有XSS内容的提示框（这也是手动查找该类XSS的方法，下一个方法也是，不过是换了位置）。你可能会想到，一个提示框算什么呢？但这正说明了，这个页面中并没有过滤类似<script>这样的敏感词，也意味着网站浏览者可以提交代码，并执行代码（这不就是在设计网页了吗？但实际上这个工作成了黑客具有的能力，而不再是前端人员了。）第二个方代码是利用src命令，使得网页重定位到/hook.js下，而这实际上是一个js文件，里面可以构建你的恶意代码。值得注意的是src前的%20，实际上是一个空格字符，说明这里可能为了躲过过滤系统设置的部分敏感词。但我们可以用其他方法来绕过过滤设置，除了利用%20的空格我们也可以利用Tab键。（一些过滤的方法，我会在后面提到）一般此类的XSS的出现位置在搜索栏，或者是用户资料信息填写等等，其实也不仅仅是此类了，XSS主要存在数据交互的地方都会可能出现。这类XSS一般可以用于钓鱼攻击，窃取cookies。在这里我要特别说出的是一般的钓鱼方法是采用搭建网站这种办法，但因为不会出现相同域名的情况，所以一般钓鱼网站的域名很容易辨析。但对于反射XSS的话，我们利用官方网站的漏洞，所以如果有人给你一个taobao的恶意URL，一般很有可能上当。但对于稍微有点安全意识的用户，一般不会随意点击他人给出的URL，更何况是后面带有js代码的URL。不过我们可以模糊URL，使得URL里的js代码没那么显而易见，其次也绕过了过滤设置。比如利用十进制等进制转换，ascii码等等方法。
2.存储型XSS
反射型XSS每次的构建URL实在麻烦，加上URL的隐蔽性确实值得商榷。所以一般推荐利用存储型XSS，这类XSS将恶意代码永久存储于web应用中，所以只要通过浏览器浏览都会执行恶意代码。因为存储在web应用中，所以很难被发现。比如我之前提及的flash中，如果我给你一个YouTube的网页，很有可能在你看视频的同时已经被攻陷了。我提交的代码仍然可以是上述的代码，显示出你的cookies或者重定位到某一个网站。这种方法一般利用的是后端的数据库保存代码，因为一般网站的web应用记录不具有XSS防御能力，在查看日志时都会导致浏览器渲染并运行恶意代码。这种方法的利用是针对网站的管理员，一般会添加在后台的数据交互区域，那么造成的危害就是对整个服务器和服务器组。
上图是去年雅虎邮箱中存在的存储型XSS，这是因为js代码对于date-url属性的渲染按钮导致的。因为Yahoo对YouTube所分享的视频没有严格的代码过滤筛查，所以对于之后黑客添加的html代码也直接加载。作者是来自芬兰某安全团队的研究员，大家可以去网上找下那篇文章（对学有余力的朋友建议），有翻译过的。
3.DOM XSS
正如我所提到的，这种方法不依赖web应用处理输入的漏洞。比如我们设置一个参数用于欢迎词，因为一般欢迎词会带有浏览者的ID或者昵称帐号。但对于ID这类参数，对不同浏览者会对应不同的欢迎ID，很明显这里包含了一个参数的变量。所以我们设置一下这个代码：
document.write(document.location.href.substr(
document.location.href.search(
/#welcome/i)+16,document.location.href.length)) (这里代码我引用于网上提供的一个思路）
一般我们会看到URL里面的id=某个数字的构成，那么对于上面这个代码，就是利用document.write命令进行一个欢迎词的书写，为方便理解你可以想象成id=数字，换成了welcome=123。也就是会出现欢迎123用户，这样的一个提示。如果是一个恶意代码的话，我们可以将URL构建成
http：//baidu.com/home.html#welcome=<script>document.location='google.com'</script>
注意，虽然这个看上去很像之前的反射型XSS，但实际上这是依赖与web应用的。DOM XSS对服务器是不可见的，所以这段危险代码将依存在浏览器。
4.通用型 XSS
这个方法够我写两篇了，这是在浏览器中执行js的方法，不受SOP制约。因为利用到浏览器缺陷，所以我给出一个09年的例子（书上看的）。
var sneaky = 'setTimeout("alert(document.cookie);",4000);
document.location.assign("http://gmail.com");';
document.location=
'chromehtml:"80%20javascript:document.write(sneaky)"';
上面的代码建立一个sneky变量，达到gmial加载时会延迟执行脚本的功能，在这里实际是延时显示cookies。这个DOM XSS应用针对的是主流的Chrome浏览器的缺陷。当然我们不一定要面对纯浏览器，因为一般浏览器会推荐使用类似谷歌翻译或者一些地图等等的插件组功能等等，我们也可以利用这些来攻破浏览器（想象一下吧，用这种浏览器的用户都得死！）所以通用型 XSS知道这些暂时就够了。
今天就写到这里了，好久没更新写了这些内容就累得够呛。（抱歉，没有及时更新。但我不会弃坑的，对自己也是一种巩固）文中利用的代码均为js代码，所以对于前端人员可以有一个很好的思路延伸。在下次我会继续补充，也十分感谢在头条和简书支持我的人，我会不断努力为大家带来有趣的内容。这次的文章中有部分网上或书上的引用，因为对与通用型 XSS和DOM XSS一般都会是针对浏览器的渗透测试以及后端的延伸，对于这方面我没有什么经验之谈只好引用。希望大家能去学习一些js基础和浏览器相关，对于XSS的学习有很大的帮助。
https://toutiao.io/k/xocw2s