Computers, Programming, Technology, Music, Literature

Archive for July 2015

Leveraging Open Source for Continuous Application Security at Agile Continuous Integration and Continuous Delivery environments

leave a comment »


This post is an abstract of my submission to nullcon 2015.


With more and more web applications enabling us to converse, communicate, conspire, collaborate, contribute, capture, compute, credit, conjure, and even keeping us content; more and more trivially insecure vulnerabilities are left to be exploited. With development teams always confronted with deliverables and ever faster imminent deadlines, they always see penetration testers as blockers because when a developed application is penetrated and vulnerabilities are identified the effort to fix them surges and it just would have been downright child’s play, had those bugs been identified early in development cycle when features of the application were being built and tested. As deployment dates near, most raised security bugs still remain raised, the critical and some lucky high risk bugs are fixed, but stakeholders accept medium and low risk bugs as technical debt, our vulnerable application meets the world wild web.

The early feedback cycles introduced by Continuous Integration systems have proven that when software development teams are faced with bugs, and build failures, they have always stepped up with early fixes. In the same way a system with Continuous Security aims at a transparent security governance of application development, making security visible at all levels – development, quality, compliance. As ‘tools in the market can’t oust human intelligence at penetration tests’ stands as an immutable fact ‘tools are used to automate and identify recurring and routine security bugs and complement manual audits’ also stands true. Sure, there are security wary development firms that use penetration testing tools, part of their development cycles. However, there hasn’t been a rapid adoption of automated tools in the rapid and agile application development processes. The primary answer could be cost, time, effort, lack of security awareness, fear of introducing more bugs trying to fix an existing bug, habit of responding to latest threats instead of proactive measures. Even some of the free and open source offerings lack support, active development community, documentation, usability, scripting support.

Bugs are something that frightens every developer and tester. Working with development teams of various sizes it is evident that the earlier the bugs are identified the easier they are to fix. While the proposed idea might look familiar or said before or may be even some of the organizations have expensive tools deployed to identify bugs every night, they are no extra steps taken to get a developer’s attention. Nothing could be more embarrassing for a developer to have broken a build and notified about the bugs. Getting a developer’s attention with build notifications and failures, getting the identified bugs fixed, keeping the source control free of the common security vulnerabilities at the cost of free and open source software with a generic platform agnostic approach is different and innovative about this paper. Also the sample source that accompanies this abstract would help many needy security analysts and developers to understand how Continuous Application Security could be done, and actually implement Continuous Application Security for their web applications.

This paper proposes a generic framework/approach with open source options to integrate vulnerability analysis as a daily chore during web application development and maintenance. The fundamental idea is to integrate a custom pipeline build script or use the boilerplate code accompanying this paper into the build system; the custom pipeline build script henceforth referred to as the CPBS. Based on the vulnerabilities found the CPBS would update the build system for success or failure. Conditional action should be taken to keep the new checked in code into the version control system or discard it or to stop a production deployment for continuous integration or continuous deployment setup respectively.  The CPBS sequence follows a work-flow of starting our security tools on a port to listen; attempts a health check on the website Url and keep polling until the website services are up; excludes urls that destroy active sessions; if a functional test suite is available, monitors and waits for the functional tests to complete; lets the security tool analyze the traffic and sense vulnerabilities based on passive scanning; starts a webdriver script to create an active session for the application; apart from the urls obtained while the functional tests were running, fires up the spiders to crawl for more resources; sets the desired scan policies and starts the scan; sends success or failure code based on the results.

Embracing automated functional tests within the Vulnerability Analysis process, handling authenticated resources and login protected websites, handling intensive client side scripts with JSON or single page web applications, handling CSRF tokens, handling iterative and incremental scans, false positive management, promoting security culture and governance in the organization, managing identified bugs in tracking systems, keeping the code in version control systems free of security bugs are some of the key areas of focus.


Written by gmaran23

July 16, 2015 at 1:56 pm

Penetration testing vs Vulnerability Analysis

leave a comment »


So we are talking about penetration testing and we are talking about vulnerability analysis.

Think about a bank job – movies like Dog Day Afternoon, Inside Man, American Heist or the 1995 movie Heat. Before the bank robbers penetrate into a bank, they recon the place for days and days together, and look for vulnerable spots, study the building schematics so they could make use of a weakness or a couple of weaknesses to penetrate in to the bank – get in and out sometimes without leaving a trace and sometimes with damages to the banks’ property.

Think about a web application that has a weakness in output encoding, an attacker could exploit this weakness and try to hijack sessions, do a Denial of Service, change web page content, include key loggers, steal information, serve malware and so on. Think about an another application that takes user input, does not validate it and concatenates into a SQL statement, an attacker could exploit this weakness and try to access confidential data from database, hack into the company’s corporate network, or sabotage systems.

Identifying vulnerabilities like encoding mistakes (XSS), concatenation mistakes (Injection) are done during a vulnerability analysis. Identified vulnerabilities could then be exploited leading to a successful penetration.

Often in terms of computer hacking,  penetration testing (aka pen testing) is an activity where a person (that is called a penetration tester) tries to penetrate (or hack into) a particular resource/system. In order to do that the penetration tester often analyzes the system/resource for vulnerable spots that could lead a way in. Hence vulnerability analysis (VA) is done to identify weak spots in an application. The results of a vulnerability analysis (VA) could be used for an effective penetration testing (PT).

Written by gmaran23

July 15, 2015 at 8:55 pm

Downloading and Building OWASP ZAP source from Github using Eclipse IDE

with one comment


Download this blog as PDF – 


This is a quick and dirty blog for those that are new to Eclipse IDE and want to try tweaking the OWASP Zed Attack Proxy’s code. I must say that that you might stumble upon this well written guide titled “Building OWASP ZAP Using Eclipse IDE for Java… Pen-Testers” here - . First time I was trying to build ZAP with Eclipse this guide was my complete reference. However, OWASP ZAP’s code was recently move to GitHub in the month of May-June 2015 rendering that guide obsolete and my OWASP ZAP Eclipse workspace – connected to google code SVN – a little defunct. Raul Siles, the author of the above guide would update it for changes with respect to the GitHub move.

Recently I was trying to download OWASP ZAP’s code from GitHub and build it because the existing code from SVN (google code) went obsolete. I am not an advanced Eclipse user or Java developer and I was a little lost trying to clone the new OWASP ZAP GitHub repo to my Eclipse. As I was trying, I took screenshots and ended up posted in this blog. Remember, this blog is not a step by step instruction, but it is a quick and dirty steps (5 major steps) to get OWASP ZAP’s code running in your Eclipse IDE.

Glimpse through the articles titled

  1. Building OWASP ZAP Using Eclipse IDE for Java… Pen-Testers
  2. Building ZAP (,
  3. Downloading and Building OWASP ZAP source from Github using Eclipse IDE (this article)

and I am sure you’d get ZAP running on your Eclipse IDE.


Download Eclipse

…  from If you are confused which edition to download, pick the Eclipse IDE for Java Developers



When you open Eclipse for the first time choose the default workspace and proceed. If you’d like create a workspace such as workspaceowaspzap like I did. Refer to Raul Siles guide for workspace screenshots.

Make sure you have EGit plugin installed. If you are a prime time command liner with Git you may not need this plugin.

If you have downloaded Eclipse from Eclipse for Java Developers, then please ensure in the Eclipse Installation Details you have the below three components highlighted

  1. Eclipse Git Team Provider
  2. Java Implementation of Git
  3. Mylyn Versions Connector: Git

At the time of this writing Eclipse IDE for Java Developers comes with all required plugins to work with Git ( and hence GitHub)



Add a Git Perspective

… to view Git Repositories and stuff..bla bla

Hit the Open Perspective button at the right top corner 


Choose Git at the Open Perspective Dialog


Hit OK to view the Git Repositories view.


Tip: From time to time you could hit the Java perspective to view the Java related tools and views, you could hit the Git perspective to view your Git Repositories.



If you look at the workspace that we choose when opening Eclipse, in Windows Explorer now it just has one folder named .metadata. Time to download the code from 




Downloading the OWASP ZAP’s code

Choose File –> Import


Select Team –> Team Project Set. Hit Next.


In the Team Project Set Dialog, Input the Url – 
and hit Finish.


Tip: Always refer to the recent project set Url available at




Wait for the ZAP projects to be downloaded and built

Watch the progress as the Git Repositories view would show projects as and when they are downloaded


Once all the ZAP projects are downloaded, your workspace the Git Repositories view should look like below. The approximate size of the workspace with all the ZAP coded summed up to 2.27 GB for me (on July 4 2015).



Run ZAP’s source and start playing (and contributing)

Switch to the Java perspective


In the Package Explorer, right click zaproxy and choose Run As –> Java Application


Eclipse would search for the Main types. In the Select Java Application dialog choose ZAP and hit OK


Witness the Console Logs


Start ZAPping



Tip: You can also start ZAP by hitting the play button in Eclipse


If you encounter any problems, try fixing it yourself first – spend a day or two Winking smile, as a last resort – post at the ZAP Developer group here –!forum/zaproxy-develop

Written by gmaran23

July 5, 2015 at 1:25 pm