webgoat-Broken Access ControlI 访问控制失效

Hijack a session会话劫持

在登录认证的设计中，如果对session id的生成机制考虑的不够严谨，比如没有足够的复杂和随机，应用就可能遭受到基于session的暴力破解攻击。

目标

Gain access to an authenticated session belonging to someone else.

获得某人认证的session

作业0x02

预测hijack_cookie的值，这个值用来区分已经认证的用户和匿名的用户。

参考A1-Hijack a session - 知乎 (zhihu.com)

1、使用自己的账号密码点击登录，提示失败，但是发现cookie设置了一个hijack_cookie的值。

2、删除 hijack_cookie，多次点击access，发现输出的hijack_cookie分别为如下值，可以看到前缀是相似的，而前面的字符串没有105，所以猜测前面一串为1280708799358440105，后面那串，我直接用104对应的那个值，点击access，直接通过了。

看来这里难度降低了，实际应该暴力破解，后面那串值应该在83693-99269之间。

1280708799358440102-1699436020760
1280708799358440103-1699436036272
1280708799358440104-1699436083693
1280708799358440106-1699436099269

源代码

 public Authentication authenticate(Authentication authentication) {
    if (authentication == null) {
      return AUTHENTICATION_SUPPLIER.get();
    }
 
    if (StringUtils.isNotEmpty(authentication.getId())//如果id不为空，并且sessions包含这个id，就认证成功。
        && sessions.contains(authentication.getId())) {
      authentication.setAuthenticated(true);
      return authentication;
    }
 
    if (StringUtils.isEmpty(authentication.getId())) { //如果getId为空，则设置id
      authentication.setId(GENERATE_SESSION_ID.get());
    }
 
    authorizedUserAutoLogin();//调用登录方法
 
    return authentication;
  }

总结：再回过来看这一节，目的其实就是有一个已登录的session id，让我们找到这个session id是谁。我们根据返回的hijack_cookie值的规则，找到了这个session id。

这篇作者想告诉我们，如果session机制设计的有问题，会引发一系列的session安全问题

Insecure Direct Object References不安全的直接对象引用

直接对象引用

直接对象引用是指应用程序使用客户端提供的输入来访问数据和对象。

例子
使用 GET 方法的直接对象引用示例可能如下所示

https://some.company.tld/dor?id=12345

https://some.company.tld/images?img=12345

https://some.company.tld/dor/12345

其他方法
POST、PUT、DELETE 或其他方法也可能容易受到影响

不安全的直接对象引用

当引用未得到正确处理时，是不安全的，可能被权限绕过，或者泄露私人数据，或者用户也可以执行本无法执行的操作，访问不该访问的数据。

假设作为用户，查看个人资料，URL 如下所示：

https://some.company.tld/app/user/23398

这里的url中暴露的是用户id，如果修改id，是否能查到其他用户信息？

https://some.company.tld/app/user/23399…​或在末尾使用另一个数字。如果您可以操作数字（用户 ID）并查看他人的配置文件，则对象引用是不安全的。 当然，这可以检查或扩展到 GET 方法之外，查看数据或者操作数据。

更多好读物
 

https://www.owasp.org/index.php/Testing_for_Insecure_Direct_Object_References_（OTG-AUTHZ-004）

https://www.owasp.org/index.php/Top_10-2017_A5-Broken_Access_Control

https://cheatsheetseries.owasp.org/cheatsheets/Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet.html

https://www.owasp.org/index.php/Top_10_2013-A4-Insecure_Direct_Object_References

http://cwe.mitre.org/data/definitions/639.html

先进行身份验证，后滥用授权

许多访问控制问题容易受到经过身份验证但未经授权的用户的攻击，所以我们先从合法认证开始。然后，我们会找办法绕过或者滥用授权。

账号的id和密码时tom 和cat（这是不安全的）

认证之后，进入下一节。

作业0x02

直接使用tom cat登录

观察差异和行为

从进攻端来看，AppSec 的一个一致原则是查看原始响应与可见响应的差异。

原始响应中通常有数据不会显示在屏幕/页面上。

here is often data in the raw response that doesn’t show up on the screen/page

查看下面的文件并注意差异。

作业 0x03

点击profile，查看响应，repsonse中有几个属性，页面上没显示的属性是role和userid

 猜测模式

我们正在测的应用似乎遵从restful风格，很多app都有可以让用户访问其他用户信息的角色，所以/profile不能告诉我们，我们要访问的是哪个用户的信息。所以请猜测有没有方式可以使用直接对象引用来查看你的信息？

作业0x04

因为上一节接口给出了隐藏字段role，userid，并且第三题URL为 http://127.0.0.1:8080/WebGoat/IDOR/profile

所以猜测用userid可以访问。
填写为WebGoat/IDOR/profile/2342384 提交

意思是直接使用userid就可以查询该id的信息。如果知道了其他用户的id，那就也可以查询信息了。
在restful风格中，提供使用同样的url，不同的方法来进行处理，可以利用这样的模式，比如修改方法，传body，看能否对某些属性做出修改。

playing with the patterns

查看其他人的简介

使用同样的方式查看其他人的简介信息，使用view profile按钮，拦截并修改请求，查看其他人的简介信息。另外，使用浏览器只能发送get请求（意思是只用浏览器是做不出题的）

作业0x05

点击view profile，接口为 GET /WebGoat/IDOR/profile/%7BuserId%7D

将后面{userld}修改为3中查到的id GET /WebGoat/IDOR/profile/2342384，返回 try again

需要将userid进行暴力破解。

我这里暴力破解报错了很多500，还需要看下原因。

答案为 /WebGoat/IDOR/profile/2342388 可以返回一个已有用户的信息。

参考A1-Insecure Direct Object References - 知乎 (zhihu.com)

 本题的主题是Insecure Direct Object References，不安全的对象引用，本质上是后端的验证逻辑有问题，直接相信了前端传进来的参数来进行逻辑处理，而导致的越权访问。

在实际的场景下，研发人员通过请求的id参数获取到参数的值以后，一般会根据该id去查询数据里面的数据。在查询之前有一个很重要的验证：

使用后端session中获取到该用户的信息，然后根据该用户绑定的数据范围去查询属于该用户的数据。

也就是不能用前端传进来的用户id作为识别用户的条件，因为前端参数是可以被篡改的

安全的对象引用

1、要有权限控制文档。权限控制是由业务逻辑定义的。
2、水平和垂直权限控制，通常我们使用角色来进行权限控制，但是同样角色的用户，也可能获取到其他用户的信息，这就是水平权限，也需要进行控制。

3、审计。权限控制规则应该包括哪些操作应该被记录下来，如超级用户或者管理员修改了其他人的信息，应该有日志记录。另外试图破坏权限控制机制的操作也应该记录下来。
4、使用间接引用。这个的方法用的比较少，可以hash，编码或者其他的方法，使客户端看到的id不是真实的引用对象，
这会降低一些处理效率，但是也容易被猜测，暴力破解，或者反编译。
5、权限控制API 如 JSON Web Tokens (https://jwt.io和Secure Token Binding

Missing Function Level Access Control缺少功能级别访问控制

Relying on obscurity

可以使用 HTML, CSS, or javascript 隐藏用户一般用不到的链接. 在过去，一个网络路由视图使用js在UI中隐藏管理员相关功能。Blogger: Time Warner Routers Still Hackable Despite Company Assurance | WIRED.

找到隐藏内容

There are usually hints to finding functionality the UI does not openly expose in:

• HTML or javascript comments

• Commented out elements

• Items hidden via CSS controls/classes

作业0x04

要求对第二题找到的链接/WebGoat/access-control/users-admin-fix，根据这个链接，获取jerry的hash。

参考：A1-Missing Function Level Access Control - 知乎 (zhihu.com) 

1、 GET方法访问这个链接，提示403，权限不够，只有admin可以访问

2、在源码里，针对这个链接还有一个post方法，可以用来设置用户的角色。

用post方法请求，将当前自己的账号设置为admin

3、然后GET方法请求

这个题的bug之处在于如果没有源码，不知道可以设置角色，那就解不出来了。 

总结：对于url，method,function都要做access control，不要试图通过hide信息让用户无法访问，一旦这些信息泄露，被攻击者发现，就over了。 

Spoofing an Authentication Cookie cookie欺骗

cookie用来认证用户身份，由服务器通过set-cookie设置，cookie 通常存储在客户端和服务器端。

一方面，将 cookie 存储在客户端意味着它可能容易通过利用某些漏洞或通过中间人攻击或 XSS 进行拦截而被盗。另一方面，如果获得了用于生成 cookie 的算法，则可以猜测 cookie 值。

如果提供了正确的身份验证 cookie，许多应用程序将自动登录用户。

用户不应能够猜测 cookie 生成算法，也不能通过以其他用户身份登录来绕过身份验证机制。

为了降低这种风险，必须采用强大且加密安全的算法来生成身份验证 cookie。这些算法应使用强大的随机化和哈希技术，以确保生成的cookie的唯一性和不可预测性。

此外，实施会话过期和定期轮换身份验证 cookie 等措施可以进一步增强安全性。通过频繁更改 cookie 值和强制执行会话超时，攻击者利用任何潜在漏洞的机会窗口会大大减少。

总体而言，保护身份验证 cookie 生成算法的机密性和完整性对于防止未经授权的访问和维护身份验证机制的完整性至关重要。

作业0x02

题目要求通过欺骗认证cookie来绕过认证机制，用tom登录。

参考：A1-Spoofing an Authentication Cookie - 知乎 (zhihu.com)

方法

1、知道tom的账号和密码

2、知道tom的cookie值。

给了两个账号和密码，分别登录，提示设置了一个叫spoof_auth的cookie值，

 base64解码得到一串数字

再用16进制解码 得到 lCkUchkoNTnimda

webgoat同样方法解码得到 lCkUchkoNTtaogbew

可以看到前缀一样，后面是用户名翻转。所以对 lCkUchkoNTmot先16进制编码再base64编码得到 NmM0MzZiNTU2MzY4NmI2ZjRlNTQ2ZDZmNzQ=

 HEX编码/解码 - 在线工具 (try8.cn)

 

然后抓包，加上spoof_auth再请求

 源码：

通过源码可以可以看到验证cookie的逻辑是：

1.如果请求中携带了cookie，就使用cookiLoginFlow进行处理

2.在cookiLoginFlow里面可以看到对cookie值进行了base64、16进制解码，然后反转后全部转换成小写

3.然后对比这个cookie值中是否包含了指定的用户名(题目中设定的用户名是tom),只要包含了就可以过关；

4.因此通过源代码，我们发现制造这个cookie其实很简单，只需要原始的字符串中包含tom这个用户名即可。

比如：xxxxxxxxxxmot,对其进行16进制编码，然后在base64编码，得到的值也可以认证通过。

4.总结

这个题貌似也没啥总结的，跟Hijack a session有点像，只是这里作者换了一个“错误的设计”方式。将sessionid的生成搞的太简单了，导致攻击者可以很容易找到的规律。

在实际的系统开发中，大多数的session生成机制都会使用框架自带的方式去生成，而不会自己手动设计了。在java开发中比如：spring security 、shiro等，只需要自定义对应的配置，就可以自动生成属于自己的session.

使用框架的好处是方便，安全。。。真的安全吗？额，也不一定。

因为框架的源码都是公开的，各种算法和机制都是公开的，如果设计机制有问题，被安全研究员挖来的话，因为用的人比较多，因此这种漏洞影响也会比较大。

本题收获

1、java代码调试。

2、运行一个java，只用在class里写main就行了，都忘记这个了。

3、带==的是base64编码，一串数字是16进制，也可以用burpsuite进行编码解码。