java - 如何使用 Spring Boot 防止危险 Controller 包含在生产配置文件中？

Question

tl;博士如何根据 Spring 配置文件排除某个类包含在 bootJar 生成的 jar 文件中？

<小时/>

我会故意含糊其辞，但会尽力提供尽可能多的信息。

我有一个 C# .NET Web API(基于 HTTP/1.1 的 JSON)。此 API 从第三方接收加密的有效负载。该第三方有一个为 Java 编写的库，但不是为 C# 编写的。由于时间限制和其他因素，我们决定使用 Spring Boot 建立 Java API 并调用该 API，而不是自己实现他们的库，这样会更快。

流程是

1. 将加密的负载发送到 C# API
2. (C#) 将加密的负载发送到 Java API
3. (Java) 解密加密的有效负载
4. (Java) 使用第三方库进行数据转换/验证
5. (Java) 重新加密负载
6. (Java) 将加密的负载返回到 C# API
7. (C#) 发送给不同的第三方

我们有一套目前用 C# 编写的自动化集成测试。

我们需要确保，给定有效的有效负载，当它发送到 C# API 时，有效负载会转发到 Java API，正确解密，正确转换，并为其他三分之一正确重新加密-要处理的派对。

为了促进这一点，我在 Java API 上创建了一个新的 Controller ，它接收明文有效负载，对其进行加密(就像第三方那样)并将其返回给调用者。然后，调用者可以将该加密的有效负载发送到 Java API 上的不同 Controller 来执行解密+验证，并将重新加密的有效负载发送回调用者。

Java API 信任这些自动化创建的有效负载。 Java API 在运行时生成一个新的 key 对，当它收到明文有效负载时，它使用运行时生成的私钥对其进行签名，并信任使用运行时生成的公钥签名的消息。

我现在遇到的问题是，我不希望在生产中使用此功能。这些有效负载的内容对于不良行为者来说过于敏感，无法操纵。 p>

我通过向 Controller 添加 @Profile("test") 属性解决了部分问题。这允许我在运行时配置它，例如

java -jar sensitive-app.jar --spring.profiles.active=production

这样，在运行时，sp​​ring 会阻止 Controller 工作

{
    "timestamp": "2018-03-16T23:20:00.781+0000",
    "status": 404,
    "error": "Not Found",
    "message": "No message available",
    "path": "/dangerous-endpoint"
}

但是，我明白没有什么是无法破解的。我想尽可能确保这不会被任何进入该盒子的不良行为者所攻击；或者换句话说，即使攻击者可以访问该框，并启动应用程序

java -jar sensitive-app.jar --spring.profiles.active=test

Controller 仍然无法正常工作。

我正在使用 spring-boot gradle 插件构建这个 jar。

我能想到的唯一方法是首先阻止 Controller 包含在 jar 中。

我尝试将其添加到我的构建脚本中

bootJar {
    exclude('sensitive/dangerous/**')
}

但我看到类文件仍然包含在 jar 中。

然后我想知道是否有某种方法可以让 spring 插件根据属性智能地包含或排除文件，例如

gradlew clean build bootJar -Dspring.build.profile=production

但找不到任何东西。

我还尝试在源集中排除该文件

sourceSets {
    main {
        java {
            if (project.environment == 'prod') {
                exclude '**/dangerous/**'
            }
        }
    }
}

但是类文件仍然位于 jar 文件中(在 BOOT-INF/classes 文件夹下)

注意:此 Controller 需要在所有非生产环境中可用，因此不能完全阻止编译此文件。

如何排除某个类包含在 bootJar 生成的 jar 文件中？或者有没有一种方法可以告诉 gradle 构建将包含在 Spring 配置文件中的文件？

Answer 1

我会采取不同的策略。

我会编写危险的 Controller ，以便它在 JVM 环境中查找非常具体的内容(例如自定义系统属性或环境变量)。

• 让 Controller 测试变量，如果检测到该变量正在生产中使用，则抛出异常。失败得大声，而且要早!可能将其放入静态初始化程序中，以便在加载/连接 Controller 时发生故障。

• 安排属性/变量/任何内容的设置方式不会被您选择的构建/部署方法意外复制到生产环境。 (有多种方法可以做到这一点……但是您故意对上下文含糊其辞，这使得很难提出合适的方法。)

这种方法的优点是它不会受到构建脚本的干扰。但建议也通过构建脚本排除 Controller 。 (腰带和背带...)