Send RxFill to EHR only after NCPDP REMS interactions.

[plarocque4]

Describe your changes

Send RxFill to EHR only after NCPDP REMS interactions.
This has corresponding Pull Requests in rems-intermediary, request-generator, test-ehr.

Issue ticket number and Jira link

869

Checklist before requesting a review

• I have performed a self-review of my code
• Ensure the target / base branch for any feature PR is set to dev not main (the only exception to this is releases from dev and hotfix branches)

Checklist for conducting a review

• Review the code changes and make sure they all make sense and are necessary.
• Pull the PR branch locally and test by running through workflow and making sure everything works as it is supposed to.

Workflow

Owner of the Pull Request will be responsible for merge after all requirements are met, including approval from at least one reviewer. Additional changes made after a review will dismiss any approvals and require re-review of the additional updates. Auto merging can be enabled below if additional changes are likely not to be needed. The bot will auto assign reviewers to your Pull Request for you.

In general, the problem is fixed by introducing a rate-limiting middleware for routes that perform expensive operations (database / network calls). In an Express app, the typical solution is to use a well-known middleware like express-rate-limit, configure sensible limits (e.g., max requests per IP per time window), and apply it either globally to the router or to specific sensitive routes.

For this file, the least intrusive, most effective fix is to import express-rate-limit, define a limiter tailored for doctor order update operations, and apply it specifically to the /api/updateRx/:id PATCH route (and optionally similar DB-heavy routes if desired). This avoids changing any existing functionality of the handler itself while satisfying the requirement that the route be rate-limited. Concretely:

• Add import rateLimit from 'express-rate-limit'; near the top of backend/src/routes/doctorOrders.js without altering existing imports.
• Define a limiter constant, e.g., const updateRxLimiter = rateLimit({ windowMs: 15 * 60 * 1000, max: 100 }); after the router/middleware setup.
• Change the route declaration from router.patch('/api/updateRx/:id', async (req, res) => { ... }) to router.patch('/api/updateRx/:id', updateRxLimiter, async (req, res) => { ... }), so each client IP can only hit this endpoint a bounded number of times per window.
  This single limiter on the route will cover all three database accesses within the handler because the middleware runs before the handler executes.

Generally, to fix this kind of SSRF risk you must ensure that any configuration affecting outbound URLs cannot be set to arbitrary values by untrusted input. This can be done by (a) validating user-provided configuration against strict rules (e.g., allow only https, disallow private IPs/hosts, optional allow-list) and/or (b) preventing certain sensitive fields (like endpoint base URLs) from being set via user-facing APIs at all.

For this codebase, the least intrusive, functionality-preserving fix is to harden updateConfig in backend/src/lib/pharmacyConfig.js so that only a controlled subset of fields can be updated, and only with safe values. Specifically:

• Define a small allow-list of configurable keys; for example, allow boolean useIntermediary but block arbitrary updates to URL fields from req.body.
• Optionally add format validation for any URL fields you really do need to update at runtime (e.g., require https:// and a host that is not localhost or a private IP). Because we can’t assume other project parts, the safest is to block URL changes from the API completely and rely on environment variables for these.
• Implement this by having updateConfig construct a sanitized safeConfig from newConfig, copying only allowed keys, and ignoring the rest.

Concretely:

• Edit backend/src/lib/pharmacyConfig.js, lines 17–21, to:
  • Introduce a list of allowed keys (e.g., only useIntermediary).
  • Build a sanitizedConfig object with only those keys and with minimal type coercion (e.g., convert "true"/"false" strings to booleans).
  • Merge sanitizedConfig into config instead of merging newConfig directly.
• Leave doctorOrders.js’s sendRxFill function unchanged; it still calls getRxFillEndpoint(), but now that endpoint can no longer be redirected arbitrarily by untrusted configuration updates.

This preserves existing behavior for safe fields (like toggling useIntermediary via the API) while preventing a user from changing intermediaryUrl, remsAdminUrl, or ehrUrl to arbitrary attacker-controlled hosts.

In general, to fix SSRF caused by user‑controlled configuration, you must prevent untrusted clients from setting arbitrary URLs used in outbound HTTP calls. That can be done by: (1) restricting which configuration fields can be updated at runtime, (2) validating URL fields carefully (scheme, host allow‑list, no localhost/metadata IPs, etc.), or (3) removing dynamic configuration of such URLs entirely and sourcing them only from trusted environment variables or static config.

The best minimal fix here, without changing intended functionality, is to validate and sanitize the newConfig object in updateConfig before merging it into config. Specifically: ensure useIntermediary is just a boolean; for each URL field (intermediaryUrl, remsAdminUrl, ehrUrl) either ignore updates from the client or strictly validate them so they cannot point to internal/loopback/metadata addresses, and require http or https scheme and a normal hostname. To keep behavior flexible but safe, we can: (a) only allow updates to a small subset of fields from /api/config; and (b) for URLs, parse them with Node’s standard URL class, reject invalid URLs or ones with disallowed hosts, and possibly restrict host to an allow‑list pattern (e.g., only specific domains). Since we must not assume external code, we will implement a small internal validator in backend/src/lib/pharmacyConfig.js and call it inside updateConfig to produce a sanitized merged config object.

Concretely:

• In backend/src/lib/pharmacyConfig.js, add a helper like sanitizeConfigUpdate(newConfig) that:
  • Creates a copy of the existing config.
  • If newConfig.useIntermediary is present, coerces it to a boolean if it’s "true"/"false" or a boolean.
  • Option A (safest and simplest): completely ignore client updates to intermediaryUrl, remsAdminUrl, and ehrUrl so they remain environment‑defined and not attacker‑controlled.
  • Option B (more flexible, but more logic): if we choose to allow URL updates, parse them with new URL(value), ensure protocol is http: or https:, and ensure the hostname is not localhost, not in 127.0.0.0/8, not ::1, and not in the 169.254.169.254 metadata pattern or private ranges. To keep the patch small and robust, I’ll use Option A and simply refuse to override the URL fields from req.body, which fully breaks the taint flow to getRxFillEndpoint().
• Change updateConfig(newConfig) to call sanitizeConfigUpdate(newConfig), assign the sanitized result to config, and return a copy.

No changes are needed in doctorOrders.js beyond this, because once config.intermediaryUrl (and the other URLs) can’t be set from req.body, getRxFillEndpoint() no longer depends on untrusted input and the SSRF sink is neutralized.

---