XSS简介——精选推荐

XSS简介
1. XSS简介
跨站脚本攻击，英⽂全称是Cross Site Script，本来缩写是CSS，但是为了和层叠样式(Cascading Style Sheet,CSS)有所区别，所以在安全领域叫做“XSS”。

XSS攻击，通常是指⿊客通过“HTML注⼊”篡改了⽹页，插⼊了恶意的脚本，从⽽在⽤户浏览⽹页时，控制⽤户浏览器的⼀种攻击。

在⼀开始，这种攻击的演⽰案例是跨域的，所以叫做“跨站脚本”
XSS长期以来被列为客户端Web安全中的头号⼤敌。

因为XSS破坏⼒强⼤，且产⽣的场景发杂，难以⼀次性解决。

现在业内达成的共识是：针对各种不同场景产⽣的XSS，需要区分情景对待。

第⼀种类型：反射型XSS
反射型XSS只是简单地把⽤户输⼊的数据“反射”给浏览器。

也就是说，⿊客往往需要诱使⽤户“点击”⼀个恶意链接，才能攻击成功。

反射型XSS也叫做“⾮持久型XSS”(Non-persistent XSS)
第⼆种类型：存储型XSS
存储型XSS会把⽤户输⼊的数据“存储”在服务器端。

这种XSS具有很强的稳定性。

⽐较常见的场景就是，⿊客写下⼀篇包含有恶意JavaScript代码的博客⽂章，⽂章表达后，所有访问该博客⽂章的⽤户，都会在他们的浏览器中执⾏这段恶意的JavaScript代码。

⿊客把恶意的脚本保存到服务器端，所以这种XSS攻击叫做“存储型XSS”。

存储型XSS通常也叫做“持久型XSS”(Persistent XSS)，因为从效果上来说，它存在的时间⽐较长的。

第三种类型：DOM Based XSS
这种类型的XSS并⾮按照“数据收费保存在服务器端”来划分，DOM Based XSS从效果上来说也是反射型XSS。

XSS的防御
XSS的防御是复杂的。

流⾏的浏览器都内置了⼀些对抗XSS的措施，⽐如Firefox的CSP、Noscript扩展，IE 8内置的XSS Filter等。

对于⽹站来说，也应该寻找优秀的解决⽅案，保护⽤户不被XSS攻击。

2.1 HttpOnly
HttpOnly最早是由微软提出，并在IE 6中实现的，⾄今已经逐渐成为⼀个标准。

浏览器将静⽌页⾯的JavaScript访问带有HttpOnly属性的Cookie。

严格地来说，HttpOnly并⾮为了对抗XSS——HttpOnly解决的是XSS后的Cookie劫持。

2.3 正确地防御XSS
为了更好地设计XSS防御⽅案，需要认清XSS产⽣的本质原因。

XSS的本质还是⼀种“HTML注⼊”，⽤户的数据被当成了HTML代码的⼀部分来执⾏，从⽽混淆了原本的语义，产⽣了新的语义。

如果⽹站使⽤了MVC架构，那么XSS就发⽣在View层——在应⽤拼接变量到HTML页⾯时产⽣。

所以在⽤户提交数据处进⾏输⼊检查的⽅案，其实并不是在真正发⽣攻击的地⽅做防御。

想要根治XSS问题，可以列出所有XSS可能发⽣的场景，再⼀⼀解决。

换个⾓度看XSS的风险
前⽂谈到的所有XSS攻击，都是从漏洞形成的原理上看的。

如果从业务风险的⾓度来看，则会有不同的观点。

⼀般来说，存储型XSS的风险会⾼于反射型XSS。

因为存储型XSS会保存在服务器上，有可能会跨页⾯存在。

它不改变页⾯URL的原有结构，因此有时候还能逃过⼀些IDS的检测。

⽐如IE 8的XSS Filter和Firefox的Noscript Extension，都会检查地址栏中的地址是否包含XSS脚本。

⽽跨页⾯的存储型XSS可能会绕过这些检测⼯具。

从攻击过程来说，反射型XSS，⼀般要求攻击者诱使⽤户点击⼀个包含XSS代码的URL链接；⽽存储型XSS，则只需要让⽤户查看⼀个正常的URL链接。

⽐如⼀个Web邮箱的邮件正⽂页⾯存在⼀个存储型的XSS漏洞，当⽤户打开⼀封新邮件时，XSS Payload会被执⾏。

这样的漏洞极其隐蔽，且埋伏在⽤户的正常业务中，风险颇⾼。

从风险的⾓度看，⽤户之间有互通的页⾯，是可能发起XSS Worm攻击的地⽅。

⽽根据不同页⾯的PageView⾼低，也可以分析出哪些页⾯受XSS攻击后的影响会更⼤。

⽐如在⽹站⾸页发⽣的XSS攻击，肯定⽐⽹站合作伙伴页⾯的XSS攻击严重得多。

在修补XSS漏洞时遇到的最⼤挑战之⼀是漏洞数量太多，因此开发者可能来不及，也不愿意修补这些漏洞。

从业务风险的⾓度来重新定位每个XSS漏洞，就具有了重要的意义。