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漏洞
- 内部端口探查
- 利用云服务
- 使用http://webhook.com显示IP地址和HTTP库
- 下载大文件(7层DDOS)
- 反射SSRF,本地管理平台泄露
TIP6
批量赋值是真实存在的。现代框架鼓励开发人员在不了解安全性影响的情况下使用批量赋值。在使用过程中,不要猜测对象的属性名,只需找到一个返回所有属性的GET端点。
TIP7
一家公司向开发者公开了API接口,且在移动端和web端使用了相同的API程序。我们需要分开测试它们,不要假设它们实现了相同的安全机制。
TIP8
在测试api的时候,虽然REST API是当前最常见API形式,但是我们也还检查一下API是否也支持SOAP。将content-type更改为“application/xml”,在请求主体中添加一个简单的xml,并查看API如何处理它。
代码语言:txt复制有时身份验证是在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),看看会发生什么.