<p dir="ltr">Hi Sherif, I agree with everything you put here! I put the groundwork for this into the Security_for_developers/Architecture. New features should have Selenium tests for security critical features, and I would really like to setup exactly the scenario you proposed, having automated regression testing with Zap. I've just lacked the time to do it yet.</p>
<p dir="ltr">+1 on static analysis too. I tested checkmarks earlier this year and their php 5.3 support wasn't good enough to give good results on our codebase. I'm trying to get coverty setup right now. Both are closed source so I don't like using them. Facebook's pfff has a lot of potential, but doesn't do security testing yet, and we don't have ocaml expertise to help them implement it.</p>
<p dir="ltr">So yes, I would love help! Let's get in touch next week and see if we can get you setup to help us implement the dynamic testing part. Feel free to ping me of list or on irc.</p>
<div class="gmail_quote">On Aug 10, 2014 7:24 AM, "Sherif Mansour" <<a href="mailto:cherifmansour@gmail.com">cherifmansour@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">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.<div><br></div><div><b>What can be done?</b></div>
<div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div><b>Are there tech teams working on this?</b></div><div>Yes several tech companies are using similar approaches and for inspiration I recommend that you take a look at the following work:</div><div><a href="http://www.continuumsecurity.net/bdd-intro.html" target="_blank">http://www.continuumsecurity.net/bdd-intro.html</a> <br>
</div><div><b><br></b></div><div><b>Is it open sourced?</b></div><div>Yes, and its on github: <a href="https://github.com/continuumsecurity/bdd-security" target="_blank">https://github.com/continuumsecurity/bdd-security</a><br>
</div><div>
The ZAP security proxy is also open sourced (and it:</div><div><a href="https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project" target="_blank">https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project</a><br>
</div><div><br>
</div><div><b>How does that work in practice:</b></div><div><ol><li>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).</li>
<li>
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).</li><li>The selenium scripts run and zap would run security tests off of that.</li>
<li>Additionally there would be some selenium tests that are based on security scenarios.</li><li>The security findings are reported, reviewed for false positive, the priority is set, and bug is raised for developers to work on.</li>
<li>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).</li></ol><div><b>That are the interesting challenges that a team might see from this.</b></div>
</div><div><b><br></b></div><div>And an interesting conversation today with Chris McMahon and Nikolas Everett about this:</div><div>Right now the environment is quite public...does WikiMedia want to show security issues in SDLC reported the same way as QA issues?</div>
<div><br></div><div>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).</div><div><br>
</div><div><b>Please note: </b>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.<br></div><div><br>
</div><div><b>Is there anything else that can be done?</b></div><div>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.</div>
<div><br></div><div><b>I would like to volunteer as a security resource for Wikimedia</b></div><div><b><br></b></div><div>Kind regards</div><div>Sherif Mansour</div><div>User:Kerberosmansour</div><div><br></div></div>
</blockquote></div>