C-SWCM study materials
C-SWCM study resources

SQL Injection Behind an ORM

C-SWCM · Put your knowledge to work in context.

All case studies

SQL Injection Behind an ORM

An application uses an ORM for most queries, but a reporting module builds SQL by string concatenation for a date-range filter: WHERE created_at BETWEEN ' + start + ' AND ' + end + '. The inputs come from a web form and are validated with a regex that allows digits, dashes, and spaces. A penetration test found that a crafted value containing a quote and comment sequence returned extra rows. The database account used by the app has full DDL rights. The team argues the regex makes exploitation impossible and wants to close the finding as a false positive. The reporting module is used by internal staff only, behind SSO.

1. Assess the team's false-positive argument and identify the exploitable path.

Read the worked answer

The regex reduces but does not eliminate risk. It allows spaces, digits, and dashes, and depending on its exact form it may permit characters that enable injection, such as a quote if the pattern is anchored incorrectly or if the input is concatenated before validation. More importantly, the penetration test already demonstrated extra rows returned, which is evidence of injection. Internal-only and SSO are not mitigations: staff accounts can be phished, and an insider or compromised session can exploit it. The correct conclusion is that the finding is valid. The fix is parameterized queries for the date range, not string concatenation. Validation is defense in depth, never the primary control.

2. What additional hardening should be applied to limit impact if another injection exists?

Read the worked answer

Apply least privilege: the application's database account should have only the DML rights it needs and no DDL or access to unrelated schemas. Separate reporting credentials from transactional ones. Enable database auditing and alerting on anomalous queries. Add a WAF rule as a temporary compensating control, but do not rely on it. Review all dynamic SQL, including ORDER BY and table names, which cannot be parameterized and must use allowlists. Add SAST and dependency checks to CI, and include injection tests in the regression suite. These measures reduce blast radius and catch recurrence.