若API形式为: /api/v3/login
,那么可尝试 /api/v2/login
, /api/v1/login
等。
若API形式为: /api/mobile/login
,那么可尝试 /api/phone/login
, /api/wx/login
等,再比如 download_receipt
, export_receipt
等。
比如如下JSON Response
{"user_id":233,"nickname":"w2n1ck","phone":"15566668888"}
那么可尝试:
GET /api/user/{user_id} //查询用户GET /api/user/{orther_user_id} //查询其他用户POST /api/user/{user_id} //修改用户信息PUT /api/user/{user_id} //修改用户信息POST /api/user //创建新用户DELETE /api/user/{user_id} //删除用户
在Ruby on Rails App的情况下,如果开发人员使用了 Kernel#open
函数的话,使用 |
管道符测试命令注入。
比如更新某功能时
PUT /api/videos/233
{"name":"my_video","format":"mp4"}
但是在其他接口可能会有该对象的其他属性
GET /api/my_videos
{[{"id":233,"file_name":"my_video.mp4","path":"/my_video/path/"}]}
尝试添加隐藏属性
PUT /api/videos/233
{"name":"my_video","format":"mp4","path":"/my_video/path/../../evil/path"}
若web端限制较严格,可以尝试在app端测试。
对于Rest API可以修改 Content-Type
为 application/xml
,并在body中添加xml代码,看是否会有错误产生。
http body/header
中的参数比url中的参数更容易受到攻击。
如果API使用JWT验证,那么CSRF就无法利用了。
即使id是UUID或其他非数字字符串,也要尝试发送一个数字值,比如使用 /user/detail?userId=1
替换 /user/detail?userId=616d6bad-536e-44bb-9bf5-05042c9bffe8
。
如果不同业务功能被分配到了不同的集群机器上,那么可能导致绕过。
# 修改密码为例POST /api/reset_pass //需要旧密码PUT /api/update_user //添加reset_pass中的参数可能直接就修改密码了
不同子域名可能使用同一套API,可尝试在其他子域名测试。比如 admin.w2n1ck.com
,可尝试 admin-api.w2n1ck.com
, admin-api-v1.w2n1ck.com
等。
由于大部分系统对静态资源的处理方式不同,所以静态资源很容易出现越权等问题。
如果最新的APP无法找到突破口,可尝试下载旧版的客户端程序。
开发者可能对比较重要的接口做的防护更加完善,多留意一些不重要的API。
开发者对于一些重要接口可能会做一些频次等限制,但是非生产环境可能就没这些限制措施。
前端js、webpack可能包含了大量API接口及参数。
若通过某种途径获取到dll,jar,rar等源码,可通过反编辑等手段,阅读源码在源码中找API。
若API存在导出功能,比如导出PDF,可尝试注入特定的HTML代码。
# 数组{"id":111} --> {"id":[111]}# Json{"id":111} --> {"id":{"id":111}}# 参数污染id=111&id=222# 通配符{"id":"*"}
如果响应包是 Content-type:application/json
,就不要考虑XSS攻击了。
.net
应用可能会使用 Path.Combine(path_1,path_2)
来组合参数,将两者连接起来得到一个完整的路径。web 应用程序的上下文中,第一个参数通常是指向图像或用户文档存储位置的绝对目录路径, 第二个参数通常是用户控制的,那么在某种程度上,如果参数path2是绝对路径,则忽略参数path1。
https://github.com/smodnix/31-days-of-API-Security-Tips/blob/master/README.md
https://apidock.com/ruby/Kernel/open
https://www.praetorian.com/blog/pathcombine-security-issues-in-aspnet-applications
https://medium.com/@inonst/a-deep-dive-on-the-most-critical-api-vulnerability-bola-1342224ec3f2