Webgoat之Session Management Flaws

Hijack a Session

如图是一个登陆页面，现在要求在不知道用户名和密码的情况下登陆进去。现在我们已经知道的是如果传过去的cookie是对的话，服务器端会跳过验证用户名和密码的环节。也就是说用户名和密码可以随便填写，关键是猜对cookie，并且这个cookie需要是正在使用的会话cookie。我们先随便抓一个看看所提交的是哪些数据：

可以看到在请求头中cookie有两个，一个是WEAKID，一个是JSESSION，我们主要是猜对请求头的WEAKID，这是我们的会话ID。首先我们连续刷新该页面，观察服务器传过来的cookie的变化。也就是说在刷新该页面的时候，需要删掉WEAKID后再发送请求，这样每次服务器都会传过来一个WEAKID，我们可以观察其规律。先试第一个，我们提交一个请求后，服务器传过来的响应是这样的：

继续提交一个请求，服务器传过来的响应是这样的：

可以发现WEAKID由两部分组成，减号前面是依次递增的，减号后面也是递增的，这是我们观察之后的结论。下面继续验证，采用burpsuit提供的自动化发包工具，提交一个数据，抓到之后删掉WEAKID，然后点击Action发送到Sequencer。然后进行相应的设置：

上面是选择tooken出现的地方。

上面是选择运行的线程个数。然后点击Start live capture，开始抓包：

上面表示已经发送的请求和已经抓到的tooken。此时点击copy token，再回到Manual load，点击Paste：

上图可以看到这是我们抓到的所有token，都是连续的，但是只有16964和16966之间却缺少了16965，因此我们猜测这个token是一个已经登录进去的会话，我们可以利用这个会话进行登录。现在我们需要猜测减号后面的那部分数据，它是在1462418466736到1462418466754之间的，下面使用暴力破解，我们将请求继续发送到Intruder，如下图所示：

给cookie的最后两位数增加变量，然后给该变量设置范围，burpsuit会根据你设定的范围一个个的去试，如下图所示：

上面对相关变量的一些设置。然后点击Stack Attack。

可以看到有一条记录服务器响应的长度与其他记录不一样，而上图下方显示的是该条记录具体发送的内容和服务器的响应。最后可以看到以该内容作为请求发送时，成功登陆了：

如下登陆页面：

我们有两个用户名和密码，分别为：webgoat/webgoat、aspect/aspect，现在我们还知道alice的用户名却不知道其密码，要求我们以alice的身份登陆。
我们尝试以webgoat的身份进行登陆，发现登陆时的请求为：

服务器端的响应为：

可见登陆的时候是没有AuthCookie的，登陆之后服务器传给浏览器一个AuthCookie，我们观察其值。
下面以aspect身份进行登陆，看到：

观察如下：

webgoat ——> 65432ubphcfs
aspect ——> 65432udfqtb

可以找到规律了，就是把字母反过来，再向后移动一位。
那么猜测alice的AuthCookie为：65432fdjmb，在用户名和密码那里什么都不填，直接提交，burpsuit拦截后修改cookie如下：

然后成功登陆:

Session Fixation

通过会话固定盗取Session。服务器通过每个用户唯一的Session ID来确认其合法性。如果用户已登录，并且授权服务器不必重新验证授权后，当该用户需要重新登录进入系统时，他的Session ID 依然被服务器认为是合法的。
在一些程序中，可能会在GET-REQUEST请求中传递Session ID。这就是攻击的起点。一个攻击者可以用一个选定的Session ID给受害人发送一个超链接。例如，这里有一个准备好的邮件，它看起来像是一个从应用程序管理员发来的官方邮件。如果受害者点击了这个链接，并且该受害者以攻击者指定的Session ID登录了系统，那么攻击者可以不经授权直接使用与受害者相同的Session ID来访问该页面。
在实际课程中需要我们同时扮演攻击者和受害者，攻击者是Hacker，受害者是Jane。
首先由Hacker向Jane发一封看起来很正常的邮件，该邮件是关于银行对账单的。需要诱导受害者点击该邮件的链接。该邮件为：

邮件中间是一个超链接，对应的代码为：

然后受害者点击了该超链接，进入他的银行系统的登陆页面：

该页面的链接地址为：