Hi,
SaaS Security Testing - The Challenges
This article by Roshen Chandran
I have collected for you and provide here..
Last month we looked at 5 Tips for Securing Software as a Service . This time, we’ll dive into the challenges in security testing SaaS applications, and how to overcome them.
Very frequent changes
Too many pages
Lots of privilege levels
A lot of Ajax
Tools haven’t matured
Very frequent changes
The SaaS model lets developers add features incrementally. Every fortnight, every month, new features are released to meet customers’ needs and stay ahead of competition. Every change is a potential security bug.
Traditionally software vendors performed security tests between alpha and final release. With SaaS, that’s almost every day. A few new features would always be scheduled to release soon. The traditional “one major security test”, followed by a few re-confirmatory tests are too slow when the application is adding features routinely.
Today, SaaS vendors we work with are experimenting with a subscription model for security testing - round the year testing that include incremental tests for new features.
Too many pages
Feature-rich SaaS applications can have lots of pages. That increases the time it takes for testing. In an ideal world, automation tools could have reduced the problem. But automated scanners today find at most 20% of the vulnerabilities in an application. So, the large number of pages are a challenge in testing SaaS applications.
How do we overcome this challenge? Our approach has been to focus on the threats. This is not a new approach, you can read about it in “Why we love Threat profiles ”, and “Still loving Threat profiles ”. By focusing on the threats, we do not let ourselves be overwhelmed by the number of pages.
Other approaches we have heard and experimented with are 1. partitioning the test into smaller modules, and 2. focusing on just the security functions like authentication and cryptography. Partitioning works as long as each module is independent and there are no dependencies - which was rare in the applications we tested. The latter approach of testing only security functions is cost effective, but completely ignores the threat of business rules being violated.
Lots of privilege levels
A good security test will find holes that lead to privilege escalation. So when the number of roles (and thus privilege levels) increase, the number of test cases increase quickly.
For example, a purchase workflow might involve purchase initiator, verifier, and approver - 3 different roles with different privileges. The security test must find any hole that lets an initiator escalate his privileges and approve a purchase. The number of such combinations increase as the number of privilege levels increase.
This is not a problem for automated scanners, as they do not find these holes anyway. But, for the intelligent security tester the surge in privilege levels present a challenge. At Plynt, we haven’t solved this fully yet. An approach we are trying out today attempts to find a smaller set of test cases that verify if any privilege level can be violated. If you know a good solution, we’d love to hear it.
A lot of Ajax
Web 2.0 SaaS applications use a lot of Ajax . Under the hood, there is a rush of HTTP requests. Traditionally, new HTTP requests were initiated during a page transition, or to get an image. With Ajax , the client is constantly issuing requests for small changes to the page.
The security tester looks at these rush of requests with hope and alarm. Every request is a potential candidate for tampering a variable, injecting a SQL snippet, or embedding a script. That gives the security tester hope - until the flood of requests begin to overwhelm him.
While the vulnerabilities in Ajax applications are similar to those in older applications, the techniques and tools for testing Ajax applications is just evolving. Shreeraj Shah’s article in Securityfocus last month “Hacking Web 2.0 Applications with Firefox ” is a good starting point to learn today’s approach to Ajax security testing.
Tools haven’t matured
Automated scanners were built to reduce the manual component in security testing - especially when new versions of an application are released frequently. Unfortunately, even the best scanners today fall short of these expectations.
Tools today reduce the load of brute force testing, eg. to inject faults in an HTTP stream. Less than 20% of holes can be discovered by that brute force approach, though. Teasing out those bugs require more intelligence than today’s tools display.
The best approach to reducing time is to combine human intelligence with tools to find the most holes in the least time.
You can get more articles , ebooks, related to software testing from http://www.macrotesting.com - here .
All the best...
|