以审计的角度走遍全关卡

目录

1. (A1) Broken Access Control（访问控制失效）
• 1.1 会话劫持
• 1.2 不安全的直接对象引用
• 1.3 缺失功能级访问控制
• 1.4 伪装认证Cookie
2. (A2) Cryptographic Failures（加密失败）
3. (A3) Injection（注入）
• 3.1 SQL注入(介绍)
• 3.2 SQL注入(高级)
• 3.3 SQL注入(缓解措施)
• 3.4 跨站脚本
• 3.5 跨站脚本（存储）
• 3.6 跨站脚本（缓解措施）
• 3.7 路径穿越
4. (A5) Security Misconfiguration（安全配置错误）
• 4.1 跨站请求伪造
• 4.2 XXE
5. (A6) Vuln & Outdated Components（易受攻击的组件）
• 5.1 易受攻击的组件
6. (A7) Identity & Auth Failure（身份认证失败）
• 6.1 认证绕过
• 6.2 不安全的登录
• 6.3 JWT tokens
• 6.4 密码重置
• 6.5 安全密码
7. (A8) Software & Data Integrity（软件和数据完整性故障）
• 7.1 不安全反序列化
8. (A9) Security Logging Failures（安全日志故障）
• 8.1 日志安全
9. (A10) Server-side Request Forgery（服务器端请求伪造）
• 9.1 服务器端请求伪造
10. Client side（客户端安全）
• 10.1 绕过前端限制
• 10.2 客户端过滤
• 10.3 HTML 篡改
11. Challenges（挑战关卡）
• 11.1 管理员丢失密码
• 11.2 无密码
• 11.3 管理员密码重置
• 11.4 没有账户
12. 本文涉及的所有代码和文件

(A1) 一、Broken Access Control（访问控制失效）

1.1 会话劫持

第一关，定位请求接口。

定位代码位置。分析处理逻辑，我们这里的目的是通过劫持已登录用户的会话，所以我们当前是没有登录状态的。重点在于代码:

authentication = provider.authenticate(Authentication.builder().id(cookieValue).build());//认证通过就过关if (authentication.isAuthenticated()) {return success(this).build();}

Authentication.builder().id(cookieValue).build()中cookieValue未认证用户不存在hijack_cookie，因此该代码创建了一个Authentication实例并未初始化任何值。定位类HijackSessionAuthenticationProvider的authenticate方法。重点分析如下代码即可。

  private Queue<String> sessions = new LinkedList<>();  private static long id = new Random().nextLong() & Long.MAX_VALUE;  protected static final int MAX_SESSIONS = 50;  private static final DoublePredicate PROBABILITY_DOUBLE_PREDICATE = pr -> pr < 0.75;  private static final Supplier<String> GENERATE_SESSION_ID =      () -> ++id + "-" + Instant.now().toEpochMilli();  public static final Supplier<Authentication> AUTHENTICATION_SUPPLIER =      () -> Authentication.builder().id(GENERATE_SESSION_ID.get()).build();  protected void authorizedUserAutoLogin() {if (!PROBABILITY_DOUBLE_PREDICATE.test(ThreadLocalRandom.current().nextDouble())) {      Authentication authentication = AUTHENTICATION_SUPPLIER.get();      authentication.setAuthenticated(true);      addSession(authentication.getId());    }  }

因此我们构造一个脚本，每次发送一个请求后遍历该请求附件的几个id以命中有效会话，为了避免本文过长，本文涉及的脚本内容文末一起奉上，结果如下。

1.2 不安全的直接对象引用

第一关，输入tom和cat直接过。第二关，题目说列出服务器响应中存在但在配置文件中未显示的两个属性。对比一看代码中多了userId和role,提交过关。第三关，定位接口，检索代码。拼接请求路径即可，但是你会发现需要userId,还记得第二关的userId吗？在burp构造请求获取即可。拼接WebGoat/IDOR/profile/2342384通过。第四关，存在两个问题，分别解决。题目让我们查看别人的资料，这里从代码可知，这个别人应该就是2342388，当然如果作为黑盒测试您一定会枚举对吧。第二小题让我们编辑其他用户的配置文件，这往往涉及到不同的请求方法，定位接口。同时你会发现你检索IDOR/profile/{userId}似乎没有什么有用的信息，不过题目要求你修改别人的信息这个userId此时应该是一个具体的值，会不会就是2342388呢？让我们检索一下。好吧，你很聪明，你发现了它，让我们构造对应的请求完成题目。当然请注意Content-Type: application/json的设置，不要被这小错误而困扰。

1.3 缺失功能级访问控制

第一关，题目让我们找一些隐藏的东西，不过我们不管直接，整代码(狗头)。

1.4 伪装认证Cookie

定位请求接口，检索代码，分析逻辑。

依照代码算法，我们可以得到如下示例，其中xxx代表随机字符串，只要开头以tom开头即可，这是由代码decoded.substring(0, decoded.length() - SALT.length())得出。同时根据代码private static final String SALT = RandomStringUtils.randomAlphabetic(10);得出随机字符串长度为10。

tomxxxxxxxxxx->xxxxxxxxxxmot->787878787878787878786d6f74->Nzg3ODc4Nzg3ODc4Nzg3ODc4Nzg2ZDZmNzQ=

则tom的cookievalue值应该为Nzg3ODc4Nzg3ODc4Nzg3ODc4Nzg2ZDZmNzQ=。

二、(A2) Cryptographic Failures（加密失败）

第一关，base64解码 c2hpeXVlOnBhc3N3b3Jk解码得到shiyue:password过关。 第二关，定位接口，检索代码。

第三关，定位接口，分析代码。

同时secret变量来自于如下代码。

 public static final String[] SECRETS = {"secret", "admin", "password", "123456", "passw0rd"};

因此题目中的hash均来自于这个列表，手动试一试即可。

第二关，根据给定的私钥计算公钥的模数和模数的签名。

这里似乎没什么可直接得到的，老老实实计算。

┌──(shiyue㉿kali)-[~/Desktop]└─$ openssl rsa -in private.pem -modulus -noout | sed 's/Modulus=//'83C3385487173B1516A983E7A0EA715850B111798316C243F24FC0E7B95581885A0EF119AD61C2628BAD20E52B8BC0424CDB4D7AB76B557C5710322420191A91643149125C8F494B7177B01BD9AD46A2C727D7FCF0FF13E8AE2501D44FCA9F43EBB8B413B6425BC872A5C31F7833EAAB1F65FD0E25771481CE797D5343854F9C20FC7F30D132BA09A2D80812E7716407FA50823694FF0491CDAEBFA99FBAF72F2AB729FDE3A6A812E1A5E26DDE2FDD1137F2FCB1DA0D4C60FAC3327DF81DBB53CAD662DF46CCEE4299DFCCE3D17A2D59DAD75636A325743F00DD7B04F615F1209AF1A3F64689FD4F2486ED51BEE494B11D1A55A91AB6CAF619957DE653A1A0BF┌──(shiyue㉿kali)-[~/Desktop]└─$ openssl rsa -in private.pem -modulus -noout | sed 's/Modulus=//' | tr -d '\n' | openssl dgst -sha256 -sign private.pem | base64 -w 0S9hg/iHaqg206/iH3RG/PeLHBVI5/nUkOWJAYwl2CKCfVogrV3sGJo07Fs6ewMoalM/tNR1otK+Nwp7ntWm0zCXBOQUZvYADRxwC4ubdNNSYmXyWOgN/qfn58eKRhvBdkp6vLq9jNpI1Rd8aj7NEV9C6MOAH+X9OFUJ3zO9GBQNZfzV4RXAuzkebNAlQfMKx9jLuZQMtGeT60BIF6TDrUTbGCSCLZbcoVooxHsHWHsn82OrtxIR7NOJrCmGYUXLQCnsnBlbhLWGnHrZr0NFvAjn0kyWu1+DUhso8T6gY80DpvG/8ytGSAPEf1Kl06z5c0rqPMRiolvkTK0ZBOJBerw==   

第三关，定位接口，并检索代码。

解码text提交结果。

三、(A3) Injection（注入）

3.1 SQL注入(介绍)

第一关，定位接口，分析代码。

第二关，定位接口，分析代码发现主要更新Barnett的部门为Sales即可过关。

第三关，定位接口，分析代码发现如果员工表中存在phone这一列则过关，所以添加一列即可。

第四关，定位接口，分析代码发现需要给unauthorized_user用户授予grant_rights 表的查询权限。

第五关，定位接口，分析代码发现直接拼接用户输入的sql语句，当用户输入的查询结果超过6行时通关。

第六关，定位接口，分析代码发现虽然login_count用了PreparedStatement（安全），但accountName没有用?占位符，而是直接拼进去，所以仍然是注入点。

第七关，定位接口，分析代码发现直接拼接sql语句导致注入。

第八关，定位接口，分析代码发现存在sql注入，并且只需要将John Smith的薪水设置的比当前最高薪资还高时即可过关，参考语句3SL99A'; UPDATE employees SET salary=84700 WHERE last_name='Smith'; --

第九关，定位接口，分析代码发现存在sql注入，需要使得查询结果为空的同时删除access_log表即可通关，参考语句'; DROP TABLE access_log; --。

3.2 SQL注入(高级)

第一关，定位接口，分析代码。

既然代码要求输出包含指定内容output.toString().contains("dave") && output.toString().contains("passW0rD")那么我们直接输入。

正规途径还是通过sql注入获取指定内容，虽然代码检测了union但是并未作为黑名单拒绝，仅仅只是构建了消息内容，因此我们完全可以通过联合查询获取指定的内容以通关。

构建联合查询通过该关卡-1' UNION SELECT userid, user_name, password, cookie, NULL, NULL, NULL FROM user_system_data -- 。

自然你也能从联合查询获取的内容得到密码过关。

第二关，定位接口，分析代码。

直接在代码文件中找到tom的密码，取巧过关。

老老实实分析下代码。

我们发现登录接口写法合规不存在sql注入漏洞，切换注册接口。

通过代码分析，注册接口在检查注册的用户名是否已经存在时存在sql注入漏洞，因此我们通过该漏洞获取tom的密码，同时这是一个经典的布尔盲注。

这里就不手动注入了，直接使用sqlmap获取结果，命令python sqlmap.py -r 1.txt --dbms=HSQLDB --technique=B --string="already exists" --sql-query="SELECT password FROM sql_challenge_users WHERE userid='tom'"结果如下。

3.3 SQL注入(缓解措施)

第一关，题目这里是希望你编写正确的参数化查询方式，但是我们直接定位接口，分析代码过关。

第二关，定位接口，分析代码发现题目让我们提交一段包含数据库操作的预编译代码，只要编译通过即可过关。

这一步你可以借助ai完成代码。

第三关，搜索路由不存在，代码中不存在该接口。

直接检索参数userid_sql_only_input_validation定位真实的接口，这里可能是靶场前端编写有误。

通过分析代码可知，唯一的过滤式不能存在空格，输入语句Smith';SELECT/**/*/**/from/**/user_system_data;--通关，当然修改下接口地址。

第四关，前端依旧那个接口地址。

通过参数检索定位后端处理接口。

简单的过滤双写即可绕过，输入语句Smith';SELselectECT/**/*/**/frfromom/**/user_system_data;--，不过依然需要修改下接口地址。

第五关，定位接口，检索代码，发现提交接口不存在注入风险。

分析排序接口。

检索分析代码发现存在order by的sql注入。

针对order by注入，我们这里使用case when的方式进行布尔盲注获取id地址，给出语句(CASE+WHEN+(SUBSTRING((SELECT+ip+FROM+servers+WHERE+hostname='webgoat-prd'),1,1)='1')+THEN+id+ELSE+hostname+END)。

当然我们也可以投机取巧直接搜索代码拿到。

3.4 跨站脚本

第一关，定位接口，分析代码发现filed1存在xss回显，并且需要命中指定的标签才可通关。