`
csd_ali
  • 浏览: 134283 次
  • 性别: Icon_minigender_1
  • 来自: 杭州
社区版块
存档分类
最新评论

固定SessionID漏洞

阅读更多

 

by BoBo

 

一个简单的登录控制

下面是一个最常用最简单的登录控制流程,通过表单提交用户名密码,servlet判断用户名密码,正确则写一个session,然后跳转到登录后的能够看到的页面
登录页面JSP

/*省略头部信息*/
<body>
<form action="SessionTestServlet" method="post">
	用户名:<input name="username" type="text" value=""/>
	密码:<input name="password" type="password" value=""/>
	<input name="submit" type="submit" value="Submit"/>
</form>
</body>

SessionTestServlet

protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
	    HttpSession session = request.getSession();
	    String username=request.getParameter("username");
	    String password=request.getParameter("password");
	    if("admin".equals(username) && "pass".equals(password)){
	        session.setAttribute("login", true);
	        response.sendRedirect("hello.jsp");
	    }else{
	        response.sendRedirect("login.jsp");
	    }
	}

登录后的页面hello.jsp

<body>
<%
	boolean isLogin = (Boolean)request.getSession().getAttribute("login");
	if(isLogin!=null){
	    out.print("Welcome");
	}else{
	    out.print("Sorry!");
	}
%>
</body>

匿名SessionID

运行着个简单的demo后,打开login.jsp,使用firebug或chrome会发现,即使没有登录,我们也会有一个JSESSIONID,这是由服务器端在会话开始是通过set-cookie来设置的匿名SessionId

输入用户名密码后,在查看JSESSIONID

可以发现,登录前和登录后的JSESSIONID并没有改变,那么这就是一个固定SessionID的漏洞(详见《黑客攻防技术宝典-web实战》第七章)

简单的漏洞攻击

第一步,需要获取被攻击用户的JSESSIONID,可以通过给被攻击用户一个伪造的JSESSIONID,使其用该JESSIONID登录,获取用户登录后的JESSIONID。(这里作为示范,直接从浏览器中获取)
第二步,等被攻击用户登录,是JESSIONID成为已登录状态。
第三步,伪造请求,访问登录后的资源。
在用户登录使该JSESSIONID称为已登录的ID后,攻击者就可以利用这个ID伪造请求访问登录后的资源。下面是一个简单的python脚本

#!/bin/python
import urllib, urllib2

request = urllib2.Request('http://localhost:9090/sec/hello.jsp')
opener = urllib2.build_opener()
//设置窃取的JSESSIONID
request.add_header('Cookie','JSESSIONID=CF2D43B2C433F1A9FD78CE9D01E2E52D')
hellodata=opener.open(request).read()
print hellodata

执行该脚本,结果如下:

能够看到需要登录的页面

漏洞分析处理

出现该问题的主要原因是登录控制使用的固定的SessionID,登录前与登录后的SessionID是一样的。这样就使得攻击者可以简单的伪造一个SessionID诱使用户使用该SessionID登录,即可获取登录权限。如果配合XSS漏洞,则更加可以轻易获取登录权限。避免这一漏洞的方法主要有两种:
1.在登录后重置sessionID
在登录验证成功后,通过重置session,是之前的匿名sessionId失效,这样可以避免使用伪造的sessionId进行攻击。代码如下

protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
	    String username=request.getParameter("username");
	    String password=request.getParameter("password");
	    if("admin".equals(username) && "pass".equals(password)){
                //是之前的匿名session失效
	        request.getSession().invalidate();
	        request.getSession().setAttribute("login", true);
	        response.sendRedirect("hello.jsp");
	    }else{
	        response.sendRedirect("login.jsp");
	    }
	}

这样登录前与登录后的sessionID就不会相同

2.设置httpOnly属性
httponly是微软对cookie做的扩展,该值指定 Cookie 是否可通过客户端脚本访问, 解决用户的cookie可能被盗用的问题,减少跨站脚本攻击
主流的大多数浏览器已经支持此属性。httpOnly是cookie的扩展属性,并不包含在servlet2.x的规范里,因此一些javaee应用服务器并不支持httpOnly,针对tomcat,>6.0.19或者>5.5.28的版本才支持httpOnly属性,具体方法是在conf/context.xml添加httpOnly属性设置

<Context useHttpOnly="true">
...
</Context>

另一种设置httpOnly的方式是使用Tomcat的servlet扩展直接写header

response.setHeader( "Set-Cookie", "name=value; HttpOnly");
  • 大小: 36.1 KB
  • 大小: 28.9 KB
  • 大小: 30.4 KB
  • 大小: 37.5 KB
分享到:
评论
21 楼 JE帐号 2010-12-15  
chris_zley 写道
JE帐号 写道
chris_zley 写道
其实这个漏洞很简单,但整个攻击过程最难点在于如何获取用户的jsessionid


这个方案不是为了解决哪些能获取用户jsessionid的情况. 而是为了解决去诱导用户使用一个与jsessionid绑定的url(sessionid的url改写),并诱使用户在此基础上进行登录操作的情况.
这和获取去获取用户jsessionid还是有本质区别的,因为这种引诱的情况,实际上是不需要攻击用户的终端和网络的.

另外,对于有人说的tomcat7每次连接都会修改jsessionid的情况,有人知道更详细的细节么? 我很疑惑的是,如果每次都修改,岂不是意味着一些并发连接可能失效了?
比如,我先是一个xhr异步请求,服务端刚生成一个新jsessionid,但是还没有返回客户端时,我又是一个xhr请求过去.此时我带的是旧的jsessionid,岂不是就会出问题?




。。。你想说什么,能把话理顺了吗


汗, .
"整个攻击过程最难点在于如何获取用户的jsessionid" 意味着攻击的前提是你有办法可以监听对方的浏览器或者网络.很显然,这时候你面对的敌人不只是对方,还有对方的系统安全防护或者网络安全防护.成本会大很多.

但是另外一个方案是,你发给对方一个url(注意,这个url是经过你精心构造的,你将一个由你访问网站产生的jsessionid以 url重写的方式附加到你发给对方的url上.比如:www.x.com/login;jsessionid=xxxxxxxxxx?x=money).再找一些理由让对方在你给的url里进行登录.这样,对方访问过去的时候就已经附带上jsessionid了,此时如果服务端在login成功后,不去重新生成jsessionid,那么原先的那个jsessionid就会被认证.此时,你以及对方就都可以使用同一个jsessionid做登录后的操作了.
很显然,这种攻击方式,你除了需要找个有诱惑的理由去引诱对方去使用你给的url登录,其他的完全没有什么技术含量,而且对方的所有系统安全手段也完全无效. 攻击成本会低很多.这也是所谓的"社会工程学攻击"的一种.

总结一下,实施这中攻击的条件:
1.匿名访问服务器时,服务器也会分配jsessionid.
2.服务器端支持识别jsessionid的url重写.
3.服务器端在认证后没有重新生成jsessionid.
20 楼 nehu 2010-12-15  
java里面还算有解决方案,.net就悲剧了,目前还没发现好办法 (除了绑定IP)
19 楼 cr0w 2010-12-15  
https也不是绝对安全的
18 楼 xgj1988 2010-12-15  
javaeyebird 写道
服务器可以不接受url里的sessionid 只接收cookie里的sessionid
当然攻击者可以伪造 javascript:...之类的url来设置cookie 不过这样很容易被识别出来 不是一个常规的url

  我也觉得是这样。。
17 楼 archerfrank 2010-12-15  
chunquedong 写道
在session中保存客户端ip地址,每次都检查一下ip地址是否对应,要是不太合适就删除session。我想应该会安全点。

如果在局域网里,大家都用一个代理出去,一样有问题。
16 楼 javaeyebird 2010-12-15  
服务器可以不接受url里的sessionid 只接收cookie里的sessionid
当然攻击者可以伪造 javascript:...之类的url来设置cookie 不过这样很容易被识别出来 不是一个常规的url
15 楼 chris_zley 2010-12-15  
JE帐号 写道
chris_zley 写道
其实这个漏洞很简单,但整个攻击过程最难点在于如何获取用户的jsessionid


这个方案不是为了解决哪些能获取用户jsessionid的情况. 而是为了解决去诱导用户使用一个与jsessionid绑定的url(sessionid的url改写),并诱使用户在此基础上进行登录操作的情况.
这和获取去获取用户jsessionid还是有本质区别的,因为这种引诱的情况,实际上是不需要攻击用户的终端和网络的.

另外,对于有人说的tomcat7每次连接都会修改jsessionid的情况,有人知道更详细的细节么? 我很疑惑的是,如果每次都修改,岂不是意味着一些并发连接可能失效了?
比如,我先是一个xhr异步请求,服务端刚生成一个新jsessionid,但是还没有返回客户端时,我又是一个xhr请求过去.此时我带的是旧的jsessionid,岂不是就会出问题?




。。。你想说什么,能把话理顺了吗
14 楼 chunquedong 2010-12-15  
在session中保存客户端ip地址,每次都检查一下ip地址是否对应,要是不太合适就删除session。我想应该会安全点。
13 楼 JE帐号 2010-12-15  
chris_zley 写道
其实这个漏洞很简单,但整个攻击过程最难点在于如何获取用户的jsessionid


这个方案不是为了解决哪些能获取用户jsessionid的情况. 而是为了解决去诱导用户使用一个与jsessionid绑定的url(sessionid的url改写),并诱使用户在此基础上进行登录操作的情况.
这和获取去获取用户jsessionid还是有本质区别的,因为这种引诱的情况,实际上是不需要攻击用户的终端和网络的.

另外,对于有人说的tomcat7每次连接都会修改jsessionid的情况,有人知道更详细的细节么? 我很疑惑的是,如果每次都修改,岂不是意味着一些并发连接可能失效了?
比如,我先是一个xhr异步请求,服务端刚生成一个新jsessionid,但是还没有返回客户端时,我又是一个xhr请求过去.此时我带的是旧的jsessionid,岂不是就会出问题?
12 楼 chris_zley 2010-12-15  
其实这个漏洞很简单,但整个攻击过程最难点在于如何获取用户的jsessionid
11 楼 褚晓娜(0511) 2010-12-15  
感觉不错,虽然不是最终中的解决办法,但是还是比较安全一点的,
10 楼 tianice 2010-12-14  
官方早就有补丁了,tomcat7解决了这个问题
9 楼 JE帐号 2010-12-14  
无论如何,这样处理一下,确实会安全一些.
比如,我给一个人发过去一个url,然后使用url上带上sessionid这种情况,这个时候,那个人在这个url的地址上进行登录,如果sessionid是固定的,那么我就可以使用这个共享这个sessionid的.
在这种模式下,我完全没有尝试去对那个人的系统有任何的监听,hack行为,却能达到很好的效果.

8 楼 linkobe 2010-12-14  
所以现在大部分好的网站都有在客户端对用户密码进行加密,或者走https协议,这个问题很老了,不走https,是没有绝对的安全的,用sniffer,任何明文都可以轻易获取,管你什么session不session,除非将session跟ip加密绑定
7 楼 kkqqcom 2010-12-14  
archerfrank 写道
既然之前的sessionid会被盗,那么如果用户在登录以后sessionid再被盗了呢。



能拿到别人的sessionid,如果不是在局域网的话,差不多能拿到用户名密码了。
6 楼 michael.softtech 2010-12-14  
tomcat7已经自动处理了这种情况,可以设置为每次请求更新sessionId
5 楼 archerfrank 2010-12-14  
既然之前的sessionid会被盗,那么如果用户在登录以后sessionid再被盗了呢。
4 楼 bill2004158 2010-12-14  
不就是Session fixation嘛?
3 楼 icanfly 2010-12-14  
老生常谈的问题。
2 楼 lxtx517 2010-12-14  
这个session跟数据库的sql语言预处理,感觉有相似

相关推荐

Global site tag (gtag.js) - Google Analytics