There are some powerful methods for finding more security bugs with fewer false positives while using the test framework you already have for your web apps. Doing it doesn't need to be complex or expensive.
More about that in a bit, but for now I want to tell you about my favorite HR violation. No, this doesn’t involve human resources. This involves the humble horizontal rule tag, <hr>.
A manual tester at my company had a huge number of "usability" bugs that were often considered low priority. These were simple bugs, caused when he put the <hr> tag in a user's name; he would then see a line break instead of the user's name. From a QA perspective, this was not a huge concern, but I’m on the security team, and I saw this as an indicator that we might have cross-site scripting (XSS) there.
I decided to give our manual tester a couple of magic strings, such as <script>alert(1)</script>, and said, "If you get any alerts popping up in your usability bugs, they are security bugs, so let me know." This led to a deluge of bugs.
This shows everything you need to know about what's behind integrated security testing. If you give the QA automation engineers a bit of help from the security team, you have many powerful ways to find security bugs with surprising accuracy.
Since I used to work on the QA team, I found some unique and accurate ways to use existing tests for my hacking purposes. Here's how you can do it, too.
General principles
The complexity of testing comes from the sheer number of things you have to test. For every feature, there are multiple use cases, multiple settings, multiple versions, multiple user stories, multiple—you get the idea. The effect of just a few variations creates an exponentially more complex test problem.
For example, just 10 switches create more than 210 possible combinations to test, which means that, to have perfect coverage, you would need 1,024 tests! Luckily, most testers know that having that many tests is not ideal.
Testers use a couple of tricks to get good enough coverage. One is to use code coverage tools to ensure that each function gets unit tested. Another is to ensure in the test plan that you cover the most common test cases, and then cover the edge cases to ensure that users don't run into issues. Testers can also use clever algorithms such as PairWise to get incredible depth and breadth in testing an application.
My point is that testers already have a lot of coverage for the most common cases and the all-important edge cases. Therefore, to have amazing security test coverage, simply add some hacking payloads to your existing security tests. Then you'll have both in-depth and incredibly broad coverage. It's that simple!
Figure 1: How integrated security testing works.
[ Special Coverage: SecureGuild 2019 testing conference ]
How to use integrated security testing to find XSS instances using Selenium
XSS is a common security issue for web applications and a persistent issue on the OWASP Top 10. Simply put, it is one user executing a script on another's page. This is normally done with simple injection of a script tag, image tag, or other breakouts. This can be used by an attacker to steal cookies from victims or to perform other actions on the victims' browser.
The common way to search for this, from a black-box perspective, is to throw in a bunch of script tags and see what comes out. This is exactly what the manual tester did with the <hr> tags, but the manual tester already had in-depth knowledge of the application he was testing. That's how he found a deluge of security bugs so quickly compared to most penetration testers and scanning tools.
There are two ways to introduce this to your QA teams. The first is to provide them with a list of payloads from OWASP; here is a good one. This way works nicely, since you just drop off the payloads and see what happens.
The second way is to build in security testing as part of test suite automation. This becomes very interesting, since most of the time test automation is already automated. This means you can easily piggyback on the hard work already done by your QA department.
In the case of XSS, you can add a string generator into the Selenium automation code that spits out a lot of common payloads. The problem with this approach is that the common "alert" box will break tests, and that will anger your QA folks.
So, instead of an alert box popping up, use console.error() to send a unique number to the browser logs. Then pick up the browser logs from Selenium to see if the unique number showed up, proving that there is an XSS vulnerability. This extra detection and assertion usually add more context to let the QA team know whom to contact to find out what the error means.
Figure 2: This alert box will break your tests.
Integrated security testing versus DAST
Most dynamic application scanning tools (DAST) were built back in the days of forms-based sites that didn't use JavaScript to create interactive front-end applications with React or AngularJS. They were also built with a one-size-fits-all philosophy for every web application. Unfortunately, no two web applications are the same.
Each web application has its own business logic and rules. In some fields, you need to add an email; sometimes to get a bug to work you need to log in as a different user; and sometimes you need to do things that DAST can't, such as drag and drop.
Also keep in mind that if a payload doesn't work immediately, then DAST tools won't find the security bug. For example, imagine that there's an XSS in the username in a social media application that only works if you view it as one of your friends.
DAST won't be able to log in as someone else without a Herculean programming effort, but an important function like that will probably already be covered in a Selenium test. A DAST tool lacks the business logic, which is already built into a suite of functionality tests.
[ Also see: Security testing is unlike other QA: What you need to know ]
What you need to get started
Adding security testing to your existing functional tests is simple and effective. All that's required is a list of common payloads and some extra assertions in your tests. Doing this lets you go deeper into your web application than scanning tools can ever go, since your tests understand business logic.
For more on how to find more bugs such as XSS, Angular Injection, and SQL injection, drop in on my session at SecureGuild, the online security conference for testing professionals, on May 20-21, 2019. Can't make the date? All registered users have full access to session recordings after the event.
Keep learning
The future is security as code. Find out how DevSecOps gets you there with TechBeacon's Guide. Plus: See the SANS DevSecOps survey report for key insights for practitioners.
Get up to speed fast on the state of app sec testing with TechBeacon's Guide. Plus: Get Gartner's 2021 Magic Quadrant for AST.
Get a handle on the app sec tools landscape with TechBeacon's Guide to Application Security Tools 2021.
Download the free The Forrester Wave for Static Application Security Testing. Plus: Learn how a SAST-DAST combo can boost your security in this Webinar.
Understand the five reasons why API security needs access management.
Learn how to build an app sec strategy for the next decade, and spend a day in the life of an application security developer.
Build a modern app sec foundation with TechBeacon's Guide.
