Last updated at Thu, 31 Aug 2017 14:20:04 GMT

“Laws are like sausages. It's better not to see them being made.” – Otto von Bismarck

I'm not sure how many of you have kids or how diligent they are with their homework but I'm sure you've heard stories of parents observing that their kids have finished their homework in a remarkably short period of time.  However, upon investigation, you quickly discover that your child has only finished half of their homework.

Sadly, this state of affairs can also be true for SAAS providers offering web application application security assessment services.  Only half of the work gets done, resulting in rapid, but inaccurate scans and potentially vulnerable websites that are given clean bills of health by the scanning company.

Taking shortcuts

In order to find all SQL Injection and other important vulnerabilities, its critical to test every single parameter or input in an application. Properly configured web application vulnerability scanners should test parameters by locating all of the parameters on a page and then making attacks against individual parameters at a time.  So if there are 10 parameters, you do an attack against the first parameter and then enter acceptable test data values into the other nine parameters to successfully complete the form request.

Why can't you just attack all 10 at once?  Well, let's say that parameter one is vulnerable and parameters two -10 have good filters or validation. If you attack parameter one with an attack that works (i.e. the application does not recognize it) and parameter two with an attack that trips the filter in the application, the application will quite likely appear to not be vulnerable.

Now the problem is that if you are testing various attacks (SQL Injection, Blind SQL Injection, Cross Site Scripting, etc.) you will have dozens of attacks of each class against each parameter.  Your total attacks per parameter will exceed 100 and if you have 10 parameters on a page (which you will likely have in a signup form, for example), you will have over a thousand attacks for that page. On top of that, some of these attacks, like blind SQL, will have multiple requests per attack.

Performance vs comprehensiveness

Many SaaS vendors want to complete scans fast to make them look more impressive. The problem is that in order to accomplish, you have to cheat.

To speed up a scan, you might only test the first parameter or the first three or whatever and then skip testing the rest of the parameters.  If the customer doesn't test the site and doesn't get hacked, no one is the wiser if those untested parameters are vulnerable.

Does this matter?  Is it possible that one of parameters 4-10 is vulnerable if 1-3 are not?  In a word, yes.  Different parameter types (dates, text fields, numerical values, etc.) will have different filters.  Just because a developer got 1 right doesn't mean that he got them all correct.  We've seen numerous cases where one parameter is 100% clean and others are full of holes.  You have to thoroughly test every parameter.

Letting those POSTs get away with murder

Since dealing with forms on web pages can be difficult and there is a possibility that they could modify data in the database behind the web application, some SaaS solutions don't even attack them. So this means all the inputs from the forms never get tested.

On many of the sites we have tested over the last decade, the form inputs sent over POST have been some of the most critical attack points with some of the worst vulns and often the most important areas to test on a website. Not testing them is the same as locking your doors, but leaving your windows wide open.

How can you assess your vendor

Ask your vendor the hard questions, such as:

1. How many parameters do they attack per page? Are there limits they impose.

2. Ask them to demonstrate that only one parameter at a time gets attacked while the other fields having good data. Heck, ask them to put these answers in the Statement of Work (SOW).

3. Confirm that they attack forms and POST data. Ask them to demonstrate it or test it yourself with a trial.