转自:http://hi.baidu.com/hkr_tam/item/15843028b839d5ae9d63d138
XSS攻击原理:
XSS 属 于被动式的攻击。攻击者先构造一个跨站页面,利用script、、
XSS 攻 击主要分为两类:一类是来自内部的攻击,主要指的是利用WEB 程序自身的漏洞,提交特殊的字符串,从而使得跨站页面直接存在于被攻击站点上,这个字符串 被称为跨站语句。这一类攻击所利用的漏洞非常类似于SQL Injection 漏洞,都是WEB程序没有对用户输入作充分的检查和过滤。上文的 Yamanner 就是一例。
另一类则是来来自外部的攻击,主要指的自己构造XSS 跨站漏洞网页或者寻找非目标机以外的有跨站 漏洞的网页。如当我们要渗透一个站点,我们自己构造一个跨站网页放在自己的服务器上,然后通过结合其它技术,如社会工程学等,欺骗目标服务器的管理员打 开。这一类攻击的威胁相对较低,至少ajax 要发起跨站调用是非常困难的。
案例实战:
我们来看一个简单 的攻击实例,下表给出了一个简单的网站http://xss.honkwin.com:8080/testxss,该网站的密码和用户名相同,普通用户可 以修改user value,当以admin 身份登陆时可以通过向doadmin.jsp 发起请求来修改admin value。
index.jsp
login.jsp <% String u = request.getParameter("u"); String p = request.getParameter("p"); if (u != null && p != null && u.equals(p)) { session.setAttribute("username", u); } else { session.removeAttribute("username"); } response.sendRedirect("index.jsp"); %> doadmin.jsp <% String u = (String)session.getAttribute("username"); String v = request.getParameter("v"); String v2 = request.getParameter("v2"); if (u != null && u.equals("admin")) { if (v != null) application.setAttribute("adminvalue", v); } if (u != null && v2 != null) application.setAttribute("uservalue", v2); response.sendRedirect("index.jsp"); %> 容易想到,只要诱骗admin 用户发起一个到http://xss.honkwin.com:8080/testxss/doadmin.jsp 的http 请求,就能成功攻击。因此我们设计跨站语句如下
logout
Login:
hello hellohello
以普通用户身份修改user value 为以上任何一个,当admin 浏览index.jsp 时,即可悄无声息的修改admin value
这里演示了3 种跨站手法:
1 是利用img、iframe 等tag 直接发起请求,这适用于无法直接出script 的情况,其中http://bbs.honkwin.com/2xwfed 是一个redirect,指向
http://xss.honkwin.com:8080/testxss/doadmin.jsp?v=hacked2 ;
2 是用script 提交post 表单;
3 是ajax 技术。
以上攻击能够成功有2 个原因:
1. 应用程序没有对user value 做足够多的过滤,导致用户有机会构造一个复杂的跨站语句来触发admin 的非预期行为;
2. 应用程序在响应admin value 修改请求时没有防范措施来识别这是不是出于用户主动。
漏洞1 很容易修复,只要像防止SQL Injection 那样对用户输入的所有内容都过滤即可。
漏洞2 才是问题的根源,即便我们修补了漏洞1,只要诱使admin 用户访问包含 的页面,仍然能达到目的,而这是一件极容易
做到的事。
防范措施:
这里给出一些防范XSS 攻击的措施。必须说明的是,对于XSS 攻击,并不像SQLInjection 那样可以有一劳永逸的解决方案——只需要grep 一下所有的sql 调用。这是一
场长期的斗争,而且往往需要我们采取修改业务流程、产品设计等看似削足适履的手段。
防范手法如下:
1. 防 堵跨站漏洞,阻止攻击者利用在被攻击网站上发布跨站攻击语句不可以信任用户提交的任何内容,首先代码里对用户输入的地方和变量都需要仔细检查长度和 对”<”,”>”,”;”,”’”等字符做过滤;其次任何内容写到页面之前都必须加以encode,避免不小心把html tag 弄出来。 这一个层面做好,至少可以堵住超过一半的XSS 攻击。
2. Cookie 防盗
首先避免直接在cookie 中泄露用户隐私,例如email、密码等等。其次通过使cookie 和系统ip 绑定来降低cookie 泄露后的危险。这样攻击者得到的cookie 没有实际价值,不可能拿来重放。
3. 尽量采用POST 而非GET 提交表单
POST 操作不可能绕开javascript 的使用,这会给攻击者增加难度,减少可利用的
跨站漏洞。
4. 严格检查refer
检查http refer 是否来自预料中的url。这可以阻止第2 类攻击手法发起的http 请求,也能防止大部分第1 类攻击手法,除非正好在特权操作的引用页上种了跨站访问。
5. 将单步流程改为多步,在多步流程中引入效验码
多步流程中每一步都产生一个验证码作为hidden 表单元素嵌在中间页面,下一步操作时这个验证码被提交到服务器,服务器检查这个验证码是否匹配。
首先这为第1 类攻击者大大增加了麻烦。其次攻击者必须在多步流程中拿到上一步产生的效验码才有可能发起下一步请求,这在第2 类攻击中是几乎无法做到的。
6. 引入用户交互
简单的一个看图识数可以堵住几乎所有的非预期特权操作。
7. 只在允许anonymous 访问的地方使用动态的javascript。
8. 对于用户提交信息的中的img 等link,检查是否有重定向回本站、不是真的图片等
可疑操作。
9. 内部管理网站的问题
很 多时候,内部管理网站往往疏于关注安全问题,只是简单的限制访问来源。这种网站往往对XSS 攻击毫无抵抗力,需要多加注意。安全问题需要长期的关注,从 来不是一锤子买卖。XSS 攻击相对其他攻击手段更加隐蔽和多变,和业务流程、代码实现都有关系,不存在什么一劳永逸的解决方案。此外,面对XSS,往往 要牺牲产品的便利性才能保证完全的安全,如何在安全和便利之间平衡也是一件需要考虑的事情。
web应用开发者注意事项:
1.对于开发者,首先应该把精力放到对所有用户提交内容进行可靠的输入验证上。这些提交内容包括URL、查询关键
字、http头、post数据等。只接受在你所规定长度范围内、采用适当格式、你所希望的字符。阻塞、过滤或者忽略其它的
任何东西。
2.保护所有敏感的功能,以防被bots自动化或者被第三方网站所执行。实现session标记(session tokens)、
CAPTCHA系统或者HTTP引用头检查。
3.如果你的web应用必须支持用户提供的HTML,那么应用的安全性将受到灾难性的下滑。但是你还是可以做一些事来
保护web站点:确认你接收的HTML内容被妥善地格式化,仅包含最小化的、安全的tag(绝对没有JavaScript),去掉任何
对远程内容的引用(尤其是样式表和JavaScript)。为了更多的安全,请使用httpOnly的cookie。