XSS跨站脚本攻击在Java开发中防范的方法 - conkeyn - ITeye技术网站
博客分类：
XSS攻击原理：
XSS 属 于被动式的攻击。攻击者先构造一个跨站页面，利用script、&IMG&、&IFRAME&等各种方式使得用户浏览这个页面 时，触发对被攻击站点的http 请求。此时，如果被攻击者如果已经在被攻击站点登录，就会持有该站点cookie。这样该站点会认为被攻击者发起了一个 http 请求。而实际上这个请求是在被攻击者不知情的情况下发起的，由此攻击者在一定程度上达到了冒充被攻击者的目的。精心的构造这个攻击请求，可以达 到冒充发文，夺取权限等等多个攻击目的。在常见的攻击实例中，这个请求是通过script 来发起的，因此被称为Cross Site Script。攻 击Yahoo Mail 的Yamanner 蠕虫是一个著名的XSS 攻击实例。Yahoo Mail 系统有一个漏洞，当用户在web 上察看信件 时，有可能执行到信件内的javascript 代码。病毒可以利用这个漏洞使被攻击用户运行病毒的script。同时Yahoo Mail 系统使用了 Ajax技术，这样病毒的script 可以很容易的向Yahoo Mail 系统发起ajax 请求，从而得到用户的地址簿，并发送病毒给他人。
XSS 攻 击主要分为两类：一类是来自内部的攻击，主要指的是利用WEB 程序自身的漏洞，提交特殊的字符串，从而使得跨站页面直接存在于被攻击站点上，这个字符串 被称为跨站语句。这一类攻击所利用的漏洞非常类似于SQL Injection 漏洞，都是WEB程序没有对用户输入作充分的检查和过滤。上文的 Yamanner 就是一例。
另一类则是来来自外部的攻击，主要指的自己构造XSS 跨站漏洞网页或者寻找非目标机以外的有跨站 漏洞的网页。如当我们要渗透一个站点，我们自己构造一个跨站网页放在自己的服务器上，然后通过结合其它技术，如社会工程学等，欺骗目标服务器的管理员打 开。这一类攻击的威胁相对较低，至少ajax 要发起跨站调用是非常困难的。
我们来看一个简单 的攻击实例，下表给出了一个简单的网站:8080/testxss，该网站的密码和用户名相同，普通用户可 以修改user value，当以admin 身份登陆时可以通过向doadmin.jsp 发起请求来修改admin value。
&textarea rows="3" cols="100" readonly="on"&
Current User: ${username}
Admin Value: ${adminvalue}
User Value: ${uservalue}
&/textarea&
&a href="login.jsp"/&logout&/a&&br&
Login:&br&
&form action="login.jsp" method="post"&
username: &input type="text" name="u"&&/input& &br&
password: &input type="text" name="p"&&/input& &br&
&input type="submit" /& password == username :-)
&form action="doadmin.jsp" method="post"&
adminvalue: &input type="text" name="v"&&/input& &br&
&input type="submit" /&
&form action="doadmin.jsp" method="post"&
uservalue: &input type="text" name="v2"&&/input& &br&
&input type="submit" /&
String u = request.getParameter("u");
String p = request.getParameter("p");
if (u != null && p != null && u.equals(p)) {
session.setAttribute("username", u);
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 用户发起一个到:8080/testxss/doadmin.jsp 的http 请求，就能成功攻击。因此我们设计跨站语句如下
hello &/textarea& &img src="/2xwfed" style="display:none"& &/img&
hello &/textarea& &form id="shit" action=":8080/testxss/doadmin.jsp" metho
nd="post" target="myframe"/& &input type="hidden" name="v" value="hacked3"/& &/form& &iframe
style="display:none" name="myframe"& &/iframe&&script&document.forms[0].submit()&/script&
hello &/textarea& &script language="jscript"&v = new ActiveXObject("MSXML2.XMLHTTP.3.0"); v.
open("GET",":8080/testxss/doadmin.jsp?v=hacked4"); v.send();alert(v.status
Text);&/script&
以普通用户身份修改user value 为以上任何一个，当admin 浏览index.jsp 时，即可悄无声息的修改admin value
这里演示了3 种跨站手法:
1 是利用img、iframe 等tag 直接发起请求，这适用于无法直接出script 的情况，其中/2xwfed 是一个redirect，指向
: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 用户访问包含&imgsrc="/2xwfed"& &/img&的页面，仍然能达到目的，而这是一件极容易
做到的事。
防范措施：
这里给出一些防范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。
浏览: 899513 次
来自: 厦门
不使用增强器
学习了，楼主，能否提供一份源代码啊，学习一下，十分感谢！！！4 ...
学习了，楼主，能否提供一份源代码啊，学习一下，十分感谢！！！1 ...
楼主，能否源码提供一份，学习一下，十分感激！ ...1192人阅读
安全测试（26）
一、跨站脚本攻击的概念
跨站脚本攻击(Cross Site Script为了区别于CSS简称为XSS)指的是恶意攻击者往Web页面里插入恶意html代码，当用户浏览该页之时，嵌入其中Web里面的html代码会被执行，从而达到恶意用户的特殊目的。
举个比较常见的网络上的一个例子，某个论坛或者页面上有个广告，网址是，你点击进去，你看是购物网站，又是淘宝的，你就进去购买了，其实呢，他会redirect到另一个攻击者自己的网站，你在购买的时候，使用的是攻击者的接口进行付款，很可能就会被盗取个人信息及财产等。
二、寻找跨站漏洞
如果有代码的话比较好办，我们主要看代码里对用户输入的地方和变量有没有做长度和对”&”,”&”,”;”,”’”等字符是否做过滤。还有要注意的是对于标签的闭合，像测试QQ群跨站漏洞的时候，你在标题处输入，这样就可以弹出一个test的框。
三、XSS漏洞的后果
XSS漏洞可能造成的后果包括窃取用户会话，窃取敏感信息，重写Web页面，重定向用户到钓鱼网站等，尤为严重的是，XSS漏洞可能使得攻击者能够安装XSS代理，从而攻击者能够观察到该网站上所有用户的行为，并能操控用户访问其他的恶意网站。
四、XSS漏洞的常见解决措施
对于XSS漏洞，我们有两种常见的措施，第一种就是消除漏洞，简而言之就是在输出页面上不提供任何用户的输入信息；另外一种就是想办法来抵御这种漏洞，可以采用对所有用户的输入编码后再输出（可以用OWASP的ESAPI），也可以对所有用户输入进行“白名单”验证，另外，OWASP还提供了AntiSamy对HTML页面做优化以消除这个漏洞。
五、XSS的分类及测试方法
XSS分为三类：Stored XSS、Reflected XSS、Dom-Base XSS。
（1）Stored XSS，即存储式跨站攻击，存储式跨站攻击简单来说就是攻击者提交给网站的数据会提交并永久保存到服务器的数据库或者是文件系统等其他地方，之后不做任何编码操作就会显示在web页面上。这是最厉害的攻击方式。
例如1:在一个网站的一些留言板或者新闻等可以输入的地方，输入一下代码：
&alert(document.cookie)&
因为这个是留言板上或者评论等的内容，会被读取并且存储到服务器上，如果不作任何处理，当其他用户访问这个网页的时候，就会弹出一个关于cookie的警告信息。
例如2：在评论的时候输入&script type="text/javascript"&alert("you are a foolish person")&/script&，如果不进行处理，这个信息会被当做正常的留言存储到服务器，那个接下来每个访问这个页面的用户都会收到you are a foolish person的alert信息，会造成很大的影响。（可用于窃取密码，用户信息等）
（2）Reflected XSS，即反射跨站脚本攻击，这是最常见的攻击方式。所谓反射，就是等着服务器所给的返回。我们在进行测试时依据的就是在自己页面上的简单注入。在web客户端提交了数据后，服务端马上给这个请求生成返回结果页，如果结果中包含了未验证的客户端输入数据，那就表示会允许客户端脚本直接注入到页面里，也就出现了这样一个漏洞。简单举个例子，在搜索引擎里边，我们如果搜索了一个包含html代码的字符串，如果返回的字符串仍然没被编码，那么搜索的内容就不是整个html代码了，而是只想过这个html代码，那就是存在XSS漏洞了。
（3）Dom-Base XSS，即基于DOM的XSS攻击，它是修改页面DOM节点数据信息而形成的XSS跨站脚本攻击，该漏洞多见于客户端脚本，意思就是如果一个js访问需要参数的url，并且需要把信息作用于自己当前的页面，信息又未被编码，就会出现该漏洞。
例如：好多网站在网址后边带个参数（？XXX的），当看到这种情况时候，我们可以在参数后边加个，如果加了这个参数之后，这段script代码不被编码就输出，那就证明它具有这么一个漏洞。
例如：某网站的url中含有？，我们输入?，如果这个脚本执行了，那么我们就说这是一个XSS漏洞。
（注：含有？只是其中的一个例子，并不是所有Dom-Base XSS都是这种形式）
六、完善的输入检查是预防XSS的重要措施
由于三种XSS跨站脚本攻击类型的漏洞成因可不相同，针对输入输出的检查一部分适用于反射型XSS与存储型XSS，而另外一些检查适用于基于DOM的XSS。
A. 防范反射型XSS和存储型XSS
输入检查在大多数的时候都是对可信字符的检查或输入数据格式的检查，如用户输入的注册账号信息中只允许包括字母、数字、下划线和汉字等，对于输入的一切非白名单内的字符均认为是非法输入。数据格式如输入的IP地址、电话号码、邮件地址、日期等数据都具有一定的格式规范，只有符合数据规范的输入信息才允许通过检查。
输出检查主要是针对数据展示过程中，应该对数据信息进行HTML编码处理，将可能存在导致XSS跨站脚本攻击的恶意字符进行编码，在不影响正常数据显示的前提条件下，过滤恶意字符。常见的可能造成XSS跨站脚本攻击的字符及其HTML编码如下：
除了常用的编码外，任何字符都可以使用其ASCII码进行HTML编码，如
B. 防范基于DOM的XSS
从基于DOM的XSS的定义及其触发方式我们发现，当基于DOM的XSS跨站脚本攻击发生时，恶意数据的格式与传统的XSS跨站脚本攻击数据格式有一定的差异，甚至可以在不经过服务器端的处理和相应的情况下，直接对客户端实施攻击行为，因此上述我们应用于防范反射型XSS和存储型XSS的方法并不适用于防范基于DOM的XSS跨站脚本攻击。
针对基于DOM的XSS防范的输入检查方法，我们发现在客户端部署相应的安全检测代码的过滤效果要比在服务器端检测的效果更加明显。例如，我们可以通过如下客户端检测代码来保证用户输入的数据只包含字母、数字和空格，代码如下：
var str = document.URL;
str = str.substring(str.indexOf("username=")+9, str.length);
str = unescape(str);
var regex=/^([A-Za-z0-9+\s])*$/;
if (regex.test(str))
document.write(str);
同样，我们也可以通过在服务端实现类似上述数据检查的功能，如在服务器端检测URL参数是否为预定的参数username,并对username参数的内容进行检测，确认数据内容是否为只包含数字、字母和空格符，实现服务端的数据过滤。但是，由于客户端数据的可控性，这种服务端检测的效果要明显弱于客户端检测。
基于DOM的XSS输出检查与反射型XSS漏洞输出检查的方法相似，在将用户可控的DOM数据内容插入到文档之前，Web应用程序应对提交的数据进行HTML编码处理，将用户提交的数据中可能存在的各种危险字符和表达式进行过滤以安全的方式插入到文档中进行展现，如可以通过如下函数实现在客户端javascript中执行HTML编码处理。
function jsEncode(str)
var d = document.createElement('div');
d.appendChild(document.createTextNode(str));
return d.innerHTML;
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：91941次
积分：1736
积分：1736
排名：第19328名
原创：79篇
转载：26篇
评论：20条
(9)(44)(52)