XSSI是XSS的一种形式,即浏览器不会阻止网页加载图像和文字等资源,这些资源通常托管在其他域和服务器。例如,脚本可能提供攻击者需要的功能,帮助创建特定的页面。然而,这种包含可能被利用来从一个域名读取用户数据—当用户正在访问另一个域名时。例如,如果ABC银行有一个脚本用于读取用户的私人账户信息,攻击者可以在其自己的恶意网站包含这个脚本,当ABC银行的客户访问攻击者的网站时,攻击者就可以从ABC银行的服务器提取用户信息。

自上世纪90年代,攻击者就已经开始利用XSS漏洞,对谷歌雅虎进行攻击。与大多数应用层攻击不同的是,基于XSS的攻击会攻击应用的用户,而不是应用或服务器。这些攻击的工作原理是注入代码(通常例如JavaScript客户端脚本)到Web应用的输出。大部分网站有很多注入点,包括搜索域、cookies和表格。虽然这些恶意脚本不能直接感染服务器端信息,它们仍然可以破坏网站的安全性。通过使用Document Object Model操作来更改表格值,改变网页的外观或切换表格操作以张贴提交的数据到攻击者的网站,攻击者可以窃取数据、控制用户的会话、运行恶意代码或用作网络钓鱼欺诈的一部分。

XSS vs XSSI区别到底是什么?

开发者可以部署多种措施来抵御XSSI攻击。其中一种方法是向用户提供独特的不可预测的授权令牌,在服务器响应任何请求之前,需要发送回该令牌作为额外的HTTP参数。脚本应该只能响应POST请求,这可以防止授权令牌作为GET请求中的URL参数被暴露,同时,这可以防止脚本通过脚本标签被加载。浏览器可能会重新发出GET请求,这可能会导致一个操作会执行一次以上,而重新发出的POST请求需要用户的同意。

在处理JSON请求时,在响应中增加非可执行前缀,例如“\n”,以确保脚本不可执行。在相同域名运行的脚本可以读取响应内容以及删除前缀,但在其他域名运行的脚本则不能。此外,开发者还应该避免使用JSONP(具有填充功能的JSON)来从不同域名加载机密数据,因为这会允许钓鱼网站收集数据。同时,发送响应表头“X-Content-Type-Options: nosniff”也将帮助保护IE和谷歌Chrome用户免受XSSI攻击。

为了应对XSS攻击,可在HTTP Content-Type响应表头或者HTML代码中meta标签中http-equiv属性中指定CHARSET,让浏览器不会解译其他字符集的特殊字符编码。对于使用ASP.NET开发网站的开发者,微软Anti-Cross Site Scripting Library可以帮助保护Web应用抵御跨站脚本漏洞。