[QA] The case for security test scenarios

Sherif Mansour cherifmansour at gmail.com
Sun Aug 10 14:24:47 UTC 2014


As a security engineer I want to make sure that new/existing site features
are tested for security bugs, and new changes to a web application do not
break existing security controls.

*What can be done?*
There are several ways to approach this of course. One way to ensure
feature coverage is to run a lot of the QA regression packs such a selenium
scripts, through a web app security proxy which will then run security
tests based on the requests it sees flowing through it.

Additionally I recommend the creation of security test scenarios in order
to test certain application logic. Simple example: If a user signs-out and
clicks back he should not appear as signed in.

*Are there tech teams working on this?*
Yes several tech companies are using similar approaches and for inspiration
I recommend that you take a look at the following work:
http://www.continuumsecurity.net/bdd-intro.html

*Is it open sourced?*
Yes, and its on github: https://github.com/continuumsecurity/bdd-security
The ZAP security proxy is also open sourced (and it:
https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project

*How does that work in practice:*

   1. The continuous integration server (e.g. Jenkins) would run selenium
   scripts, and set the forward proxy to the security web app proxy (such as
   ZAP).
   2. The CI server would then send api commands to the zap proxy to run
   security scans based on the requests it will receive (and the scope can
   also be set there as well).
   3. The selenium scripts run and zap would run security tests off of that.
   4. Additionally there would be some selenium tests that are based on
   security scenarios.
   5. The security findings are reported, reviewed for false positive, the
   priority is set, and bug is raised for developers to work on.
   6. You can additionally get it to run Nessus as well to look at
   infrastructure vulnerabilities (note Nessus is now closed source...but
   openVAS is the opensource fork).

*That are the interesting challenges that a team might see from this.*

And an interesting conversation today with Chris McMahon and Nikolas
Everett about this:
Right now the environment is quite public...does WikiMedia want to show
security issues in SDLC reported the same way as QA issues?

Nikolas Everett pointed out that Wikimedia could make the security issues
public and never release code unless these issues are addressed (i.e. fix
the security issue or accept the risk).

*Please note: *The results from the ZAP proxy (or whatever is decided on),
would not show in the environment as is, because you would need to tell
that system where to push the results to.

*Is there anything else that can be done?*
Yes, you could use a security based static code analyser during the SDLC,
which I have had experience with, and the results were very promising.
However it does require an on-boarding process to tune the analyzer to your
code base. By that I mean take a look at the intial findings and create
filter-sets to avoid false positives and issues you do not care about. In
many cases my team had to go back to the guys who wrote the rule packs to
improve them.

*I would like to volunteer as a security resource for Wikimedia*

Kind regards
Sherif Mansour
User:Kerberosmansour
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wikimedia.org/pipermail/qa/attachments/20140810/02aef104/attachment.html>


More information about the QA mailing list