“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 true for SAAS providers offering web application scanning 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
Properly configured web 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 parameter 1 and put acceptable values into the other 9 parameters to successfully complete the form request.
Why can’t you just attack all 10 at once? Well, let’s say that parameter 1 is vulnerable and parameters 2 -10 have good filters. If you attack parameter one with an attack that works (i.e. the application does not recognize it) and parameter 2 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.
Leave a Reply