How far do you go in server-side validation of POST/GET requests?

Question

Our application had a few vulnerabilities detected by AppScan and we had to add server-side validation to catch SQL injection attempts.

But my question is, how far do you go in server-side validation? In theory there's no end to how complicated you can make it.

Suppose I'm just validating there are no special chars in my model, which is the bare minimum

public boolean validateModel(Model model) {
    // Email address has no special chars
    try {
      InternetAdress emailAddr = model.getEmailAddr();
      emailAddr.validate();
    } catch (Exception e) {
       return false;
    }

    // FirstName has no special chars
    if (!StringUtils.isAlphanumeric(model.getFirstName())
         return false;

    // LastName has no special chars
    if (!StringUtils.isAlphanumeric(model.getLastName())
         return false;
    }
    // ...  
    return true;
}

But why stop there? In any CRUD operation, we also have to protect against invalid IDs or numbers, so any Insert can check that the ID doesn't exist yet; that you belong or don't belong to whatever area you claim to be affiliated with (e.g. the ID is a valid ID for you); or any Update/Delete can check that the ID must exist first. To be really secure, we can really parse user input because hackers can substitute invalid data even without invalid chars.

My point is, to achieve a proper level of server-side security, there's a tremendous of checking you can do on the server-side. Where do you stop? What are the best practices?

Answer 1

Personally I write virtually no input checking on my .net apis.

But what about hax0rz!?!? I hear you cry.

Simple. A combination of defensive programming and using the built in .net functionally totally covers you

1. Authorise attribute and your fave auth layer stops un-authenticated/ un-authorised requests

2. SqlClient parameterised queries stops sql injection

3. Exceptions, they bubble up and are returned to the client (now requires a handler to make em json). Catch em and Throw them when something is wrong.

4. Limit functionality on public methods to required security granularity. Don't make a DeleteAnything() method when you have a requirement that people can only delete certain things. Have DeleteThisSpecificTypeOfThing()

You need input checking when you want to return nice messages to the user "it looks like your name has a number in it. That is not allowed!"

In an Api that's best left to the client. We want to avoid the round trip.

Answer 2

I understand the pain of coding such checks but you have to code them in order to have a stable/secure API.

But why stop there? In any CRUD operation, we also have to protect against invalid IDs or numbers

I assume you do not check this kind of informations ?

I'm pretty sure it exists some mecanism to make these checks easier.

I know that .NET provides some class in order to manage security checks :

• AuthorizationFilterAttribute to manage authorization on request
• ValidationAttribute to manage model validation
• ActionFilterAttribute to manage input validation (if model is not valid return BadRequest, if id does not exist return NotFound)

Have you looked at this kind of things ?

Automation is the key here !

Answer 3

Our application had a few vulnerabilities detected by AppScan and we had to add server-side validation to catch SQL injection attempts.

Server-side validation should be part of your application right from the outset.

how far do you go in server-side validation?

As far as necessary to protect your application and the users' data.

Server-side validation is the only validation that matters or, rather, it's the only validation that you can be sure will actually happen.

You cannot trust anything that comes from the client.

Previously answered (comprehensively] under What technical details should a programmer of a web application consider before making the site public?