DVWA靶场之十八：API 安全（API Security）
DVWA靶场之十八：API 安全（API Security）
大多数现代网页应用都会使用某种 API（无论是单页应用 SPA，还是用来填充传统页面的数据接口）。由于这些 API 通常在后台运行，开发者有时会在认证、授权或数据校验等地方偷工减料。作为测试人员，我们可以绕开前端直接访问这些看似“隐藏”的调用，从而利用这些弱点。
本模块将研究三个弱点：版本管理（versioning）、批量赋值（mass assignment），以及……（未写完）。
目标：
每一关都有各自的目标，但总体思路是利用实现不当的 API 来进行攻击或绕过安全控制。
1. low
通过查看 JavaScript 或监听网络流量，你应该会注意到有一个请求被发送到 /vulnerabilities/api/v2/user/，用于检索生成用户表所需的数据。
既然请求是针对端点的第 2 版（v2），显然可以尝试查看第 1 版是否可用以及它提供了什么。最简单的方法是在浏览器中直接访问 /vulnerabilities/api/v1/user/，但有时 API 调用需要额外的头信息或认证令牌，这种情况下让站点添加这些信息会比你手动添加更方便。有两种更容易的做法：一是给 JavaScript 在页面加载时修改其使用的 URL —— 在发出请求前对该位置设置断点并在断点处修改请求；二是用代理（例如 Burp Suite）拦截该请求。
无论你采用哪种方法，通过访问该端点的第 1 版，你应该能够在返回的数据中看到密码哈希。
首先依照上述方法可以看到
我们把其中的v2改成v1重新发送得到
可以看到密码的hash值
1c8bfe8f801d79745c4631d09fff36c82aa37fc4cce4fc946683d7b336b63032
e5326ba4359f77c2623244acb04f6ac35c4dfca330ebcccdf9b734e5b1df90a8
a89237fc1f9dd8d424d8b8b98b890dbc4a817bfde59af17c39debcc4a14c21de
破解后可得
2. medium
不仅要分析网站当前的API调用，还要去查阅Swagger文档，看看有没有其他目前没用到、但可以添加的参数。
当你更新名字时，会向 /vulnerabilities/api/v2/user/2 发送一个 PUT 请求，内容如下：
{"name":"morph"
}
查看Swagger文档http://127.0.0.1/vulnerabilities/api/gen_openapi.php能看到，
UserUpdate 的定义是：
UserUpdate:required:- nameproperties:name:type: stringexample: fredtype: object
这正是你目前传的内容，但如果你看 UserAdd，会发现一个额外的参数：
UserAdd:required:- level- nameproperties:name:type: stringexample: fredlevel:type: integerexample: usertype: object
注意那个额外的 level 参数吗？
在这种情况下，值得测试一下：在类似的接口上存在的额外参数，是否也能在你正在使用的接口上生效。
要尝试这一点，你可以在代理中拦截请求，或者在请求发送到服务器之前修改 JSON。在页面里修改的话，可以在 update_name 函数中设置断点，等 data 变量创建后，在控制台里用下面的命令修改该变量：
data = JSON.stringify({name: name, level: 0})
如果你这样做，然后检查发送到服务器的 PUT 请求中的 JSON，你应该会看到：
{"name": "hacked","level": 0
}
并且（希望）会看到一条恭喜你成功的提示信息。
我们这里使用burp，添加"level": 0后执行
成功
3. high
这是 OpenAPI 文档，看看里面的 health 函数，找出是否有存在漏洞的函数。
你可以手工推断每个接口怎么调用，但把这个文档导入到像 Swagger UI、Burp、ZAP 或 Postman 这样的工具里会更容易——这些工具会帮你自动生成请求，省去很多手工配置的麻烦，从而更快地测试每个接口是否有问题。
把这四个 health接口导入你选择的测试工具中，并确认它们能正常运行。等它们都能正常工作后，再测试它们是否存在漏洞。
未完待续