tip21:

在API测试期间卡住了?

扩大攻击面! 使用http://archive.com，找到旧版本的web应用程序，探索新的API endpoints。

不能使用客户端? 扫描.js文件寻找url。其中一些是API endpoints。

tip22:

api从设计上倾向于泄漏PII。BE工程师返回原始JSON对象，并依赖FE工程师过滤敏感数据。发现敏感资源(如收据)?找到所有返回它的EPs: /download_receipt，/export_receipt，等等。

有些端点可能会泄漏用户无法访问的过多数据。

这是 OWASP api 前10名的一个例子-# 3-过度的数据曝光

tip23:

找到从网络服务器下载任意文件的方法?将测试从黑盒测试转为白盒测试。下载app的源代码(DLL files: use IL-spy; Compiled Java – use Luyten)阅读代码并发现新的问题!

tip24:

在API测试期间卡住了? 扩大你的攻击面! 记住开发人员经常在非生产环境中禁用安全机制(qa/staging/etc);

利用这一事实来绕过AuthZ, AuthN，速率限制和输入验证。

tip25:

发现“export to PDF”功能? 开发者很有可能使用外部库在后台来转换HTML——>PDF。尝试注入HTML元素并导致Export Injection。

导出注入: Export Injection

这篇文章，后面也会翻译出来，链接为：

tip26:

在api中寻找BOLA (IDOR) ?有401/403的错误吗? AuthZ绕过技巧:

• Wrap ID with an array{“id”:111} –> {“id”:[111]}
• JSON wrap {“id”:111} –> {“id”:{“id”:111}}
• Send ID twice URL?id=<LEGIT>&id=<VICTIM>
• Send wildcard {"user_id":"*"}

在某些情况下，AuthZ机制需要一个普通字符串(在本例中是一个ID)，如果它接收到一个JSON，它就不会执行AuthZ检查。然后，当输入到数据获取组件时，使用JSON而不是字符串(e。g:它扁平化了JSON)

tip27:

BE服务器不再负责保护XSS攻击。api不返回HTML，而是返回JSON。如果API返回XSS payload?

例子：

{"name":"In<script>alert(21)</script>on}，所以在用户侧永远都需要做XSS保护。

这个思路确实猥琐。

tip28:

如果我们在渗透的是一个.net编写的app应用。

找到一个包含文件路径/名称的参数? 开发人员有时使用path.combine (path_1,path_2)来创建完整路径。如果param#2是绝对路径，那么param#1被忽略。

关于控制path： Path.Combine Security Issues in ASP.NET Applications

tip29:

API暴露了应用程序的底层实现。渗透者应该利用这一事实来更好地了解用户、角色、资源和它们之间的相关性，并发现很酷的漏洞和漏洞。始终对API响应保持好奇。

tip30：

在API测试期间卡住了?扩大你的攻击面!

如果API有移动客户端，请下载APK文件的旧版本，以探索旧/遗留的功能，并发现新的API端点。

请记住: 公司并不总是从一开始就实现安全机制，而且DevOps工程师也不会经常弃用旧的api。利用这些事实来发现没有实现安全机制(授权、输入过滤和速率限制)的影子API端点

Download old APK versions of android apps: https://apkpure.com

tip31:

发现一个limit / page参数?

(例如: /api/news?limit=100)它可能容易受到7层DoS的攻击。尝试发送一个长值(例如:limit=999999999)，看看会发生什么.