Hijack a Session
If the user specific session ID is not complex and random, then the application is highly susceptible to session-based brute force attacks.
实验过程
如图是一个登陆页面，现在要求在不知道用户名和密码的情况下登陆进去。现在我们已经知道的是如果传过去的cookie是对的话，服务器端会跳过验证用户名和密码的环节。也就是说用户名和密码可以随便填写，关键是猜对cookie，并且这个cookie需要是正在使用的会话cookie。我们先随便抓一个看看所提交的是哪些数据。
可以看到在请求头中cookie有两个，一个是WEAKID，一个是JSESSION，我们主要是猜对请求头的WEAKID，这是我们的会话ID。首先我们连续刷新该页面，观察服务器传过来的cookie的变化。也就是说在刷新该页面的时候，需要删掉WEAKID后再发送请求，这样每次服务器都会传过来一个WEAKID，我们可以观察其规律。先试第一个，我们提交一个请求后，服务器传过来的响应是这样的。
可以发现WEAKID由两部分组成，减号前面是依次递增的，减号后面也是递增的，这是我们观察之后的结论。下面继续验证，采用burpsuit提供的自动化发包工具，提交一个数据，抓到之后删掉WEAKID，然后点击Action发送到Sequencer。
Spoof an Anthentication cookie
session 穷举越权
我们有两个用户名和密码，分别为：webgoat/webgoat、aspect/aspect，现在我们还知道alice的用户名却不知道其密码，要求我们以alice的身份登陆。
我们尝试以webgoat的身份进行登陆，发现登陆时的请求为
可见登陆的时候是没有AuthCookie的，登陆之后服务器传给浏览器一个AuthCookie，我们观察其值。
|
|
可以找到规律了，就是把字母反过来，再向后移动一位。
那么猜测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发一封看起来很正常的邮件，该邮件是关于银行对账单的。需要诱导受害者点击该邮件的链接。该邮件为
构造的恶意链接
受害者本人要登陆系统，肯定知道自己的账号和密码。于是输入账号：Jane，密码：tarzan，进入系统。受害者进入系统之后，他的sessionID已经通过验证，就是有效的了。这时，黑客也进入该银行系统的登陆页面，此时的地址为：
|
|
