在过去的十年里，世界上已经有数以百万计的人在电脑上装了杀毒软件。在本文中，我们针对世界上Top 9杀软公司的网站里攻克下了8个，成功实现了XSS的利用。
前言
现如今的杀软已经非常成熟，还拥有了针对ransomware、间谍软件、木马、后门、蠕虫和rootkits等攻击的保护手段。
我们针对世界上Top 9杀软公司的网站里攻克下了8个，成功实现了XSS的利用。此外，下文会根据漏洞发现的难度和严重程度，对其进行评级，评级模型如下：
| Severity: ⅖
Difficulty: ⅘ |
而在报告给厂商后，我们还有个厂商响应评级供用户参考：
| Speed: ⅖
Interest: ⅘ |
下面我们进入正题，我们将分析一下每个触发弹窗的POC，并按困难程度进行排序：
各厂商XSS漏洞大合集
BitDefender(比特梵德)
影响域名：lv2.bitdefender.com
上面提到的这个子站，受影响的点在网站404页面，在路径处直接加上攻击向量(如
<script>alert(document.domain)</script>），就可以轻松进行XSS攻击。
评级：
| Severity: ⅖
Difficulty: ⅕ |
这个Severity评级是因为其与主域名共享了cookie，所以影响力是较大的。但是因为没有做XSS防护，所以Difficulty评级较低。
最终Payload如下：
| https://lv2.bitdefender.com/<script>alert(document.domain)</script> |
卡巴斯基
影响域名：kids.kaspersky.com
该子站的url里，其中age参数没有进行保护，加上攻击向量“>
评级：
| Severity: ⅖
Difficulty: ⅕ |
由于卡巴斯基这个子站也是跟主站共享cookie，而且也没有加防护，所以它跟BitDefender的XSS评分差不多。
最终Payload如下：
| https://kids.kaspersky.com/?age=”><svg/onload=alert(domain)> |
Panda Security(熊猫安全)
影响域名：download.pandasecurity.com
该子站影响在参数url上，在页面返回了三次，有两次在<h1>之间出现，还有一次出现在脚本内容（<script>标签）里。因为参数值并没有被编码或者转义，所以我们有两个选择。第一种就是用<svg onload=alert(domain)>用HTML标签注入payload。另一个选择是突破参数字符串的值，用-alert(document.domain)-进行利用，我们这里选择了第二种方式，因为固有的兼容性和简短性。
评级：
| Severity: ⅗
Difficulty: ⅖ |
这个Severity评级是由于cookie都没采用HttpOnly，所以带来了一定的风险，漏洞页面采用了403返回信息。
最终的payload：
| http://download.pandasecurity.com/cav/eng/malicious/?url=”-alert(document.domain)-“ |
小编批注：
可能有人会有点疑惑这里是如何触发的，我不会告诉你们某人傻气地跟我争论了半天(完全是毫无意义的好么!)，下面放一张图，大家可能会看得明白一点：
影响域名：search.avira.com
这个子站某个GET参数“gct”的值在返回页面出现了6次，但是其中有一个没有进行转义和加密，存在于一个脚本内容里，至于另外5处则是没有问题的。
最后我们再次选择了上面那个带减号的payload：
评级：
| Severity: ⅗
Difficulty: ⅗ |
这里Severity评级与Panda Security的网站类似，包括PHPSESSID在内都可以被黑客所取到，而Difficulty评级则是因为寻找漏洞页面费了点劲儿。
最终的payload：
| http://search.avira.com/?gct=’-alert(document.domain)-‘ |
AVG
影响域名：toolbar.avg.com
这个站的漏洞与前面四个都不同，其默认使用了微软的asp.net的默认过滤器，如果A-Z或a-z字符后跟了<，会被网站判定为XSS攻击。该web应用在GET参数“op”和“pid处，里面的值被设置为div标签的class值，我们这里采用的是onmouseenter事件。
评级：
| Severity: ⅖
Difficulty: ⅘ |
很可惜，这里的cookie采用了cookie保护，启用了HttpOnly选项，所以Severity评级并不高。
不过这里的Difficulty评级还是比较客观的，主要有以下原因。第一，受影响的页面不太好找，费了点时间。第二，ASP.NET自带的XSS过滤器还是很恶心的，增加了测试的难度。
我们只有一条路，突破class限制而不是div，那就需要用到JS事件句柄了。遗憾的是，常用的onmouseover事件被某WAF拦住了，我们只好换成了onmouseenter。然而，这坑爹的WAF还把“(”给ban掉了，不过最后还是让我们用HTML编码(给绕过了。
| http://toolbar.avg.com/almost-done?op=”onmouseenter=”alert%26lpar;document.domain)
http://toolbar.avg.com/almost-done?pid=”onmouseenter=”alert%26lpar;document.domain) |
Symantec(赛门铁克)
影响域名：library.symantec.com
该域名不同于此前其他案例，因为这个XSS是存储型的。Symantec并没有把代码放在该子站，而是采用了其他公司开发的某平台(Getty Images)。该存储型XSS影响了该子站的应用Lightboxes，它可以让用户创建自己的lightbox并与其他用户分享。
该漏洞存在于lightbox的name处：它的name出现在脚本内容里，而且没有做处理，所以就造成了一个严重的XSS攻击。自然而然，我们这里仍然选择了上面的那个payload。
评级：
| Severity:5/5
Difficulty: ⅘ |
该XSS漏洞在Severity评级达到顶级，是考虑了以下三个因素。第一，该XSS是存储型的影响力实在不小，还可能用作蠕虫。第二，就是这些cookie都没有采取任何保护措施。
最后还有一点，CSRF的token还是明文存在于页面的代码里。综上所述，黑客可以很容易取得其他用户的权限的。
至于Difficulty的评级是给花在寻找漏洞网站和漏洞点的时间上的，检查多个输入点和创建多个测试账户进行交互测试还是很费劲的。
这里的payload还是”-alert(document.domain)-”。
McAfee(迈克菲)
影响域名：
|
这里四个字站都受影响的原因，是因为他们都采用了同一套代码。受漏洞影响的GET参数term，在页面中出现了4次，其中3次都进行了编码，而还有一次进行单引号转义(因为在单引号之中)。
这里我们采用了一个非常有意思的payload，我们接着看：
评级：
| Severity: ⅖
Difficulty:5/5 |
这里的Severity评级是因为cookie是受保护的，而与此同时我们试图触发alert(document.domain)时，也遇到了很多困难。
第一个难点，我们由于单引号的过滤，用不了’-alert(document.domain)-’这类的payload了。
因此，我们尝试用事件句柄去注入HTML标签，绕过了这点。
第二个问题则是注入了HTML标签后，我们还是不能用alert(document.domain)。在这里“(”也被ban掉了。我们如果加上反引号(`) 则是可以弹窗的，但是弹出的是“document.domain”，而不是真实的网站域名。
我们尝试用(取替换“(”，结果返回了500页面。然后我们尝试加了“#”，这个标志符号通常能让我们加上额外的文本内容，而且不会被服务端所解析(只有客户端的属性location.hash会解析)。
我们这里来看看location based payloads，这里使用了javascript 协议，利用document.location属性来改变URL的导向。
不幸的是，我们没能使用下面的payload：
| </script><svg/onload=location=”javascript:alert”+location.hash>#(document.domain) |
因为location.hash回显的是#(document.domain)，而不是(document.domain)。我们不能使用substr()或者slice()函数，因为他们也使用了括号。
为了绕过这一点，我们使用了HTML元素的innerHTML属性，这会返回当前元素闭合和开放的标签内的文本内容。我们可以创建下面的payload：
| </script><svg/onload=location=”javascript:”+innerHTML+location.hash>”#”-alert(document.domain) |
上面的payload改变了页面里的document.location，转为javascript:”#”-alert(document.domain)。这里#因为包含在引号里，所以被解析为字符串，同样能触发弹窗。
最终payload：
| https://service.mcafee.com/webcenter/portal/cp/home/faq?term=</script><svg/id=javascript:+onload=location=id%2binnerHTML%2blocation.hash>”&mode=search#”-alert(document.domain)
https://att.mcafee.com/webcenter/portal/cp/home/faq?term=</script><svg/id=javascript:+onload=location=id%2binnerHTML%2blocation.hash>”&mode=search#”-alert(document.domain) https://verizon.mcafee.com/webcenter/portal/cp/home/faq?term=</script><svg/id=javascript:+onload=location=id%2binnerHTML%2blocation.hash>”&mode=search#”-alert(document.domain) |
相关内容在这里。
ESET
影响域名：www.eset.com
这里的XSS漏洞是通过GET参数q触发的，也就是查询关键词的内容。这是第三方厂商开发的一款名为TYPO3的CMS，我们发现了其中的XSS漏洞。
评级：
| Severity: ⅕
Difficulty: 5/5 |
这里的Severity评级是由于cookie设置了保护，但是需要用户交互才能触发。
而Difficulty设置的高评级，是因为我们花了许多时间寻找其他子站的XSS漏洞，然后才想到了去判定网站指纹，看看是否存在公开XSS漏洞。
接着，我们发现该网站采用了TYPO3的CMS，我们开始去Fuzz这个CMS的过滤器。后来，我们发现了Github上，该CMS放置了一些单元测试脚本，我们终于弄明白了过滤器的细节。
该CMS使用了黑名单来拦截事件句柄，如onclick之类的会被替换成on<x>click。而javascript:会被替换成ja<x>vascript:。与此同时，尖角符号也会被编码。我们尝试了javascript:来代替javascript:然后成功了。还有，我们也用( 和)代替了小括号。
在返回页面里输入内容出现了两次，一个在<strong>标签里，另一个在<input>标签的value值里。在该CMS里尖括号被HTML编码后，我们只有考虑向<input>标签里注入事件句柄和属性。
幸运的是，HTML5有了一个新的属性，也就是<input>标签可以调用的formaction。我们可以用它设置<form>里的action属性的值，<input>也在其影响之中。即使<input>标签里的action已经设置了值，我们还是可以覆盖里面action的参数值。
结合type属性使用上面提到的属性，我们可以将<input>转换为一个button，将document.location设置为“javascript:alert(document.domain)”。
最终的payload：
| https://www.eset.com/us/search/?q=1″type=image formaction=javascript%26colon;%26lpar;document.domain%26rpar;+1 |
在本节中，我们将杀软厂商的漏洞响应进行了评级，评级方式与前面大致相同。我们初始提交漏洞给各厂商时都是在1月27日，直到90天后我们才发布了这篇报告。
各厂商响应情况
BitDefender
我们在1月31日和3月1日分别给它发了消息，而在第三封消息后，他们才向我们要了漏洞细节。我们发现在此前他们已经修复了漏洞，但却没有给我们回信。
后来他们在4月12日声明这问题早已有人报告过，而且修复了(在我们发了初始报告之后的时间内修复的)，所以并没有给我们奖金。
评级：
| Speed: ⅕
Interest: ⅕ |
卡巴斯基
我们在发送初始报告消息后，在27分钟后就收到了厂商的回复，是诸厂商中最快的。
在2月4日漏洞被确认，我们检查了下漏洞已经被修复。我们在那天又发了消息给卡巴斯基，他们表示正在等待安全团队的消息。然而至今为止，还是没有下文。
评级：
| Speed: 5/5
Interest: ⅘ |
PandaSecurity
我们在给Panda Security发送初始报告后，还发过一封消息。在1月31日后，他们回复已经知晓了漏洞，并且在2月1日进行了修复，是厂商里最重视漏洞的。
评级：
| Speed: ⅘
Interest:5/5 |
Avira
在发送初始报告后，我们曾通过他们的推特账户进行联系。他们给了我们一个email地址，似乎是很重视他们的互联网用户安全的。
我们在2月2日向他们给的email地址，发送了该漏洞的POC。后来，我们又分别在2月8日、20日和27日也发送了消息，但是直到本文发布还是没收到任何回应。
然而，我们发现至少在4月21日以前该漏洞就已经被修复。但厂商没有表示任何形式的感谢，甚至根本不回复我们消息。
评级：
| Speed: ⅕
Interest: ⅕ |
AVG
AVG在我们初始报告两天后回复了我们，然后又在回复消息后10天内修复了该漏洞。为此，他们还奖励了我们一件T恤和一份感谢信。
| Speed: ⅘
Interest: ⅘ |
Symantec
Symantec在我们发出第二封消息(1月31日)后进行了回复，我们在2月2日发送了POC。直到我们又发了三封消息(2月8日、22日、27日)后，才确认了这个漏洞。他们表示已经联系了该平台的厂商，等待修复完成。
不过直到发文之时，该漏洞仍然没有修复。
评级：
| Speed: ⅕
Interest: ⅕ |
McAfee
我们尝试了各种方式联系McAfee，支持中心、推特账户，虽然他们最后还是回复了我们。后来，在2月4日我们给厂商发送了POC。但是，直到本文发布该漏洞仍然未修复。
评级：
| Speed: ⅕
Interest: ⅕ |
ESET
ESET在我们发送初始报告47分钟后就回复了，算是厂商中回复第二快的。在我们发送POC之前的当天(晚上9:57前)，漏洞就已经被修复，不过此前我们已经将利用结果的截图发过去了。为此，ESET还给我们发了一封正式的感谢函。
评级：
| Speed:5/5
Interest:5/5 |
Avast
Avast是我们唯一没有发现XSS漏洞的厂商，但并不意味着他们并没有这样的漏洞。毕竟这个测试项目，我们只花了一周的时间来做。但是这也许也象征着他们的WEB安全方面强于竞争对手，我们最后对他们的团队表示衷心的敬佩和祝贺。
本文来源于互联网:如何用XSS“干掉”90%的顶级杀软厂商