Skip to content

[Security Fix] SAST: Authenticated RCE via eval() applied to request body fields preTax/afterTax/r...#411

Open
okaypatrick wants to merge 1 commit into
OWASP:masterfrom
okaypatrick:fix/security-a46e9de0
Open

[Security Fix] SAST: Authenticated RCE via eval() applied to request body fields preTax/afterTax/r...#411
okaypatrick wants to merge 1 commit into
OWASP:masterfrom
okaypatrick:fix/security-a46e9de0

Conversation

@okaypatrick
Copy link
Copy Markdown

Security Fix

Type: SAST
Generated by: AI-Powered Fix Generator
Finding: Authenticated RCE via eval() applied to request body fields preTax/afterTax/roth.
Rule: claude-injection-eval-contributions (oogway-scanner)
File: app/routes/contributions.js (line 33)
Severity: HIGH

Explanation

The handler passed req.body.preTax, req.body.afterTax, and req.body.roth directly to eval(). Because the request body is fully attacker-controlled, any authenticated user could submit a string of JavaScript (e.g. require('child_process').execSync('...')) and have it executed in the Node.js server process, resulting in remote code execution.

The fix replaces each eval() call with parseInt(..., 10), which safely coerces the input to an integer. The existing downstream validations (isNaN, negative checks, sum-cap of 30) continue to work unchanged because they already expect numeric values, preserving all functional behavior while eliminating the injection sink.

Changes

  • app/routes/contributions.js: Replace eval() of user-supplied request body fields with parseInt() to prevent server-side JavaScript injection / authenticated RCE.

Test Suggestions

  • POST /contributions with preTax='10', afterTax='10', roth='10' should succeed and update contributions.
  • POST /contributions with preTax='require("child_process").execSync("id")' should be rejected as invalid (NaN) and not execute any code.
  • POST /contributions with preTax='-5' should return 'Invalid contribution percentages'.
  • POST /contributions where preTax+afterTax+roth > 30 should return the 30% cap error.

Breaking Changes

  • Inputs that previously relied on eval()'s ability to evaluate arbitrary expressions (e.g. '5+5') will now parse only the leading integer ('5+5' becomes 5). Plain numeric strings continue to work identically.

…s preTax/afterTax/roth.

The handler passed `req.body.preTax`, `req.body.afterTax`, and `req.body.roth` directly to `eval()`. Because the request body is fully attacker-controlled, any authenticated user could submit a string of JavaScript (e.g. `require('child_process').execSync('...')`) and have it executed in the Node.js server process, resulting in remote code execution.

The fix replaces each `eval()` call with `parseInt(..., 10)`, which safely coerces the input to an integer. The existing downstream validations (`
@carsam2021
Copy link
Copy Markdown

Hello @okaypatrick just to let you know that your "AI-Powered Fix Generator" does not have any intelligence to figure out this is an intentionally vulnerable app which does not need fixing 🤣 please stop spamming with useless PRs

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants