Automated Functional Tests, a healthy food for Automated Security Tests — Part 1
I have divided this article into two parts. In the first part we will build the approach and in the second we will actually be diving deeper and coming up with a detailed POC.
So, let the funs begin !!!
I am sure some of you must have come up with this question “Can my functional automation tests help me perform security testing?” while writing down your selenium tests…Right?? :)
Several times in my career I had this thought and at that time the maximum I did was including some malicious input as a part of my data-driven selenium tests.
E.g. In the login automation tests, along with valid and invalid permutations of username and password, we can also include some malicious username like :-
<script>alert(‘You are Hacked’)</script>
OR
a malicious password like :-
Password’ or ‘1’=’1
If you have done some sort of security testing before then the above inputs would be quite familiar..Right?! These are the standard and the goto inputs whenever you want to try out XSS and SQL Injections respectively.
There is nothing wrong in the above approach at all. But, you will have to do this for all your pages / scenarios where you are filling forms or have input boxes, which can be quite a daunting task.
Again, there are several other security vulnerabilities apart from XSS and SQL Injections which is difficult to cover by this approach.
Also, this will increase the total number of UI functional automation tests by a huge number and hence will increase the execution time drastically (which is a big NO NO)..
So, what are the other options?
In one of my previous companies, I had the privilege of working closely with the Security Team and Pen Testers. It was my first company where we had a separate Security Testing Team. In one of the cycles of pen-testing carried out by this team, I just silently observed what they used to do.
At a high level, following were the main task(s) performed by the security testing team :-
1. Start a security testing tool, in our case it was Burp Suite. We had a professional license of Burp Suite.
2. Set the proxy of the browser to point to the port where Burp Suite is running.
3. Open the web app under test in the browser and manually perform different functionalities via UI. Functionalities were performed such that all the screens/requests of the app were covered.
4. When the actions are performed in the web app, the requests would get captured in the Burp Suite (as a result of the proxy thing set above).
A passive security scan gets performed automatically by the burp suite as soon as the requests are captured (we will cover below what a passive/active scan is). Below screenshot shows a glimpse of the requests been captured in Burp Suite when the actions are performed on the Application Under Test :-
5. Select all these requests which are scanned and perform an active security scan.
6. Generate a report once the active scan is complete.
7. Study the report and on the basis of the results of active security scan, they would perform more in-depth security testing (manually + some utilities available in the Burp Suite). This is the point where the true skills and knowledge of the pen testers would actually come into use.
The steps 1–6 above would give us a security scanning report which has a good number of basic different security vulnerabilities like XSS, SQL Injections, Broken Authentication/Authorization, File Path Traversing, Missing Important Security Headers and many more.
Now, one of the main challenges they used to face was in the Step 3) above. The Security Testing Team did not have detailed knowledge about the functionality of the system. As a result of this, they ended up not touching each and every page/requests of the Application Under Test. Hence, some page/request might get deprived of getting tested from a security point of view.
Nice Story! Come to the point :)
Looking at the activities of the pen testers above, my eyes lit up and I am sure many of yours eyes must have also lit up by now :)
My reaction was :-
“Hold on!! Step 3(Performing functional testing manually) above is something we already do in our UI functional automation tests using Selenium AND it does have an awesome coverage.”
This got the Security Team also interested and then I started working with one of the pen tester to automate the other steps as well and then chaining the steps to achieve a full automation.
Before moving ahead let’s first cover what is Passive and Active Security Scanning in the security testing world.
Passive Scanning :- In Passive Scanning, the security tool (any tool) just scans all the proxied requests and tells you what all things are missing in the request from the security point of view. E.g. Request has any security headers missing etc..
Active Scanning :- In Active Scanning, the security tool changes some parameters/headers in all the proxied requests and bombards your system with these changed requests. It then scans the response and tells you about security vulnerabilities.
Hence, active scanning is the one which identifies different important security vulnerabilities in your application.
*Note:- Active scanning should be performed in an isolated environment only. Never to be tried on Production or Staging or any other environment which is shared by several team members.
Until now, we have identified how the Step 3 above can be automated if we already have functional UI automation tests for our AUT (using any of the UI automation tools not only selenium).
Now, let’s see how other steps can be automated.
Step 1 (Starting Burp Suite) : is quite simple. The tool can be started in headless mode (using one of it’s extensions). So, we can simply write down a shell script to start burp suite in headless mode.
Step 2 (Set Proxy of the Browser) : In selenium, there is a way to set proxy at the time of initializing the webdriver object. So, this step can be easily done for selenium.
If you are using any other tool, then also you can achieve this by using the native capability of the technology you are using for scripting (e.g. Java or C#)
Step 3 (Performing functional testing manually) : Already addressed above.
Step 4 (Passive scanning of the requests) : This automatically gets performed if Burp Suite is up and running (already started in Step1).
Step 5 (Active scanning of the requests) : This step is a bit challenging. Now, it happens that VmWare has come up with a RestAPI project for BurpSuite, where-in all the major functionalities of Burp Suite are exposed via restful API’s. Here is the location of the project and a nice README for the same.
It has a rest API for performing Active Scan as well.. So we can simply use a curl call OR call the respective API via any technology (java or c#) and get it achieved. Below is a screenshot of the swagger page of this VmWare Burp Suite Rest API’s. You can get an idea of different API’s available for the same.
Step 6 (Generating report of the security scan) : Again, we can leverage the above restful api project to generate a report. There is a rest API for generating HTML report as well.
YIPEEE!!!
We have automated (though conceptually as of now) steps 1–6. Now, one has to simply create a Jenkins Job or a project (in your desired technology) and connect all the above tasks (which we automated).
I used Jenkins job and added all the above tasks to it. Some level of DevSecOps also achieved.
By now, I think the concept is clear to you all on how to leverage our functional automation tests and perform automated security testing.
In the next section, we will convert this concept into a POC. We will be integrating functional selenium tests and a security testing tool called ZAP (Zed Attack Proxy).
Note :- ZAP is an open source security tool created and managed by OWASP (Open Web Application Security Project). It’s quite similar to Burp Suite.
As it’s open source, we will use it in our POC so that we don’t have to bother about licenses and stuff.
