Feat/stage

[AdriGeorge]

enterprise node

To fix this issue, we must sanitize any user-controlled string before incorporating it into an HTTP response. The most reliable approach for Node.js/Express is output encoding for HTML using a well-tested library such as escape-html. This prevents browser interpretation of injected JavaScript or HTML if the response is rendered as HTML. We should import escape-html and use it on isValid.error inside the response, so attackers cannot inject code via manipulated request parameters (e.g., signature).
Specifically:

• In src/components/httpRoutes/logs.ts, import escape-html near the top.
• Wrap isValid.error with escape() in the response on line 35:

  return res.status(403).send(`Invalid signature: ${escape(isValid.error)}`)

• Add the import for escape-html if not present.

Only these changes are required; no other lines or files shown need modification.

To fix the problem, ensure that the jobId parameter is a string before any string methods (indexOf, slice) are used on it. The best place to enforce this is the validate method of ComputeStopHandler. This should reject non-string jobId values as early as possible, returning an invalid message if jobId is not a string. In addition, for extra robustness, add a runtime type check at the start of the handle method, ideally throwing or replying with a proper error if the type is not as expected.

Steps/changes:

• In ComputeStopHandler.validate, after validating required fields, check that command.jobId is a string. If not, return an invalid request message.
• (Optional but recommended) At the top of the handle function, check typeof task.jobId === 'string'; if not, return a 400 error.
• No need to change the query handler in compute.ts, since the check in the handler will now enforce correctness.
• No new imports are needed.

---

The best way to fix this problem is to ensure that the untrusted input (req.query.jobId) is of the expected type (string) before using it, both at the point where it's assigned to the command object and before any string methods are called on it.

• First, in the route handler (in compute.ts), ensure that jobId is assigned as typeof req.query.jobId === "string" ? req.query.jobId : null. This will safely guard against type confusion caused by arrays.
• Optionally (but recommended), add an explicit type check in the saferizer/validation path, to future-proof against other bug sources.
• In stopCompute.ts, before using task.jobId as a string (e.g., calling .indexOf, .slice), check that it is a string, and gracefully handle (reject) if not.

These targeted changes are easy to apply within the code snippets shown, only require well-known JS/TS language constructs, and do not change the application’s intended behavior.

---

To fix the type confusion in this code, we need to ensure that jobId is always a string before it is used further down the chain—especially before using string-specific methods like .indexOf('-'), .slice(), etc. The best approach is to add a runtime check in the router/controller (file: src/components/httpRoutes/compute.ts, where the tainted parameter is first used), which explicitly validates req.query.jobId. If it is not a string, the request should be rejected with an appropriate error response (bad request), and execution should not proceed to the handler. This prevents arrays (or other non-string types) from reaching the business logic and eliminates the risk.

We should insert a check immediately before constructing the stopComputeTask object in the PUT /compute handler (so after line 161, before line 162). If req.query.jobId is not a string, send a 400 Bad Request response and return. This also provides a clear message to the client about what went wrong.

No new imports or dependencies are required, as this is achieved with native JS type checking.

---

To fix this SSRF vulnerability, you need to restrict the set of Docker registries (domains/hosts) to an explicit server-side allowlist before making any outgoing requests. That is, when parsing the Docker image reference, you should check if the resolved registry URL (namely, registry host) is one of your expected/trusted registry domains (such as "docker.io", "registry-1.docker.io", or domains configured in your environment). If the registry or domain is not trusted, reject the request early and do not perform the fetch.

Implement this by:

• Adding an allowlist of trusted registry hosts either as a constant array in compute_engine_docker.ts or loaded from config.
• Updating the parseImage method, or immediately after it in getDockerManifest, to check whether the registry host is in this allowlist.
• If not, throw a clear error or return a validation object indicating a failed check.
• Also, ensure that the path (name) and reference (ref) parts are not allowing traversal or malformed values (this can be simple, e.g., by using regular expressions to restrict characters, but the most crucial aspect is hostname restriction).
• Changes are limited to the handling and validation of registry domains just before the fetch in getDockerManifest in src/components/c2d/compute_engine_docker.ts.

The fix is to ensure that task.jobId is a string before doing any string operations like indexOf and slice. If it is not a string (e.g., it is an array because of a multi-parameter attack), the code should reject the request with an appropriate error message instead of proceeding. The fix should be applied before any string operations, ideally at the start of the handle method of ComputeGetStreamableLogsHandler in src/components/core/compute/getStreamableLogs.ts. You can use typeof task.jobId !== 'string' or !task.jobId || typeof task.jobId !== 'string' to catch null/undefined as well. Optionally, you may want to validate the format to match expected patterns, but at minimum, you must prevent non-string types.

Only edits to src/components/core/compute/getStreamableLogs.ts are required, and the change should be made at the start of the handle() method, before any usage of task.jobId. No additional packages are required.

To fix this problem, we must ensure that the handler in getStreamableLogs.ts only processes a string-type jobId value, rejecting requests where jobId is an array or any other unexpected type. The best way to address this is to add a runtime type check for jobId before using string methods on it (e.g., indexOf, slice). The most sensible place for this check is in the validate method or at the head of the handle method. Since the command is validated by a dedicated validate method, we should update this validator to return an error if command.jobId is anything other than a string (and non-empty). This avoids type confusion in all downstream code.

Specific changes:

• In validate(command: ComputeGetStreamableLogsCommand): ValidateParams (in src/components/core/compute/getStreamableLogs.ts):
  • Add a check: If command.jobId is not a string, return buildInvalidRequestMessage indicating the wrong type.
• Optionally, for defense-in-depth, a check can also be added in the route handler in src/components/httpRoutes/compute.ts after reading req.query.jobId, but strictly, the validator catch suffices.

No additional methods or imports are needed; just a runtime type check and an error return.

---

To fix the problem, the app should avoid sending unsanitized error text containing possible user input directly in the response body. The safest way is to not expose raw error text at all—instead, return a generic error message, or if details are required for debugging, sanitize them before sending. Ideally, also ensure the response content-type is set to application/json, so meta-characters will not be interpreted as HTML (though escaping is still important for JSON).

In src/components/httpRoutes/dids.ts, within the catch block of the POST /getProvidersForStrings route handler, replace the line res.status(400).send(error) with a generic error message such as:

res.status(400).json({ error: 'Error processing request.' })

Optionally, if the error message is useful for development but must be sanitized, use a escaping library (e.g., lodash.escape or he) to encode meta-characters, and return as a property in the JSON. However, for production, it is best to avoid including details that can contain user-supplied strings.

Only the specified code block needs to be changed; no imports or extra logic is needed since a generic error message (or sanitized message) suffices.

---

To fix this issue, we need to avoid exposing potentially sensitive error information to the user. Instead of sending the error object to the client, we should send a generic, non-descriptive error message (such as "An error occurred while processing your request." or "Bad request."). The internal details should still be logged to the server using console.error.

Detailed steps:

• In src/components/httpRoutes/dids.ts, in the catch block at line 54, replace res.status(400).send(error) with res.status(400).send('An error occurred while processing your request.') or similar.
• No new imports or method definitions are required.
• Only the catch block needs to change; logging remains as is.

---

The best way to fix this problem is to ensure that received errors are never sent directly to the user. Instead, a generic error message should be sent, while the full details are logged server-side for debugging or audit purposes. Specifically, in providerRoutes.get(${SERVICES_API_BASE_PATH}/download, ...), the catch block should be modified so that after logging the error with HTTP_LOGGER.logMessage, the HTTP response uses a generic message like "Internal Server Error" instead of error. Do not change any other functionality, request/response behavior, nor logging. Only the response body to the client should be generalized.

Change:

res.status(500).send(error)

To:

res.status(500).send('Internal Server Error')

No new imports or helper functions are needed; only this line needs to be edited.

---