Is it necessary to test all input parameters of a web application when testing its security?

Question

We know that testing input parameters for lack of validation is one part of a black box web vulnerability assessment but, is it necessary to test ALL input parameters (parameters, cookies, HTTP headers, URLs...)? If we don't test one it is possible that that parameter is the one vulnerable to a SQL injection or the XSS.

Prioritizing is one of the common answers but, how to prioritize if a SQL injection in a completely non-critical functionality opens access to the database giving complete control to the attacker?

If we have to choose a sample of input elements, how to choose that sample?

Should pentesters base its decissions just in experience or instinct when choosing which input parameters to test?

NOTE: I know that the correct thing is to test all parameters but sometimes this is unrealistic due to time limitations.

Answer 1

1. Yes you need to test all parameters if you want to perform a good test. You may choose to use automatic vs manual testing depending on how critical the input variable is and where it is situated in the application. Note that while a certain input variable may seem non-critical it might leave attackers with a vector to get to more critical functionalities of the application (think of stored XSS)
2. Prioritize based on likelihood and impact on your business. If that vulnerability allows to execute commands or dump all contents of your database,including confidential information, you need to patch it as soon as possible. If it only allows access to public information (and it can't be abused to gain more privileges within the application or access to the underlying OS) then you might make it less of a priority (depending on what the other issues are you are prioritizing on)
3. I'm not sure what "input elements" are but if you mean parameters, you need to choose all. You can choose to pay more attention on some fields than others (depending on your budget/time)
4. It depends, you need to do what your client asks, obviously if your experience has learned you that certain variable are more susceptible than others, you might just give them a bit more attention. But I'd say you need to take the requirements of the client into account.

Even if a functionality is not considered critical, you always need to assess the impact your exploit has on the application and the information stored within the application. The opposite is true as well, if you have a critical functionality with an exploit, but you can't actually gain any valuable information from it, then you should make it less of a priority to fix it. So, the impact of exploiting a vulnerability is important and not the criticality of the function you are exploiting. Prioritizing needs to happen based on impact.

Answer 2

The answer is definitively "yes", "no" and "it depends". The better way to ask this question would be "Knowing I have limited resources, how should I prioritize a review of my web-application?".

In security, success isn't defined as being 100% secure. Success should be defined as reducing risk down to an acceptable level. Your "acceptable level of risk" should be based on what your application does, what it protects, what's the fallout if something bad happens. I want more review done of the code that runs my pacemaker than I do of the Android game I buy for a dollar.

For 99% of organizations, resources are limited. It's unlikely that you will have the resources to throughly test every aspect of your web-application. You have to understand what resources you have available for review and then prioritize.

Every application is different so you should make your own judgements but here are some things I would prioritize:

Inputs that are used as part of SQL queries (SQL injection)

Inputs that are used as part of executed commands (command injection)

Inputs that are used as part of LDAP queries (ldap injection)

Inputs from one user that are echoed back to other users (persistent XSS)

Inputs from one user that are echoed back to that user (reflected XSS)

Inputs that are used as part of actions that modify a user's account

Inputs that are used as part of any complex processing (resource exhaustion DOS)

Inputs that are passed on to any processes that run with elevated privileges

Additionally, knowing that you can't exhaustively review every aspect of your web-app, you "cheat" by adding in additional mitigations:

Run your web-server without elevated privileges

Accounts for DB access should have minimal privileges

Have separate accounts for different types of DB access. If 95% of your DB calls are read-only, don't use an account with write privileges for those.

Answer 3

As others have pointed out, the short answer is YES, it is necessary to test all input parameters because when it comes down to it you have no idea how well or poorly coded the application is.

However, as you've stated, that doesn't always fly when there are unrealistic deadlines from business lines - who for lack of a better phrase, really don't care.

OWASP may be able to clue you in on which characters you should prioritize. For example: http://owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet (OWASP website)

However, with that being said, you have now just created a larger workload. You have to go through each possible vulnerability and determine which characters are specific to that vulnerability.

That task alone may take longer (at least initially) than to test all characters and will not be as thorough. (which goes without saying)