测试身份验证和会话管理

测试身份验证和会话管理

1.Burp Suite的Sequencer 从服务器请求数千个会话标识符（例如，通过重复登录请求），并分析响应以确定生成标识符的算法的随机性和密码强度。算法越强，攻击者就越难复制有效ID。

在本文中，我们将使用 Burp Sequencer分析两个不同应用程序生成的会话ID，并确定安全会话ID生成算法的一些特征。
环境准备
我们将使用WebGoat 和RailsGoat(使用Rubyon Rails框架制作的WebGoat版本)。这两个应用程序都可用于易受攻击的VM_1 。
你需要在 RailsGoat中创建一个用户;所以，得到主页上进行注册。
实战演练
我们将开始分析RailsGoat 的会话cookie 。我们可以使用任何PHPSESSID或JSESSIONID cookie,但我们将利用这个作为自定义值来查看其他概念。将浏览器配置为使用Burp Suite作为代理，然后按照以下步骤操作:
1.登录RailsGoat并查看代理的历史记录，以获取设置会话cookie 的响应。你应该有标题Set-Cookie 并且应该设置一个名为的cookie_railsgoat_session
⒉.在这种情况下，这是对/railsgoat/session的请求。右键单击URL或请求或响应的正文，然后选择发送到Sequencer:

3.在继续使用Sequencer之前，让我们看看会话cookie包含的内容。这个_railsgoat_session的cookie值看起来像一个base64编码的字符串，用两个连字符（﹒）连接到十六进制字符串。我们将在本文后面解释这个推论。选择cookie 的值，右键单击它，然后选择Send to Decoder。
4.进入“解码器(Decoder)”选项卡,我们首先将其解码为URL,然后在第二行中将其解码为 base64:

这个好像base64代码包含三个字段:session_id，它是一个十六进制值，也许是一个哈希值，csrf_token，用于防止跨站请求伪造（CSRF)攻击的值，和user_id，似乎只是两个字符，可能是一个序号。cookie的其余部分(-之后的部分〉不是 base64编码的，并且看起来是随机哈希。现在，我们对会话ID有了更多的了解，并且已经学习了一些关于编码和 Burp Suite的解码器的知识。
5.让我们继续我们在Sequencer中的分析。转到Burp Suite中的Sequencer选项卡，确保选择了正确的请求和cookie:

6.我们知道cookie是用base64编码的，转到“分析选项(Analysis options)”选项卡并在分析之前选择Base64-decode。这样，Burp Suite将分析cookie中的解码信息。
7.返回“实时捕获(Live capture)”"选项卡，然后单击开始实时捕获。将出现一个新窗口，我们等待它完成。这需要一些时间。
8.完成后，单击“立即分析(Analyze now)”按钮:

我们可以看到cookie质量很好，这意味着攻击者不容易猜到。随意浏览所有结果选项卡。这是一个高质量的会话cookie的例子。
51
9.这次让我们来看一个不太好的会话cookie。登录WebGoat并进入会话管理缺陷，劫持会话。10．这个练习是关于通过劫持有效的会话ID来绕过登录表单的。尝试使用任何随机的用户名和密码进行登录，只是为了将其记录在 Burp Suite中:

11.在这种情况下，设置会话cookie的请求是第一次加载练习的请求;在 Burp Suite的历史中搜索Set-Cookie:WEAKID=响应头。这个ID仅仅是由连字符分隔的数字。
12．将请求发送到定序器
13．选择弱cookie作为目标进行分析。
14．启动实时捕获并等待它完成并执行分析:

对于这个 ID，我们可以看到质量非常差。就角色分析而言，我们可以有更好的想法:

这个图表显示了每个字符位置的变化程度或重要性。我们看到，重要性从位置﹖增加到位置3,从位置3增加到4，然后再次下降到5，也就是连字符的位置。这表明第一ID的一部分是增量的，并且可以应用于第二部分，但是具有不同的速率。
56
原理剖析
BurpSuite’s Sequencer对大量会话标识符（或从我们提供给它的响应中提供的任何信息）执行不同的统计分析，以确定这些数据是否被随机生成，或者是否存在允许att 的可预测模式Access生成有效D并劫持会话
首先，我们分析了一个复杂的会话cookie，该cookie由使用base64算法编码的数据结构和似乎是SHA-1哈希的数据结构组成。我们可以告诉第一部分是 base64编码的,因为它包含小写和大写字母，数字，也可能包含加号(+）或斜杠(/)，它也以%3D结尾，这是URL转义sequence ==，base64 中的字符串终止符。我们说cookie的第二部分是SHA-1哈希，因为它是一个40位的十六进制字符串，每个十六进制数字代表4位，4位* 40位=160位，和SHA-1是最流行的160位散列算法。
然后，我们分析了一个弱生成的会话ID。很明显它是增量的，因为在十进制数字中，最右边位置的数字比最近的左手邻居更频繁地变化十倍。ID的第二部分基于其长度和最高有效数字,表示Unix时间戳(https://en.wikipedia.org/wiki/Unix_time) 。
拓展
进一步深入了解WEAKID会话cookie 的生成机制，并尝试找出一种方法来发现活动会话cookie以绕过登录。使用Burp Suite的 Repeater和 Intruder来促进这项工作。
要了解有关如何区分编码，散列和加密的更多信息，请查看以下优秀文章:https://danielmiessler.com/study/encoding-encryption-hashing-obfuscation/

4.8不安全对象的直接引用

对象直接引用是指应用程序使用客户端提供的输入，并且按名称或其他简单标识访问服务器文件，例如，使用file参数搜索服务器中的特定文件并允许用户访问它。
如果服务器未正确验证用户提供的值，并且允许用户访问该资源，则攻击者可以利用此功能绕过权限控制并访问未授权该用户的文件或信息。在本文中，我们将在RailsGoat程序中分析和利用此漏洞。
准备
对于此方法，我们需要在RailsGoat 中注册至少两个用户。其中一个将是用户名user 的被攻击者，另一个是攻击者，用户名为attacker.
实战演练
对于本练习，我们最好知道两个用户的密码，尽管在真实场景中我们只知道攻击者的密码。配置浏览器，使用Burp Suite作为代理并执行以下操作:

1. 以账户user登录并转到账户设置，点击个人资料图片（右上角）和账户置;
   

请注意，在我们的示例中，URL表示users/7/account_settings。数字7有可能是用户ID吗?
⒉.注销并以账户attacker登录。
3.再次转到账户设置，查看attacker 的URL地址用户ID编号。4.在 Burp Suite 中启用请求拦截。
5.然后返回浏览器中更改attacker的密码。设置新密码，确认，然后单击“提交”
6.让我们分析截获的请求:

我们看屏幕截图的下划线部分。首先，请求9.json文件，9是attacker账户设置的URL 中的数字，因此作为用户ID。接下来，有一个user% 5Buser_id%5D参数（如果我们解码它，将得到
60
user[user_id])的值为9，然后是user% 5Bemail%50参数（如果我们解码它，将得到user[email))的值是attacker的邮箱。最后两个参数是密码及其重复确认密码。
7.那么，如果攻击者请求中对用户编号9的所有引用都未正确验证，该怎么办?让我们攻击受害者用户，其D为7。
8.用户attacker进行密码更改并再次拦截请求。
9.更改请求，将URL和user_id参数中自己的ID更改为被攻击者的ID。
10.根据屏幕截图中带下划线的值（特别注意: user[user_id]的值要更改!)，更改请求的剩余部分，或者根据自己的选择进行修改:

11.提交请求并验证它是否被接受（http响应代码200和正文中的消息成功)。12.注销并尝试使用原始密码作为被攻击者登录，登录将失败。

13.现在，尝试在attacker的请求中设置的密码，登录将成功。
14.转到账户设置并验证其他更改是否也发生了:

原理剖析
在本文中，我们首先检查了用户账户设置的URL，并注意到WEB程序是通过数字ID区分用户。然后，我们执行了更改用户信息的请求并且验证了数字标识符。之后我们尝试替换用户的ID，进行更改以影响其他用户，使用在同一请求中提供的用户ID进行更改，结果发现 RailsGoat直接对象引用是包含用户信息的。这样作为攻击者，我们只需要知道被攻击者的ID就可以更改他们的信息，甚至是密码，这样我们就可以代表他们登录。

4.9执行跨站请求伪造(CSRF)攻击

CSRF攻击是指经过身份验证的用户在对其进行身份验证的Web应用程序中执行不需要的操作的攻击。这是通过用户访问的外部站点完成的,并触发这些操作。
你可以这样来理解CSRF攻击:攻击者盗用了你的身份，以你的名义发送恶意请求，对服务器来说这个请求是完全合法的，但是却完成了攻击者所期望的一个操作，比如以你的名义发送邮件、发消息，盗取你的账号，添加系统管理员，甚至于购买商品、虚拟货币转账等。
在本文中，我们将从应用程序中获取所需信息，以便了解攻击站点应该如何向易受攻击的服务器发送有效请求,然后我们将创建一个模拟合法请求的页面,并诱使用户访问经过身份验证的那个页面。我们还将对概念的基本证明进行一些迭代，使其看起来更像真实世界的攻击，受害者不会注意到它。
准备
你们需要在Bodgelt中为此配置使用有效的用户帐户。我们将使用user@example.com作为受害者:

实战演练

我们首先需要分析我们想要强迫受害者提出的要求。为此，我们需要Burp Suite或浏览器中配置的其他代理:
1． 以任何用户身份登录 Bodgelt，然后单击用户名转到配置文件。
2． 进行密码更改,让我们看看代理中的请求是什么样的:

所以，这是一个 POST请求http://192.168.56.11/bodgeit/password.jsp并且只有密码及其在正文中的确认。
3． 让我们尝试创建一个非常简单的 HTML页面来复制这个请求。使用以下内容创建一个文件(我们将其命名为csrf-change-password.html) :

4.现在,在与登录会话相同的浏览器中加载此文件:

5．单击“提交”，将被重定向到用户的个人资料页面。密码已成功更新。

6．虽然这证明了这一点，但外部站点（或本例中的本地 HTML 页面）可以在应用程序上执行密码更改请求。用户仍然不太可能点击“提交”按钮。我们可以自动执行该操作并隐藏输入字段，以便隐藏恶意内容。让我们根据前一页创建一个新页面,我们称之为csrf-change-password-scripted.html:

7.如果我们在启动了Bodgelt 会话的同一浏览器中加载此页面，它将自动发送请求，之后将显示用户的个人资料页面。在下面的屏幕截图中，我们使用浏览器的调试器在请求发出之前设置断点:

8．从攻击者的角度来看，这最后一次尝试看起来更好，我们只需要受害者加载页面，请求将自动发送，但受害者将看到密码已被更改消息，这肯定会引发警报。
9．我们可以通过在同一页面内的不可见框架中加载响应来进一步改进攻击页面。有很多方法可以做到这一点，快速而有效的是为框架设置尺寸0。我们的文件看起来像这样。
注意表单的target属性是如何在它下面定义的 iframe，并且这样的框架具有0%的高度和宽度。

10．在启动会话的浏览器中加载新页面。这个截图显示了使用浏览器的开发人员工具检查页面时的外观:

请注意，iframe对象在页面中只是一个黑线，在Inspector中，我们可以看到它包含Bodgelt用户的配置文件页面。
73
11.如果我们分析CSRF页面所进行的网络通信，我们可以看到它实际上要求更改 Bodgelt密码:

原理剖析
74
当我们从浏览器发送请求并且已经存储了属于目标域的cookie时，浏览器会在发送之前将cookie附加到请求中，这就是使cookie像会话标识符一样方便的原因，但这种HTTP 工作方式的特点也使它容易受到像我们在本文中看到的那样的攻击。
当我们在应用程序中有活动会话的同一浏览器中加载页面时，即使它是不同的选项卡或窗口，并且此页面向启动会话的域发出请求，浏览器将自动附加会话该请求的cookie。如果服务器没有验证它收到的请求实际上来自应用程序内部，通常是通过添加包含唯一的参数,对于每个请求或每次更改的令牌，它允许恶意站点代表访问此恶意站点的合法，活跃用户进行呼叫，同时对目标域进行身份验证。
在Web应用程序渗透测试中，我们使用的第一个代码，带有两个文本字段和提交按钮的代码可能足以证明存在安全漏洞。但是，如果应用程序的渗透测试是另一项参与的一部分，例如社会工程或红队练习，则需要做一些额外的努力来防止受害用户怀疑发生了某些事情。在本文中，我们使用JavaScript通过在页面中设置onload事件并在事件处理函数中执行表单的submit方法来自动发送请求。我们还使用隐藏的iframe来加载密码更改的响应，因此，受害者永远不会看到他/她的密码已更改的消息。
拓展
应用程序通常使用Web服务执行某些任务或从服务器检索信息，而无需更改或重新加载页面，这些请求是通过JavaScript(它们将添加标头X-Requested-With: XMLHttpRequest)以及通常以JSON或XML格式添加的，其中 Content-Type标头的值为application / json或application/ xml。当发生这种情况时,我们尝试发出跨站点/域请求,浏览器将执行所谓的预检检查,这意味着在预期请求之前，浏览器将发送OPTIONS 请求以验证哪些方法和内容类型服务器允许从跨源（域应用程序所属的域以外）请求)。
预检检查可以中断CSRF 攻击，因为如果服务器不允许跨源请求，浏览器将不会发送恶意请求。但是,此保护仅在通过脚本进行请求时才有效,而不是在通过表单进行时。因此,如果我们可以将JSON或XML请求转换为常规HTML表单，我们就可以创建CSRF攻击。如果这是不可能的，因为服务器只允许某些内容类型，那么我们成功CSRF的唯一机会是服务器的跨源资源共享(CORS）策略允许来自我们的攻击域的请求，因此请检查服务器响应中的Access-Control-Allow-Origin标头。