速率限制难以实施 从本质上说 , GraphQL API是比较复杂的 。 它的每一个查询都会涉及到多项操作 , 并且会消耗大量的服务器资源 。 因此 , 光靠限制接收到的HTTP请求数量 , 并使用默认的速率限制策略是不够的 。 如果两种对象类型之间存在着某种循环关系 , 那么攻击者就可以通过创建各种滥用查询(abusive queries) , 从而让查询本身变得异常复杂 。 以此产生的编排 , 能够对GraphQL应用发起拒绝服务式(DoS)的攻击 。
常见的GraphQL漏洞 下面 , 我们来进一步讨论GraphQL有哪些常见的漏洞 , 可被恶意攻击者在API层面利用 。
GraphQL批处理攻击
GraphQL框架能够支持自省查询的批处理 , 即:能够在一次性调用中 , 向后端API发送多个请求 。 由于减少了请求与服务器之间的往返次数 , 因此这对于减少API请求的开销非常实用 。 不过 , 攻击者也可以使用查询的批处理功能 , 通过反复从API服务器、或数据库处加载数据 , 来编排各种快速且难以被检测到的暴力攻击 。
以下典型示例展示了 , 在搜索数字记录对象标识(Digital Record Object Identification , DROID)对象的不同实例时 , 进行GraphQL批处理查询的代码:
- query {
- droid(id: "2000"){
- name
- }
- second:droid(id: "2001"){
- name
- }
- third:droid(id: "2002"){
- name
- }
- }
GraphQL注入攻击
GraphQL API通常与作为数据源的数据库管理系统相连接 。 API后端的Resolver在收到请求后 , 会根据操作集来区分查询 。 在Resolver查询数据库时 , 如果其操作涉及到数据的提取 , 那么就会直接执行相应的获取操作 。 可见 , 如果来自API客户端的数据 , 在未被适当清理的情况下 , 执行任何受信的操作 , 那么黑客就可以通过编排SQL/NoSQL , 来实施注入攻击 。 同样 , 如果对输入的清理不够充分 , 攻击者还会执行诸如LDAP注入、以及命令注入等其他形式的注入攻击 。
GraphQL CSRF攻击
跨站请求伪造(CSRF)攻击是指 , 在合法用户不知情时 , 强迫Web服务器运行那些不必要的操作 。 当存在CSRF漏洞时 , 攻击者会在当前登录用户的上下文 , 发送经过身份验证的请求 。 而GraphQL类型的应用极易受到CSRF攻击 , 毕竟API在接收浏览器的请求时 , 会自动接受所有的cookie(其中就包括了会话cookie) 。
目前 , 主要有两种类型的GraphQL CSRF攻击:基于Post和基于Get的CSRF 。 由于GraphQL使用多个API层来转换传入的多格式请求 , 而且能够影响到GraphQL应用的状态 , 因此大多数CSRF攻击通常以POST请求为目标 。 通常 , 许多开发人员会只接受设置为application/json的Content-Type标头 。 例如 , 以下POST请求可用于发出有效的GraphQL查询:
- POST /GraphQLHTTP/1.1
- Host: redacted
- Connection: close
- Content-Length: 100
- accept: */*
- User-Agent: ...
- content-type: application/json
- Referer: https://redacted/
- Accept-Encoding: gzip, deflate
- Accept-Language: en-US,en;q=0.9
- Cookie: ...
- {"operationName":null,"variables":{},"query":"{\n user {\n firstName\n __typename\n }\n}\n"}
- POST /GraphQLHTTP/1.1
- Host: redacted
- Connection: close
- Content-Length: 72
- accept: */*
- User-Agent: Mozilla/5.0(Macintosh; Intel Mac OS X 11_2_2)AppleWebKit/537.36(KHTML, like Gecko)Chrome/89.0.4389.82 Safari/537.36
特别声明:本站内容均来自网友提供或互联网,仅供参考,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系,我们将在24小时内删除。
