【API渗透测试】第二步：攻击
2023-11-26 19:38:41 0 举报AI智能生成
API渗透测试脑图，全方位、全流程的分析API接口如何进行信息收集、如何发现接口风险和如何实施攻击方式，帮你快速梳理出API场景下的风险。
作者其他创作
大纲/内容
缺乏资源和速率限制
OTP 功能
Login 功能
CVV / PIN认证
绕过
内部资源欺骗
Referer 操控
IP Range 欺骗
……
功能级别授权损坏
管理员功能
API 方法
e.g:
/api/v1/admin/delete?resource_id=
/api/v1/admin/update?resource_id=
/api/v1/admin/post?resource_id=
HTTP 请求方式
DELETE
PATCH
PUT
……
……
授权不当
匿名用户访问功能需要经过身份验证的用户
匿名用户访问功能检索经过身份验证的用户数据
……
操控请求方式和功能点
例如:
/api/v1/users/info?uID=1
/api/v1/admin/users/info?uID=1
/api/v1/users/info?uID=1
/api/v1/admin/users/info?uID=1
例如:
/api/v1/users/?id=myID
/api/v1/users/all
/api/v1/users/?id=myID
/api/v1/users/all
利用已有功能可能访问内部功能
例如:
/api/v1/Ajax/resource?url=/end/point
/api/v1/Ajax/resource?url=../..//etc/passwd
/api/v1/Ajax/resource?url=/end/point
/api/v1/Ajax/resource?url=../..//etc/passwd
例如:
/api/v1/Ajax/resource?url=/end/point
/api/v1/Ajax/resource?url=http://127.0.0.1
/api/v1/Ajax/resource?url=/end/point
/api/v1/Ajax/resource?url=http://127.0.0.1
通过功能点执行内部资源
例如:
/api/v1/Ajax/PUT?url=/user/profile/pic
/api/v1/Ajax/PUT?url=http://127.0.0.1/shell.ext
/api/v1/Ajax/PUT?url=/user/profile/pic
/api/v1/Ajax/PUT?url=http://127.0.0.1/shell.ext
……
资产管理不当
使用在大多数情况下不受保护的非生产资源来攻击生产资源
公开可访问的其他环境产品功能
env
test
example
branches
old releases
……
自动启用某些框架的默认端点
例如: springboot
heapdump
dump
……
批量处理
金融攻击
价格操纵
金额操纵
货币操控
……
特权攻击
权限提升
例如：{“is_admin”：true}
例如：{“is_admin”：true}
删除资源
操纵资源
……
绕过限制
email 验证
例如: {"verified":true}
默认密码启用
例如: {"default_pass":true}
……
对象级访问破坏
检查每个功能有什么
用户标识符
参数值
URL对象
可下载资源
PDFs
Docs
Invoices
……
个人信息
国家身份证
护照
……
事务对象/标识符
Usernames
参数中的值
作为 URL 中的对象
可下载资源
凭证
licenses
医学文件
…… （基于应用的逻辑设计）
应用程序的验证器
认证headers / cookies
检查：
哈希会话/cookie
序列化会话/cookie
编码会话/cookie
加密cookie
应用程序的响应
动态的应用程序响应
认证前
资源访问行为
操控
从服务器的响应中操控权限或用户状态
一些开发人员定义了用户根据服务器的响应来确定访问资源时权限，如：
{
"authorized":true,
"uID": 122
}
{
"authorized":true,
"uID": 122
}
2FA 访问特定用户内容
OTP
脆弱点
OTP 存储在某个接口中
由 API 使用某种方法生成
可操控
将值从 true 更改为 false 或者是逻辑代表。例如：{“OTP”：1}，这里的数字 1 指的是 true
远程授权
可操控
在访问应用程序中的特定敏感、关键资源时，某些应用程序需要远程授权才能继续
有些应用需要远程授权，例如移动应用程序，因此我们可以操纵响应绕过用户的内容
例如：
{
"authorization_done":true,
"resource_id": 120
}
例如：
{
"authorization_done":true,
"resource_id": 120
}
etc
已认证
标识符的操控
email
username
id
机密信息/个人信息
身份证ID
电话号码
护照ID
……
二维码攻击
预生成攻击
可欺骗的标识符
逐步识别
数字标识符
e.g: /api/v1/users/getToken/12
e.g: /api/v1/users/getToken/13
字母+数字标识符
1. e.g: /api/v1/users/getToken/username12
2. e.g /api/v1/users/getToken/username13
动态攻击
实时应用
基于响应内容
后端更改的值将用于稍后生成二维码以检索数据。
例如：
{
"username":"someUser",
"user_id":12,
"action":"getToken"
}
例如：
{
"username":"someUser",
"user_id":12,
"action":"getToken"
}
后端更改的值将用于稍后生成二维码以执行操作。
例如：{
"username":"someUser",
"user_id":12,
"action":"loginAuthorize"
}
例如：{
"username":"someUser",
"user_id":12,
"action":"loginAuthorize"
}
……
……
用户身份验证被破坏
身份验证安全性薄弱设计
验证码攻击
验证码重用
验证码太弱
验证码未生效
未授权访问验证码生成接口
获取验证码间隔时间太短
导致爆破攻击
脆弱的凭证
凭证填充
公共数据库泄露
目标有暴露在公开情报的凭据
默认凭证
默认高权限凭证
admin:admin
administrator:administrator
root:toor
……
默认低权限、自定义权限账号
guest:guest
test:test
user:user
……
不安全的方式传输敏感数据
通过GET Request / URLs传输数据
加密机制薄弱
加密秘钥较弱
明文传递数据
实施不安全的认证逻辑
Response可操控
操纵服务器的响应以绕过动态应用中的身份验证机制
API Keys 攻击
脆弱的API keys
使用较弱的 API Keys
不当的API接口跳转
基于Token的攻击
Access token 攻击
访问令牌验证不当
使用低权限访问令牌执行高权限功能
使用攻击者的访问令牌访问其他用户的内容/数据
……
JWT攻击
脆弱的secret
缺乏 JWT 验证（可接受任何令牌）
弱算法
例如： None 算法
签名绕过
例如：kid注入+SQL注入
……
针对时间攻击
不会过期的JWTs, access tokens and sessions
攻击各种认证系统
身份验证系统因应用程序而异，因此没有标准方法可以破解它们，这取决于您的创造力
过多的数据暴露
先分析其构造
例如: /api/clients/show?id=13
利用系统的检索功能
e.g: /api/{orders}/show?order_id=202
通讯功能
评论功能
消息功能
通知功能
……
日志功能
……
安全措施配置错误
CORS 配置错误
堆栈跟踪
例如: ASP.NET 堆栈跟踪
老旧版本的系统
暴露的存储或服务器管理面板
例如: S3 Buckets
……
注入
SQL 注入
NoSQL 注入
LDAP 注入
OS Command 注入
XML 注入
……
0 条评论
下一页
