0

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?

  • 1
    You go as far as you need to to achieve a reasonable amount of security. Some things are not going to give you additional security. For example, invalid ID's will fail at the database call, so they don't necessarily require any special validation, other than handling the database error appropriately. – Robert Harvey May 16 '18 at 15:03
  • No, invalid IDs can be legitimate IDs that exist, but they're just off-limits to you. Imagine the ID is "SubmissionID" and it's a submission you don't belong to or shouldn't be allowed to access. But the SQL will still work. – gene b. May 16 '18 at 15:04
  • Yes, I get it. My point is, it's not a "tremendous" amount of effort to do that; it's just ordinary effort. There isn't a never-ending parade of validation cases to identify. – Robert Harvey May 16 '18 at 15:05
  • Of course you should validate against IDs for which the user is not authorized to access. What alternative to you suggest? – Vincent Savard May 16 '18 at 15:10
  • @VincentSavard: I think the OP is asking, more or less, "how do I defend against the unknown?" – Robert Harvey May 16 '18 at 15:22
3

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.

1

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 !

0

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?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.