Here is an affordable practical proposal for continuous web application security:
- Have a Ubuntu Desktop (I personally like to see what is going on when it comes to the UI related testing) with your end to end (E2E) platform of choice running on it.
- From your continous integration (CI) of choice hit (remotely) a local runner that triggers your automated E2E test suite against your application URL. I strongly believe that E2E concerns belong to whoever is in charge of developing the UX/UI.
- E2E tests should open your browse of preference and you should be able to *see* what is going on in the browser.
- A proxy based passive scanner like zaproxy should be installed. Below is how to install it from sources:
- If you want to start the proxy with a user interface so you can look into the history of found vulnerabilities through a nice UI and assuming you installed it from the recipe then run it as '/opt/zap/zap.sh' or if you get issues with your display like it happened to me while using xrdp with 'ssh -X localhost /opt/zap/zap.sh'.
In order to proxy all requests from chrome we need to follow the below steps.
- From zap proxy menu export the Root CA certificate using "Tools | Options | Dynamic SSL Certificates | Save"
- From Chrome settings search for "certificate", click "Manage Certificates | Authorities | Import | All Files"; select the exported cer file and select "trust his certificate for identifying websites"
- Your E2E runner must be started after you run the below commands because the browser should be started after these commands in order to use the proxy.
export http_proxy=localhost:8080 export https_proxy=localhost:8080
- To stop the proxy and resume E2E without it, we just need to reset the two variables and restart the E2E runner.
LEGACY 12.04: For the proxy to get the traffic from chrome you need to configure the ubuntu system proxy with the commands below. All traffic will now go through the zaproxy. If you want to turn the proxy off just run the first command. To turn it on run just the second but run them all if you are unsure about the current configuration. This is a machine where you just run automated tests so it is expected that you run no browser manually there BTW and that is the reason I forward all the http traffic through the proxy:
- Every time your tests run you will be collecting data about possible vulnerabilities
- You could go further now and inspect the zaproxy results via the REST API consuming JSON or XML in your CI pipeline in fact stopping whole deployments from happening. You can take a less radical approach and get the information in plain HTML. Below for example we extract all the alerts in HTML obtained while passively browsing http://google.com. It is assumed that you have run '/opt/zap/zap.sh -daemon' which allows to access from http:/zap base URL the REST API:
- If you want to access this API from outside the box you will need to run '/opt/zap/zap.sh -daemon -host 0.0.0.0 -p 8081' however keep in mind the poor security available for this api.
- Do not forget to restart the proxy after vulnerabilities are fixed or stop and start it automatically before the tests are run so you effectively collect the latest vulnerabilities only
- Your CI might have a plugin for active scanning (See https://wiki.jenkins-ci.org/display/JENKINS/Zapper+Plugin) or not. Starting an active scanning automatically should be easy.
Congratulations. You have just added continuous web application security to your SDLC.