CWE-554, ASP.NET Misconfiguration: Not Using Input Validation Framework, is a short entry with a large reach. MITRE's description: the ASP.NET application does not use an input validation framework.
The consequence MITRE names is worth reading in full: unchecked input leads to cross-site scripting, process control and SQL injection vulnerabilities, among others. The missing framework is not the exploit. It is the reason exploits keep finding room.
How it happens
Validation without a shared framework is left to each developer and each page. Some fields get careful checks. Some get a quick length test. Some get nothing, because the person writing the page assumed the browser would handle it, or that another layer already had.
The ones that get nothing become the entry points. A search box, a hidden form field, a query string value used in a database call: each is a place where raw input reaches a sensitive operation.
// Vulnerable: raw input flows straight into a query
string name = Request.QueryString["name"];
var cmd = new SqlCommand("SELECT * FROM Users WHERE Name = '" + name + "'", conn);
Validation alone does not fix that line. The parameterized query below does. But a validation framework reduces how much hostile input ever arrives there, and it makes gaps visible.
// Safer: parameterized query, with input validated before it gets here
var cmd = new SqlCommand("SELECT * FROM Users WHERE Name = @name", conn);
cmd.Parameters.AddWithValue("@name", name);
What an attacker gains
MITRE lists an integrity impact with an unexpected state. In practice the gain depends on which downstream weakness the unchecked input reaches. That can be script running in another user's browser, control over a process, or reading and changing database records.
How to find it
- Review pages and controllers and see whether validation is declared or whether each handler does its own thing.
- Search for code that reads request values and passes them on with no checks.
- Look for form fields with no associated validators.
- Run static analysis, which can trace input to dangerous operations. It is often the quickest way to find the paths where the missing validation matters.
How to fix it
MITRE's mitigation, at the design stage: use the ASP.NET validation framework to check all program input before the application processes it. Its examples include:
- Phone number fields contain only valid characters for phone numbers.
- Boolean values are only "T" or "F".
- Free-form strings are of a reasonable length and composition.
Treat those as the pattern. Define what valid input looks like for each field, enforce it in the framework, and reject the rest. Then keep the other defenses in place: parameterized queries for the database and output encoding for pages. Validation is a first filter, not the only one.
Try it yourself
This demo shows a static code scan tracing untrusted input to the places it should not reach.
Click through it at your own pace, or open it full screen.
Quick check
Does using a validation framework remove the need for parameterized queries?
No. Validation narrows what can enter. Parameterized queries stop input from being treated as code. Use both.
What should free-form strings be checked for?
MITRE says a reasonable length and composition.
