DevOps 管道中的安全性

在软件开发和 DevOps 流程（从设计到部署）中，安全必须放在首位。如果事后才想到这一点，安全事件就会反咬一口。

在本篇文章中，我们将讨论 GraphQL API 开发人员经常犯下的一个重要疏忽--在生产环境中启用自省功能。在开发阶段，自省是了解和测试 API 功能的绝佳功能。但是，如果不在上线前禁用它，就会使您的应用程序面临重大漏洞。我们将讨论这种情况如何升级为重大安全风险，以及您可以采取哪些预防措施来加强 DevOps 管道的安全性。

场景

想象一下，一个开发团队正在带头实施其组织的 GraphQL API。GraphQL 是一种功能强大的查询语言，旨在让客户在一次查询中就能准确请求所需内容。这与传统的 REST API 不同，后者可能需要多次请求才能拼凑出复杂的数据和关系。GraphQL 中的数据结构是在模式中定义的，模式概述了可用的数据类型、查询和突变。

开发团队付出了巨大的努力，开发出了令人印象深刻的产品。这个 API 不仅功能强大，而且还能扩展，每分钟能处理数百万笔交易，这一切都要归功于团队设计和构建的自动扩展功能。他们专注于性能和可扩展性，确保该 API 能够处理巨大的负载而不会出现任何问题。

然而，在他们急于部署这个闪亮的新 GraphQL API 并给人留下深刻印象的过程中，他们忽略了一个小细节--生产环境中仍然启用了自省功能。自省对于开发人员来说是一个强大的工具，它为开发人员提供了一种查询 API 中可用资源的方法。但这并不应该在生产环境中开放。

后果是什么？

随着应用程序接口的扩展以满足需求，每个新实例都会使潜在风险成倍增加。现在，重大的安全漏洞已经扩散到越来越多的节点上。这样，我们就为坏人的潜在利用创造了条件。他们拥有了发现有关这个闪亮的新 API 的结构和功能的详细信息所需的一切。

由于忘记了一个简单的切换键，该团队将一个用心良苦的功能变成了一个漏洞百出的安全漏洞。

了解脆弱性

启用自省功能后，开发人员可以查询 GraphQL API，查看完整的模式--包括所有数据类型、字段、查询和突变。这就像拥有一张 API 的所有操作端点和数据结构的详细地图。对于开发人员来说，这是一个很好的资源。但你可不想让网络攻击者掌握这种资源。

考虑一下攻击者如何利用自省功能来了解你的 GraphQL API。首先，他们可以定义片段，使查询结果更便于阅读。

fragment FullType on __Type {     kind     name     description     fields(includeDeprecated: true) {       name       description       args {         ...InputValue       }       type {         ...TypeRef       }       isDeprecated       deprecationReason     }     inputFields {       ...InputValue     }     interfaces {       ...TypeRef     }     enumValues(includeDeprecated: true) {       name       description       isDeprecated       deprecationReason     }     possibleTypes {       ...TypeRef     }   }   fragment InputValue on __InputValue {     name     description     type { ...TypeRef }     defaultValue   }   fragment TypeRef on __Type {     kind     name     ofType {       kind       name       ofType {         kind         name         ofType {           kind           name           ofType {             kind             name             ofType {               kind               name               ofType {                 kind                 name                 ofType {                   kind                   name                 }               }             }           }         }       }     }   }

然后，他们可以发送查询，以反省 __schema 字段，该字段在查询的根类型中可用。GraphQL 查询可能是这样的

{   __schema {     queryType {       name     }     mutationType {       name     }     subscriptionType {       name     }     types {       ...FullType     }     directives {       name       description       locations       args {         ...InputValue       }     }   } }

通过向启用了自省功能的 GraphQL API 发送该查询和片段定义，攻击者将收到一个包含所有 API 详细信息的综合 JSON 对象的响应。然后，他们就可以使用GraphQL Voyager等工具将 GraphQL API 显示为交互式图形。

下面是一个基于上述自省查询响应的 GraphQL API 可视化示例：

如您所见，这揭示了与敏感支付操作相关的大量结构和细节。这对于试图渗透 API 的攻击者来说是非常有用的信息。同样，这对开发人员来说是个好消息，但不幸的是，对攻击者来说也是个好消息。

在生产中启用自省功能时，会面临以下风险：

• 暴露信息：详细的模式信息可以让攻击者深入了解您的后端系统、数据模型和业务逻辑。将城堡的蓝图交给他们，就能让他们轻而易举地策划有针对性的攻击。
• 为攻击提供便利：有了这些关于 API 的详细信息，攻击者就可以创建利用漏洞的查询。这可能会导致数据泄露或服务中断。
• 资源消耗：攻击者还可以利用这些知识制作恶意查询，作为拒绝服务（DoS）攻击。这些攻击会耗尽资源，并可能导致系统完全瘫痪。

但不要绝望！降低这种风险的步骤简单明了。作为保护自己的第一步，让我们看看 OWASP 是怎么说的。

来自 OWASP GraphQL Cheat Sheet 的指导

OWASP GraphQL Cheat Sheet是保护 GraphQL API 安全的宝贵资源。它为您提供以下方面的指导：

• 验证输入
• 限制或防止昂贵的查询
• 确保适当的访问控制检查
• 禁用不安全配置，如反省

小抄中有一节专门介绍自省和 GraphiQL。GraphiQL是用于探索 GraphQL 的浏览器内集成开发环境。与自省功能类似，GraphiQL 可以揭示有关 API 内部运作和设计的详细信息。

如果您正在构建 GraphQL API，我们建议您熟悉 OWASP 小抄。

如何缓解 Introspection 安全漏洞

根据 OWASP 小抄的提示，我们将听从其指示，在生产环境或可公开访问的环境中禁用自省查询。这对于防止未经授权访问可能被攻击者利用的详细模式信息至关重要。

我们如何做到这一点？

下面是一个简单的 JavaScript 代码片段，演示了如果使用Apollo Server，如何在生产中关闭自省功能：

const { ApolloServer } = require('apollo-server'); const server = new ApolloServer({   typeDefs,   resolvers,  // Enable introspection only in development or test environments   introspection: process.env.NODE_ENV === 'development' ||                 process.env.NODE_ENV === 'test', }); server.listen().then(({ url }) => {   console.log(`Server ready at ${url}`); });

是的，基本上就是这样。这个简单的步骤（设置 introspection 至 false 配置新的 ApolloServer)将阻止用户通过自省查询访问详细的模式信息。这将降低泄漏敏感信息的风险。

使其成为安全 DevOps 管道的一部分

如果这个步骤如此简单，为什么开发人员经常忘记呢？因为他们专注于其他事情，忙于赶工期。偶尔忽略一些看似次要的配置设置也就不足为奇了。

这就是为什么我们有自动化测试和 DevOps 管道，以防止人为错误和遗忘。

如何将这一安全措施集成到 DevOps 流程中？这里有两个建议：

• 编写一个部署前测试，明确检查 GraphQL 服务器配置，确保在生产部署时禁用自省功能。
• 编写一个部署后测试，尝试对生产环境进行自省查询。当您的尝试遇到错误响应（如 Cannot query field '__schema' on type 'Query')，那么测试就会通过。

利用Jenkins、GitHub Actions 或 CircleCI 等 CI/CD 管道工具来运行脚本，在 CI/CD 过程中检查 GraphQL API 设置。

总结

构建 GraphQL API 是公司进行创新的绝佳方式，但这需要您积极主动地采取安全措施。一个小小的疏忽就可能让您的 API 面临巨大的漏洞。在本篇文章中，我们介绍了这方面的一个典型例子：在生产部署中禁用自省功能，这样攻击者就无法获得 GraphQL 架构的详细信息。

有关进一步的指导和资源，请查看 Linode 有关安全、GraphQL 开发和https://www.linode.com/docs/guides/platform/ 的综合指南库。