原项目链接： 31-days-of-API-Security-Tips

tip1:

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

比如:

http://api.example.com/v3/login

可以把v3换成v2,v1等等，其实如果想探测到更多的版本，可以探测一些大范围比如v0-100等等。还有存在一些v2.1 这种小版本的可能。

http://api.example.com/v2.1/login

tip2:

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

认证的接口确实很多，包括

• /api/mobile/login

• /api/v3/login

• /api/magic_link

这种需要去变量很多的二级子目录，再加上login，或者一些其他的接口也是可以登录，这个需要查看官方的文档。

OAuth的认证机制，需要学习一下。很多大公司的OAuth的接口如下：

做认证的时候，公开API 一般为：

https://api.example.com/v1/oauth2/toke

tip3:

还记得5-10年前SQL注入是多么常见么？你几乎可以进入任意一家公司。BOLA(IDOR)是API安全最新的流行病。作为一个渗透者，如果你知道如何利用它，你的荣誉就得到了保证。

BOLA参考信息：https://medium.com/@inonst/a-deep-dive-on-the-most-critical-api-vulnerability-bola-1342224ec3f2

看了一下BOLA，打算写一篇文章来介绍一下，后面放文章链接。

tip4:

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

更多的参考函数文档： https://apidock.com/ruby/Kernel/open

tip5:

寻找SSRF? 使用它来

• 内部端口扫描

• 利用云服务

• 使用http://webhook.site 网站来反查IP地址和HTTP库

• 下载大的文件(7层 DOS)

• 反射SSRF,本地管理平台泄露

tip6:

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

更多的了解批量赋值：

一文带你了解 Laravel 中的 Mass-Assignment (批量赋值)

tip7:

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

tip8:

在进行测试REST API时，我们也应该检查一下API是否也支持SOAP。将content-type更改为“application/xml”，在请求主体中添加一个简单的xml，并查看API如何处理它。

有时身份验证是在不同的组件中完成的。可能是在REST和SOAP API之间共享的，所以SOAP API可能支持JWT。如果API返回带有DUMPling的stack trace，那么它很可能是存在漏洞的。

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

其实这些API端口是很好猜的，而且设计规范的API 也应该这样设计。

一个规范的设计：

https://api.example.com/v1/users/<id>

可以替换版本，二级目录，id ，包括方法等等，这都是可以用遍历工具来找出来的。

tip11:

检查API 是否使用授权头？忘了 CSRF 吧！如果身份验证机制不支持 cookie，则这个 API 就被设计为了防止 CSRF 的攻击。

tip12:

对 BOLA (IDOR)的测试？即使ID是GUID或非数字类型的值，渗透测试人员也要尝试发送一个数字值。

例如: / ?user_id=111 使用 user_id=inon@traceable.ai 代替

有时身份认证机制同时支持这两种方式，而且暴力破解数字更容易。

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)*

比如 上面的重设密码需要旧密码，但是更新用户的API 就不需要发送旧密码

tip14:

在API测试期间卡住了?

扩大你的攻击面!

查找同级域名或者子域名 使用http://Virustotal.com和http://Censys.io。其中一些域可能使用不同的配置/版本公开相同的api。

tip15:

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

tip16:

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

tip17:

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

tip18:

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

如 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)

上面的都容易被攻击吧，最容易的就是有权限访问的。像组织用户管理，子用户创建和管理。

对象共享，也有权限问题，输出CSV/HTML/PDF 这个功能可能比前面的要好一点。

tip20:

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

更多的例子： WHY FACEBOOK HACKERS ARE A REAL THREAT AND HOW TO PROTECT YOURSELF

这个例子也会写一篇文章，链接后面发。

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

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?

例子：

{"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)，看看会发生什么.