The web is full of applications that pop up overnight like weeds after a spring rain. It's not really unexpected, then, that organizations are struggling with testing these applications before they have the potential to cause corporate calamity in the form of a security incident.
Keeping up with the amount of applications being released can often lead to more subtle issues.
We can all say with relative confidence that just because an application has been tested does not make it secure - and even the best analysts & testers can miss security defects.
Speaking with industry veterans it is still apparent, at least to me, that there is a long way to go between testing applications and testing applications properly.
Before diving into any application a security tester needs to know the following 3 Critical Facts about the application under test:
What does it do? - Entirely too many testers just dive in to an application to security test it without actually knowing what that application does.
The critical thing to understand is that without knowing what the purpose of the application is, you can't hope to understand any subtle flaws in business logic, or inter-connected components of the application.
Knowledge of the intended business purpose and function of the application should be automatic, yet often lacking. Attackers adapt their techniques once they've fully understood the way an application works, shouldn't your corporate testing regime do the same?
How is it built? - Knowing the construction of an application is critical to adapting your testing strategy and techniques, thus asking how an application is built will provide deeper insight into the application that you can see through your browser.
Does the application run on Oracle? or NoSQL? Is it built on top of a LAMP (Linux Apache MySQL PHP) or is it a multi-tiered Windows platform?
Having the knowledge of the construction of an application can help a tester concentrate on the attacks focused on the specific platform, and give him or her the necessary knowledge to tune the testing technology to maximize results and minimize wasted time.
What is the data? - Data can be email addresses, credit card numbers or proprietary statistics -but knowing which you're after can be the difference between succeeding and meandering.
A thief will not try to break in to steal 'something'... he will break in because he knows that on the 2nd floor, behind that portrait of dear uncle Harry is a safe which houses your family's valuables.
You as the application tester should absolutely be armed with the same knowledge when testing an application... ask yourself - "what am I after?"
Clearly there are more facts that you must know about an application before you dive in and start testing. These are just the 3 absolutely most fundamental.
Here's some of the other things you'll also want to have ...
- application workflows (or use-cases for you QA analysts)
- valid test data
- application failure states
- authentication and authorization modes, tiers and roles
- ...and there's more