API安全测试31个Tips(一)
最近研究了一下API安全，有一个叫Inon Shkedy的同学整理了自己在API安全测试中的31个tips。我觉得质量不错，翻译了一下，再加上了一些自己的理解，会分成3篇发出来。
最近研究了一下API安全，有一个叫Inon Shkedy的同学整理了自己在API安全测试中的31个tips。我觉得质量不错，翻译了一下，再加上了一些自己的理解，会分成3篇发出来。
项目：31-days-of-API-Security-Tips
地址：
https://github.com/inonshk/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-10等等，还有存在一些v2.1 这种小版本的可能。
http://api.example.com/v2.1/login
tip2:
永远不要认为只有一种方法，用来验证API的身份。现代的应用程序有很多API接口用于认证:
/api/mobile/login
- ```
/api/v3/login/api/magic_link
等等。找出他们并测试所有的授权认证问题。
认证的接口确实很多，可以分为不同的应用，不同的平台，不同的版本等等。
这种是需要去做侦查，比如发现一些二级域名，再加上login之类的接口，或者公司的一些其他接口也是可以登录，这个在官方文档上可能有发现。
OAuth的认证机制，需要学习一下。很多大公司的OAuth的接口如下：
在线服务接口端点RFC 6749/tokenTwitter/oauth2/tokenDropbox/oauth2/authorizeFacebook/oauth/access_tokenGoogle/o/oauth/tokenGithub/login/oauth/access_tokeninstagram/oauth/authorizetumblr/oauth/token
做认证的时候，公开API 一般为：
https://api.example.com/v1/oauth2/token
## **tip3:**
**
**
还记得5-10年前SQL注入是多么常见么？你几乎可以进入任意一家公司。BOLA(IDOR)是API安全最新的流行病。作为一个渗透测试人员，如果你知道如何利用它，你的荣誉就得到了保证。
BOLA参考信息：
https://medium.com/@inonst/a-deep-dive-on-the-most-critical-api-vulnerability-bola-1342224ec3f2
## **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端口即可。
## **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的漏洞?
HTTP bodles/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>
可以替换URI中的版本，二级目录，id ，还包括请求方法等等。这都是可以用遍历工具来验证的。