If you own an online trading site, you’ve probably thought about these threats:
Can an adversary…
… view the portfolios of other users?
… place trades on behalf of another user?
… cancel trades that have already been executed?
… steal the passwords of other users?
… bypass login?
… deny access to all users?
We call the list of all the threats to your application its Threat Profile.
The Threat Profile is the starting point of our tests. In the first few days, our engineers study your application and prepare its Threat Profile. We share it with you and get your feedback – have we missed something? Have we exaggerated a threat? The final Threat Profile drives the Test Plan. For an online trading application, the Threat Profile might identify 20-40 threats.
The Test Plan first maps each threat in the Threat Profile to specific pages on your site. For example: The adversary views the portfolios of other users might be mapped to the “View Portfolio” page. Next, the Test Plan identifies all the attacks to try on those pages to realize that specific threat. For example, on the “View Portfolio” page, we might decide to try a Variable Manipulation attack and a SQL Injection attack to see portfolios of other users. The Test Plan is thus built up for all the Threats in the Threat Profile. This is the most intensely “thinking” phase of the test. To assist our engineers, we have a master reference checklist of all attacks – they pick attacks for the Test Plan from that checklist.
Once the Test Plan is prepared and approved by a senior, the testing begins in earnest. The tests are a combination of manual and automated checks. The engineer adheres to the Test Plan. When he gets new ideas, he updates the Test Plan and performs the Test.
When an attack succeeds, we capture the screenshots of the attack. Our final report walks through the attack with the aid of these screenshots.
The Threat Profile to Test Plan approach helps us focus our testing on the threats that matter to you. Any large application penetration test involves hundreds of test cases, so it’s important that the engineer focus on the right set of test cases. He should, for instance, focus on whether a trade can be cancelled than on generating error messages by tampering unimportant variables.