字符串输入参数的 SSRF CheckMarx 漏洞答案

【问题标题】：SSRF CheckMarx Vulnerability for String input parameter字符串输入参数的 SSRF CheckMarx 漏洞
【发布时间】：2017-06-20 11:59:06
【问题描述】：

我正在为我的一个项目运行 CheckMarx 扫描，它带有一个方法的输入字符串参数之一的 SSRF 漏洞。我的方法如下所示，参数 param1 会引发 SSRF 漏洞。

public String method1(@WebParam(name = "param1") final String param1) {
    LOG.info("Inside method1...")
    if (StringUtils.isBlank(param1) || !StringUtils.isAlphanumeric(param1)) {
        throw new DataManipulationException();
    }
    // Call 3rd party here (method in line 87 below)
}

在方法内部，我使用 HttpClient GetMethod 调用第 3 方 URL，param1 作为查询字符串参数传递。

来自 CheckMarx 的 SSRF 是：

The application sends a request to a remote server, for some resource, using @DestinationElement in \src\com\test\Test.java:87. However, an attacker can control the target of the request, by sending a URL or other data in param1 at \src\com\test\Test.java:55.

在第 55 行，我有

public String method1(@WebParam(name = "param1") final String param1) {

在第 87 行我有

private String processRequest(final GetMethod method) throws IOException {

感谢您提供解决此 SSRF 漏洞的任何帮助。谢谢。

【问题讨论】：

所以？你的问题是什么？或者你只是在吹牛：D。此外，您的问题缺少大部分相关代码......无论如何，我确信 Checkmarx 报告也有解释和建议？
我的问题是如何修复这个 SSRF 漏洞
对于字符串请求，我认为这将是best solution。

标签： java checkmarx ssrf

【解决方案1】：

为了确认SSRF漏洞，还需要processRequest方法的代码sn-p。据我了解，CheckMarx 将问题报告为“param1”应包含第三方 URL，并且该应用程序正在使用该 URL。降低 SSRF 风险可能有以下几种方法：

是否需要第三方库来执行功能？如果否，那么您可以安全地删除该代码。
如果您需要第三方并且 URL 保持不变，那么您可以对该 URL 进行硬编码。
如果您无法进行硬编码并且它不断变化，那么您能否列出可能的第三方 URL？必须手动审查所有可能的第三方 URL 并执行白名单以允许所需的 URL。或者所有可能的 URL 都应该插入到后端的文件/数据库中，并且用户可以传递该特定 URL 的 ID。
如果 URL 每次都在变化，而且没有办法加入白名单，你应该阻止这种不会进一步损害应用程序的方法。在这种情况下，需要方法的 sn-p 代码，并且应正确审查方法。

【讨论】：