Fix SSJS/NoSQL code injection vulnerabilities

[Copilot]

Replaces insecure eval() usage in contribution parsing and eliminates NoSQL $where injection in allocation threshold queries by removing the JavaScript-in-query approach entirely.

Changes

app/routes/contributions.js

• Replace eval(req.body.*) with strict regex validation (/^\d+$/) to reject any non-numeric input upfront, then convert with Number() for preTax, afterTax, and roth
• Add early input guard returning a user-facing error for invalid input before session destructuring
• Remove dead /*jslint evil: true */ directive and stale commented-out parseInt block

app/data/allocations-dao.js

• Parse threshold via parseInt(threshold, 10) and validate it falls within [0, 99]
• Replace the $where JavaScript-in-query clause entirely with native MongoDB query operators ({ userId: parsedUserId, stocks: { $gt: parsedThreshold } }), eliminating the JavaScript execution attack surface at the query level
• Throw a descriptive Error on out-of-range values instead of passing raw user input to the query

// Before — arbitrary JS execution
const preTax = eval(req.body.preTax);

// After — strict regex guard + Number() conversion
const isValidContribution = (val) => /^\d+$/.test(String(val));
if (!isValidContribution(req.body.preTax) || ...) {
    return res.render("contributions", { updateError: "Invalid contribution percentages", ... });
}
const preTax = Number(req.body.preTax);

// Before — $where with string interpolation (JS injection surface)
return { $where: `this.userId == ${parsedUserId} && this.stocks > '${threshold}'` };

// After — native MongoDB operators, no JS execution
return { userId: parsedUserId, stocks: { $gt: parsedThreshold } };

Potential fix for alerts

• Code injection
• Code injection
• Code injection
• Code injection

[marcosbergami]

@copilot modify this resolution and propose another possible alternative to fix this vulnerability.

[Copilot]

@copilot modify this resolution and propose another possible alternative to fix this vulnerability.

Here's the alternative approach implemented in commit fb2cb4b:

contributions.js — instead of parseInt(), now uses strict regex validation (/^\d+$/) to reject any non-numeric input upfront, then converts with Number(). This is stricter than parseInt which silently truncates strings like "5abc" to 5.

allocations-dao.js — instead of sanitizing input for the $where JavaScript-in-query operator, the $where clause is eliminated entirely and replaced with native MongoDB query operators ({ userId: parsedUserId, stocks: { $gt: parsedThreshold } }). This removes the JavaScript execution attack surface at the query level rather than just sanitizing the input.