/文 空虚浪子心[XGC]
【IT168 专稿】最近笔者在网上看到一个新文章《JSESSIONID Regeneration in Struts 2》&＃xff0c;讲的是一段代码&＃xff0c;在STRUTS 2框架中&＃xff0c;防御Session Fixation***。笔者比较老土&＃xff0c;看不懂英文&＃xff0c;还好能看懂代码&＃xff0c;发现这是一种平时开发中(至少自己是这样)&＃xff0c;从来没注意过的***。关于这种***&＃xff0c;刺在自己博客上写了篇文章《关于Session Fixation》。我在邮件列表&＃xff0c;和文章后面跟帖讨论了下&＃xff0c;但是仍然感觉自己说的不是很清晰&＃xff0c;毕竟没有实战&＃xff0c;所以实践了一下自己的想法&＃xff0c;重新写篇文章补充下。注&＃xff1a;为了保证质量&＃xff0c;本文假设读者对COOKIE和session基本概念和特性已经掌握。
作者是从防御代码中&＃xff0c;发现这种***的存在&＃xff0c;所以&＃xff0c;我们先看防御的代码&＃xff1a;
public void doGet(HttpServletRequest request, HttpServletResponse response)throws ServletException, IOException {if(userid.equals("admin") && password.equals("admin")) {request.getSession().invalidate();HttpSession session &＃61; request.getSession(true);session.setAttribute("AUTHENTICATED", new Boolean(true));response.sendRedirect("PageRequiringAuthentication.jsp");
//Additional Code Would Normally Follow
这是一个很常见的登录过程&＃xff0c;首先验证用户名密码是否正确&＃xff0c;正确后&＃xff0c;干掉当前session。然后重新获取一个新session&＃xff0c;继续执行赋予用户管理权限。关键就是&＃xff0c;这段代码干掉了当前的session。当服务器和客户端之间的session销毁时&＃xff0c;因为客户端仍然向服务器发送数据&＃xff0c;所以服务器会自动的新生成一个session。为什么以前的session不能用呢&＃xff1f;
在作者刚看到邮件的时候&＃xff0c;一直看不明白&＃xff0c;因为站在程序员的角度&＃xff0c;作者不知道为啥非要让session销毁了。如果不消毁session&＃xff0c;程序一样正确执行&＃xff0c;***者不知道管理员密码&＃xff0c;一样进不来。如果这个人知道管理员密码&＃xff0c;那么对于程序本身来说&＃xff0c;这个人就已经是一个程序所期望的管理员了。但是换个角度想一下&＃xff0c;管理员在管理网站的时候&＃xff0c;通常都做些什么&＃xff1f;在管理员登陆前&＃xff0c;他还只是一个普通的浏览者&＃xff0c;会去浏览一些公开页面&＃xff0c;他可能在哪里发现了问题&＃xff0c;需要进后台处理一下&＃xff0c;于是他就登录了。就在这个很普通的过程中&＃xff0c;如果程序没有在认证成功后&＃xff0c;销毁session&＃xff0c;则管理员在登录前和登录后&＃xff0c;session是同一个。假设我们能够在前台&＃xff0c;使用了XSS一类手段&＃xff0c;获得了这个session&＃xff0c;等他一旦登录&＃xff0c;就“野鸡变凤凰”了。
在以往的XSS***、CSRF***中&＃xff0c;我们总是把目光放在管理员登陆后&＃xff0c;XSS他、CSRF他。都没有想过&＃xff0c;如果管理员登陆后&＃xff0c;不浏览XSS页面&＃xff0c;怎么***&＃xff1f;看到这段防御代码&＃xff0c;作者突然想到了一种***手段&＃xff0c;只要管理员曾经浏览过XSS页面&＃xff08;这时候只是普通用户&＃xff09;&＃xff0c;就能在他登录后&＃xff0c;即使不再浏览XSS页面&＃xff0c;也能***到。
为了详细的描述和重现这种***方式&＃xff0c;作者特意下载了动网BBS 8最新版本。首先做两个实验&＃xff0c;来验证动网是否存在这个漏洞&＃xff1a;
1、在登录前&＃xff0c;查看自己的SESSIONID&＃xff0c;管理员前台登录后&＃xff0c;再查看SESSIONID&＃xff0c;登录后台&＃xff0c;再查看。发现这个值没有变动。就是说动网存在这个漏洞&＃xff0c;登录前后&＃xff0c;SESSIONID没有变。
2、为了保证实验成功&＃xff0c;需要知道动网的后台是否仅仅通过SESSION来验证身份。登录后&＃xff0c;抓包。修改包中的信息&＃xff0c;修改username&＃xff0c;提交&＃xff0c;返回数据表明可以同过。再修改SESSIONID&＃xff0c;却出现“本页面为管理员专。。。”字样&＃xff0c;没有通过认证。这说明动网后台是仅仅通过session验证的&＃xff0c;而不是COOKIE。
证明了这个漏洞的存在&＃xff0c;下面就利用这个漏洞&＃xff0c;***登录前的管理员。动网论坛的用户身份模式&＃xff0c;可以很好的诠释这种***&＃xff0c;用过动网的读者都知道&＃xff0c;浏览动网的用户分为以下几种级别&＃xff1a;“未注册用户”、“注册用户”、“前台管理员”、“后台管理员”。我们先架设好***环境&＃xff0c;之后让一个未登陆的管理员&＃xff0c;浏览论坛的XSS页面&＃xff0c;之后登录到后台。
总体来看&＃xff0c;利用这样的漏洞&＃xff0c;需要以下一些东西&＃xff1a;
1、a.php&＃xff0c;一个脚本&＃xff0c;用来接收XSS页面传来的SESSIONID&＃xff0c;然后保存在haha.txt&＃xff0c;可以放在任何一个支持php的空间里。
2、go.py&＃xff0c;没隔5秒&＃xff0c;请求一次haha.txt&＃xff0c;获得SESSIONID值。之后把获得的SESSIONID值放入请求的COOKIE中&＃xff0c;请求后台页面的“添加管理员功能”。
3、一个前台的XSS漏洞&＃xff0c;这个漏洞我们自己可以构造出来。
作者为了仅仅说明这个问题&＃xff0c;而不是大量的制造***&＃xff0c;所以单独为动网写了个对应的脚本&＃xff0c;go.py这个脚本&＃xff0c;请求了动网后台的“添加管理员功能”。他会一直去请求&＃xff0c;不管管理员有没有登录&＃xff0c;在登录前&＃xff0c;会收到“本页面为管理员专。。。”字样。但是管理员一旦登录&＃xff0c;就会请求成功这个功能。
下图可以说明这次模拟实验&＃xff1a;
第一步。首先架设好辅助***的服务器&＃xff0c;服务器中有两个文件&＃xff0c;一个是a.php。这个文件用来接收XSS发来的SESSIONID信息&＃xff0c;然后保存为haha.txt。
第二步。执行go.py。这个文件会每隔5秒&＃xff0c;请求一次haha.txt&＃xff0c;读取其中的数据&＃xff0c;解析为对应的SESSIONID&＃xff0c;把SESSIONID放在发动包的COOKIE中&＃xff0c;之后请求一次“添加管理员”这个功能。
管理员登录后台之后&＃xff0c;SESSIONID就会成为了一个可以通过论坛验证的SESSIONID&＃xff0c;这时候的请求会成为合法请求&＃xff0c;登录之前的请求&＃xff0c;全都是垃圾数据。在整个过程中&＃xff0c;我们要求管理员在登录前浏览一次XSS页面&＃xff0c;然后登陆。登录后&＃xff0c;大概15秒的时候&＃xff0c;就可以退出了。这点时间&＃xff0c;我们的***&＃xff0c;已经成功。
请注意&＃xff0c;这次***的演示中&＃xff0c;重点不是动网出现了XSS漏洞&＃xff0c;而是Session Fixation&＃xff0c;所以我们在前台假设他出现了XSS漏洞。制造这个漏洞很简单&＃xff0c;论坛后台有个给版面加“本版版规”的功能&＃xff0c;支持HTML。把XSS的内容放这里&＃xff1a;
用于提交SESSIONID到a.php。下面是一个COOKIE的内容&＃xff1a;
请注意图片中的“ASPSESSIONIDASQC***T&＃61;PIMHLBHCDAPCDLMNLFBGHCIB”这部分&＃xff0c;这里就是一个SESSIONID和它的值。不仅仅是每次新的SESSIONID的值不一样&＃xff0c;“ASPSESSIONIDASQC***T”这个KEY的名字&＃xff0c;也是不同名称的。但是他逃脱不了一种模式&＃xff0c;就是SESSIONID的名字&＃xff0c;改来改去&＃xff0c;总要让服务器认识。结合几次抓包内容&＃xff0c;发现&＃xff0c;这个字符串没有固定的名称&＃xff0c;也没有固定的值&＃xff0c;但是他总是以“ASPSESSIONID”开头。所以才会有了这段生涩难解的XSS代码。
php代码&＃xff0c;用于接收提交过来的SESSIONID&＃xff0c;保存&＃xff1a;
$fp &＃61; fopen("haha.txt","wb");
fwrite($fp,$_GET["id"].",".$_GET["value"],strlen($_GET["id"].",".$_GET["value"]));
fclose($fp);
?>
下面先执行go.py。
可以看到代码一直在执行“添加管理员这个过程”&＃xff0c;并且一直不能通过验证。
现在先浏览下XSS页面&＃xff0c;查看那个有XSS的版面。先让程序获得SESSIONID&＃xff0c;注意&＃xff0c;还没有登录。
和前次不同的是&＃xff0c;我们获取了sessionid。但是这个SESSIONID还没有通过验证&＃xff0c;管理员还没有登录。之后使用管理员登录后台。
这张图&＃xff0c;出现了提示信息“您输入的用户名已经在管理用户中存在!”&＃xff0c;说明已经可以通过验证了&＃xff0c;***成功。
可能有很多读者在本次***过程中想到了SESSION IE这个工具&＃xff0c;该工具也可以获得管理员的SESSIONID&＃xff0c;并且通过不断的访问&＃xff0c;维持这个SESSIONID不被销毁。与之区别的是&＃xff0c;如果管理员登录后&＃xff0c;自己点了“退出”。那么这个维持中SESSIONID就没用了&＃xff0c;除非你能在他没点退出之间&＃xff0c;做了添加管理员操作&＃xff0c;期待该工具更新本文所提功能。而这次的***过程中&＃xff0c;即使管理员退出了&＃xff0c;我们***也早就在管理员登陆的那一刹那间&＃xff0c;***成功。Session Fixation最大的威胁&＃xff0c;就是在登录前的XSS能一直威胁到了管理员登录&＃xff0c;即使管理员登录后不再访问XSS页面&＃xff0c;也不影响***效果。
工具go.py在这里提供下载&＃xff0c;但是注意一点&＃xff0c;这个工具&＃xff0c;不是一个多线程的。实验的时候可以用&＃xff0c;如果用于做坏事&＃xff0c;除非修改它的代码&＃xff0c;否则每一个看到XSS页面的人&＃xff0c;都会提交SESSIONID上去&＃xff0c;导致***失败。为了网络和谐&＃xff0c;作者就不提供真正用于***的代码了&＃xff0c;大家回去后自己研究。
京公网安备 11010802041100号