访问控制缺陷之WebGoat练习 - 2016.01.06

        访问控制的方案很很多种，有基于角色的也有基于路径的。他们的基本原则都是根据用户的不同身份为用户划分等级，同样对可用资源也划分等级，进而根据用户的等级限制用户的对资源的访问。而现实网络中的访问控制却往往存在各种各样的控制缺陷。例如，我们将在下面提到的绕开基于角色的访问控制，进而获取我们想要查看的信息；绕开基于路径的访问控制，进而访问我们不能访问的资源。

        为什么会存在这样的问题，又怎样防御这样的缺陷。我想这才是我们学习的目的。首先让我们分析一下问题存在的原因：

      （1）服务器端过分相信不可信的客户端；

      （2）服务端端没有对主客体之间是否存在访问权限做合理的检查；

      （3）将客户的信息暴漏在客户端；

      （4）依靠不可靠的标示进行检查和查询；

       所以我们时刻要记着：（1）客户端是不可信的，从客户端传输过来的任何信息都有可能是假的，都有可能危害我们的服务器，我们必须对所传输的数据进行合理的检查；（2）对于像用户表示这样的用于服务器端进行比对查询的信息不要保存在客户端；（3）要对用户的身份和所提交的请求或者说权利进行严格检查；例如我们可以在用户登录的时候用session等机制标示用户的身份，然后每一次操作的时候我们用session值与用户所提交的操作进行合理的匹配，以保证当前用户只能行驶当前用户的权利，当然这样的话就要求session是不可预测的，否则还是不能保证访问的安全性。这就涉及到session的机制，稍后我们会提到。不在这里多说了，接下来让我们一起进入实验吧。

1.1 Using An Access Control Metrix（使用访问控制模型）

这个实验其实没有什么意思，设计这个实验的目的我想就是想让我们了解访问控制的概念。在这里每一个用户都代表着不同的身份，对系统所持有的资源也都有不同的访问权限，我们可以任意选择一个用户和资源，进而查看这个用户是否有对这个资源的访问权限。在这里我们需要找出的是对”'Account Manager'“拥有响应权限的人员，则我们只需逐个测试便可得出所找的人。如图1所示，我们可以看到在这里我们要找的那个人是 Larry。

图 1

1.2 Bypase A Path Based Access Control Scheme（基于路径的访问控制方案）

在这个实验中每个用户都有一个特定的身份，并且对如下资源的访问受到了其身份的限定。但是由于这个实验的路径访问是相对访问的，而且没有没有进行绝对路径的检查，因此我们可以通过构造相对路径进而查看我们不能查看的资源。

首先，我们任意选择一个文件，点击查看。然后我们在webscarab中可以看到我们提交的数据，如图2所示，我们提交的仅仅是一个文件名，那么我们就可以推测这个网站对文件的访问是将path与filename进行连接得到的绝对路径，那么这样就很好玩了，我们可以通过修改查看文件的name，进而通过相对路径的方式修改我们所访问的文件。以便查看。然后由题中指出当前用户所在路径为：”D:\WebGoat-5.4\tomcat\webapps\WebGoat\lesson_plans\English“，并且对”tomcat/conf/tomcat-users.xml“没有访问权限。

那么根据"./" 指当前目录，”../“上一个目录，这些是相对路径中常用的语法，我们可以发现我们需要修改文件名为”./../../../../conf/tomcat-users.xml“,如图3所示；然后提交数据到服务器端我们可以发现我们已经成功的绕开了基于路径的访问控制，结果如图4所示。

 

                                                      图  2                                                                                                                                              图 3

图 4

1.3 （Bypass Business Layer Access Control）绕开业务层的访文控制

这里的原理和上述差不多，不在赘述，直接开始试验。首先选择一个账户登录，登录之后检查手否有DeleteProfile按钮，如果有则换别的账号登录，直到找到一个没有这个功能的账号为止。在这里我们就以Tom为例，我们可以看到Tom没有DeleteProfile的权利，如图5所示。

图 5

         然后我们点击ViewProfile我们会在Webscarab中截取到如图6所示的信息。

                                                                                      图 6                                                                                                       图7

         我们发现了一个action项，它的value也就是他的操作类型，在这里我们可以修改其操作类型为DeleteProfile，如图7所示，然后执行我们没有权利执行的删除文件权限。然后提交数据你就可以看到如图8所示的成果结果，

图 8

1.4 Bypass Data Layer Access Control（绕开数据层的访问控制）

这个实验的原理和上述相同，不再细讲。大体说一下思路，首先我们需要知道其验证方式，即我们正常登陆然后操作截取数据进行分析，发现是通过ID进行控制的，那么我们就需要知道一个具有更高身份的用户的ID，然后当登陆后，我们在查看用户信息的时候通过Web拭擦然进行截取提交的数据，将要查看的用户的ID改成我们的目标ID即可，这样我们就可以查看目标用户（即正常方式我们是没有办法访问的用户）的信息。至于怎样找到合法用户的ID，有多种方法，一种是我们可以随意猜测；另外一种是我们可以先试着用别人的账号登录一下，这个时候虽然不会登录成功，但是如果我们截取数据包，我们会发现我们尝试登录用户的ID；

1.5 Remote Admin Access（远程管理访问）

任何网站通常都会有自己的管理界面，这一个界面普通用户是无法看到的，也是无法访问的，只有具有特权的用户才可以进行访问。然而有一些网站在这个方面的管理比较薄弱，往往采用通用的参数传递或管理路径进行用户身份区别；最常用的就是/admin或者admin=true等。接下来让我们体验一下这种感觉。

首先，让我们进入管理界面，如图9所示，然后我们尝试在URL地址栏中加入&admin=true，会出现什么情况呢，如图10所示。然后再每一个选项里进行相同的操作，我们会看到很多我们在普通管理界面看不到的信息。如图11和12所示。

图 9                                                               图10

图11                                                                                                                                               图12

到此为止，WebGoat访问控制缺陷这一段的练习就做完了，不知道对那些刚刚步入Web编程有没有什么启发，有没有觉得自己平时写的网站bug百出啊，反正我是这么深有体会，好好想想在以后的编程开发中怎样才能避免这些由访问控制缺陷引发的危害吧。具体怎样避免这些漏洞怎么避免我就不多说了，如果大家有兴趣的话我们可以进行讨论，讨论毕竟避免这些漏洞引入的方法是很多的。