API 安全测试的 31 个 Tips

TIP1

旧的API版本通常会包含更多的安全漏洞，他们缺乏一些安全机制。我们可以使用REST API的一些特征来预测是否存在旧的API版本。比如当前有一个API被命名为/api/v3/login ，我们可以检查/api/v1/login是否存在 。

TIP2

永远不要假设只有一种方法来验证API的身份。现代的应用程序有很多API接口用于认证:/api/mobile/login| /api/v3/login| /api/magic_link等。找出他们并测试所有的授权认证问题。

TIP3

sql注入

TIP4

测试一个Ruby on Rails的应用程序&注意到一个包含URL的HTTP参数?开发者有时会使用“Kernel#open”函数来访问url == Game Over。只需要发送一个管道作为第一个字符，然后发送一个shell命令(通过设计的命令注入)

TIP5

SSRF漏洞

1. 内部端口探查
2. 利用云服务
3. 使用http://webhook.com显示IP地址和HTTP库
4. 下载大文件(7层DDOS)
5. 反射SSRF，本地管理平台泄露

TIP6

批量赋值是真实存在的。现代框架鼓励开发人员在不了解安全性影响的情况下使用批量赋值。在使用过程中，不要猜测对象的属性名，只需找到一个返回所有属性的GET端点。

TIP7

一家公司向开发者公开了API接口，且在移动端和web端使用了相同的API程序。我们需要分开测试它们，不要假设它们实现了相同的安全机制。

TIP8

在测试api的时候，虽然REST API是当前最常见API形式，但是我们也还检查一下API是否也支持SOAP。将content-type更改为“application/xml”，在请求主体中添加一个简单的xml，并查看API如何处理它。

有时身份验证是在REST和SOAP API之间共享的不同组件中完成的== SOAP API可能支持JWT

TIP9

试图找到BOLA(Broken Object Level Authorization)的弱点?HTTP bodies/headers 中的id往往比url中的id更容易受到攻击。首先试着关注他们。

TIP10

利用REST的可预测特性来查找管理API endpoints!比如你看到一个api叫做GET /api/v1/users/<id>，我们可以试着修改请求方法POST/DELETE来create/delete users.

TIP11

检查API是否使用授权头？如果身份验证机制不支持cookie，那么这个API就被设计为防止CSRF。

TIP12

即使ID是GUID或非数字类型的值，渗透测试人员也要尝试发送一个数字值。例如: / ?user_id=111代替user_id=inon@traceable。有时身份认证机制同时支持这两种方式，而且暴力破解数字更容易。

TIP13

使用大量分配绕过安全机制。例如，“输入密码”机制:

• POST /api/reset_pass requires old password.
• PUT /api/update_user is vulnerable to MA == can be used to update pass without sending the old one (For CSRF)*

TIP14

在API测试期间卡住了?扩大你的攻击面!查找 sub/sibling domains 使用http://Virustotal.com和http://Censys.io。其中一些域可能使用不同的配置/版本公开相同的api。

TIP15

静态资源包括照片、视频.等，Web服务器(IIS、Apache)在授权时对静态资源的对待是不同的。即使开发人员实现了良好的授权，也有很好的机会访问其他用户的静态资源。

TIP16

即使您使用另一个web代理，始终在后台使用Burp。@PortSwigger的人在帮助你管理pentest方面做得非常好。使用“树视图”(免费版本)功能查看您访问过的所有API端点。

TIP17

移动证书锁定？在你开始逆向工程和修补客户端应用程序之前，检查iOS和Android客户端以及它们的旧版本。很有可能其中一个没有启用证书锁定。

TIP18

公司和开发人员倾向于将更多的资源(包括安全性)投入到主要的api中。那些很少被人们使用过的API endpoints可以发掘一些有趣的漏洞。如POST /api/profile/upload_christmas_voice_greeting

TIP19

你觉得哪些功能更容易受到攻击?

• Organization's user management
• Export to CSV/HTML/PDF
• Custom views of dashboards
• Sub user creation&management
• Object sharing (photos, posts,etc)

TIP20

测试AuthN api ?如果您在生产环境中进行测试，那么很有可能AuthN端点具有抗暴力破解保护。无论如何，DevOps工程师倾向于在非生产环境中禁用速率限制。不要忘记测试它们:)

A good example of this issue: Facebook Breach (Found by @sehacure) http://www.anandpraka.sh/2016/03/how-i-could-have-hacked-your-facebook.html

TIP21

在API测试期间卡住了?扩大攻击面!使用http://archive.com，找到旧版本的web应用程序，探索新的API endpoints。不能使用客户端?扫描.js文件寻找url。其中一些是API endpoints。

TIP22

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

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

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。

Learn more about Export Injection: https://medium.com/@inonst/export-injection-2eebc4f17117

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? - E.g: {"name":"In<script>alert(21)</script>on}，所以在用户侧永远都需要做XSS保护。

TIP28

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

Leverage it to control the path

Learn more: https://www.praetorian.com/blog/pathcombine-security-issues-in-aspnet-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)，看看会发生什么.