OWASP Security in a Continuous Integration World

This article discusses techniques used to confront web vulnerabilities using open source tools in the agile world. These experiences might not reflect the practices followed within MIMOS Berhad and may be the author’s own interpretation.

It has been a legacy ordeal to begin security testing as we move closer toward the release cycle. The reasons include security testing needing a near-production environment or the higher priority that functional tests command over security. This has in fact worked well for many years, with functional testing being a must-have and security tests recommended. But if you look at the number of security incidents being reported today, it’s obvious that most companies need a lot of improvement when it comes to the way they treat security testing. Vulnerability charts on the most-used technologies provide an idea (while sending a chill up the spine) of where we stand when it comes to software security.

The following charts use information from http://cve.mitre.org.

Microsoft – Vulnerabilities per Year

Figure 1. Microsoft – Vulnerabilities per Year

Microsoft – Vulnerabilities by Type

Figure 2. Microsoft – Vulnerabilities by Type

Let’s look at a classic example. Cloud and RAD are the talk of the town. As we all acknowledge, a company usually uses both in-house and third party tools for their projects. It’s possible to perform source code instrumentation on the in-house code to reduce vulnerabilities, even before it reaches the security test team. There’s not much that we can do about third party components, though. We have to accept them, since vulnerabilities in third party tools will be inherited by our product.

But is it possible to check for vulnerabilities in both third party components and in-house development without compromising one for the other? Read on to find out more.You’ve realised and finally convinced the others of the importance of performing penetration testing on your project much earlier in the life cycle. That’s only half of the job. Setting up the right processes and tools is another ball game altogether. Now you must create a thorough plan that fits into the development process. To complicate the matter, we all know that neither the time-to-market nor the working habits of developers can be changed so easily.The objective is to set up a security process for a company that follows agile methodology to deliver their projects, has all of their assets in the cloud, and uses various third-party components within their development cycle. The same process will still work if one or more of the parameters in the above equation is missing.

Apple – Vulnerabilities per Year

Figure 3. Apple – Vulnerabilities per Year

Apple – Vulnerabilities by Type

Figure 4. Apple – Vulnerabilities by Type

In order to adapt to agile methodology, the security process used can be broadly divided into the following:

  1. Identify the vulnerabilities to be addressed
  2. Align to continuous integration
  3. Wrappers for security automation
  4. Automated reporting

1. Identify the Vulnerabilities to Be Addressed

This discussion will limit itself to web applications. Mobile and client-server applications will deviate from this methodology depending on the platform used.

There are too many types of web vulnerabilities. It’s practically impossible to focus on all of them. We can shortlist the vulnerabilities to highlight by deciding on the following parameters:

  1. Threat agents: the actors and non-actors who access the system
  2. Attack vectors: ease of exploitability
  3. Security weakness: prevalence and detectability
  4. Technical impact: data loss, corruption, accountability, denial of access, etc.
  5. Business impact: business value of the platform and affected data

Just to give you an idea of possible web application vulnerabilities, here is one incomplete yet fairly comprehensive set: injection – File, HTML, SQL, AD, LDAP; cross site scripting (XSS); operating system and command injection; Jason, HTML, JS injection; DOM injection; CSS injection; log injection; reflected cross site scripting, cookies and headers; stored cross site scripting; cross site request forgery (CSRF); authentication bypass via SQL injection; privilege escalation cookie injection; unencrypted database credentials; directory browsing; Javascript validation bypass; application exception; unvalidated redirects and forwards; phishing; click jacking; social engineering tools; OS INT; bit flipping; memory scraping; bruteforce secret admin pages; PHP server configuration disclosure; application/platform path disclosure; HTML comments information disclosure; robots.txt information disclosure; distributed denial of service (DdoS); HTTP parameter pollution; method tampering; forms caching.

Phew! And please take note, this list does not include any of the infrastructure or cloud-based vulnerabilities that might pave the way for a new set of attack vectors on a web application.

The idea is to come up with a list of the most important vulnerabilities and safeguard against them. This is where OWASP comes in. The OWASP Top 10 report released every third year provides the top-ten vulnerabilities and recommended measures to avoid them. They also recommend a set of best coding practices to be followed which can minimize the risks of vulnerabilities.

2013 Top 10 List [1]

A1 Injection

Injection flaws, such as SQL, OS, and LDAP injection occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.

A2 Broken Authentication and Session Management

Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities.

A3 Cross-Site Scripting (XSS)

XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation or escaping. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.

A4 Insecure Direct Object References

A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, or database key. Without an access control check or other protection, attackers can manipulate these references to access unauthorized data.

A5 Security Misconfiguration

Good security requires having a secure configuration defined and deployed for the application, frameworks, application server, web server, database server, and platform. Secure settings should be defined, implemented, and maintained, as defaults are often insecure. Additionally, software should be kept up to date.

A6 Sensitive Data Exposure

Many web applications do not properly protect sensitive data, such as credit cards, tax IDs, and authentication credentials. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data deserves extra protection such as encryption at rest or in transit, as well as special precautions when exchanged with the browser.

A7 Missing Function Level Access Control

Most web applications verify function level access rights before making that functionality visible in the UI. However, applications need to perform the same access control checks on the server when each function is accessed. If requests are not verified, attackers will be able to forge requests in order to access functionality without proper authorization.

A8 Cross-Site Request Forgery (CSRF)

A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session cookie and any other automatically included authentication information, to a vulnerable web application. This allows the attacker to force the victim’s browser to generate requests the vulnerable application thinks are legitimate requests from the victim.

A9 Using Components with Known Vulnerabilities

Components, such as libraries, frameworks, and other software modules, almost always run with full privileges. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications using components with known vulnerabilities may undermine application defenses and enable a range of possible attacks and impacts.

A10 Unvalidated Redirects and Forwards

Web applications frequently redirect and forward users to other pages and websites, and use untrusted data to determine the destination pages. Without proper validation, attackers can redirect victims to phishing or malware sites, or use forwards to access unauthorized pages.

2. Align to Continuous Integration (CI)

This is a multi-step process and covers the following areas:

Phases: The components making up the security assurance for a project can be classified as:

  • Design principles
  • Static code analysis
  • External reviews
  • Attack surface analysis
  • Threat modeling
  • Cryptography review
  • Response plan

3. Attack Surface Analysis and Threat Modeling

The first three points mentioned above are a part of the regular development life cycle. Attack surface analysis is currently a manual process in which the penetration test engineer understands application environment, controls, technology, domain, and other related information from either the design document or the requirements book. This helps in creating the strategy and threat model. The seven steps of the threat modeling process are: understanding the security requirements; identifying the assets; creating the access matrix; threat identification; simulating attack scenarios; simulating test attack conditions; and reporting.

Please see Figure 5 and 6 to see what the threat model outputs might look like.

We now need to align our tools to the agile process. The main focus is to ensure the tool is able to integrate with the continuous integration solution, in our case Jenkins. We should be able to invoke the tools in serial order as soon as sanity tests are complete.

Threat modeling

Figure 5. Threat modeling

The shortlisted tools for web security testing based on OWASP’s 2013 Top 10 are:

  • A1 – Injection – SQLMap, SQLNinja, Tamper Data, W3AF
  • A2 – XSS – Tamper Data, Burp Suite, Webscarab
  • A3 – Broken authentication and session management – Hackbar, ZAP
  • A4 – Insecure data object references – Burp Suite, Webscarab
  • A5 – CSRF – Burp Suite, Tamper Data, Webscarab, ZAP
  • A6 – Security misconfiguration – Watabo
  • A7 – Insecure cryptographic storage – Ciku
  • A8 – Failure to restrict URL access – Nikto, FOCA, Wikto
  • A9 – Insufficient transport layer protection – Calomel
  • A10 – Unvalidated redirects and forwards – Watcher
  • Once the tool set has been identified, it can be integrated with the CI framework.


Threat model outputs

Figure 6. Threat model outputs

4. Wrappers for Security Automation

Shell scripts are created, which both update the tools and run them. One such code snippet is available here. This script updates all the tools on Kali Linux (penetration testing Linux distro) and starts the script with proper parameter values depending on the type of tests to be run (basic or comprehensive).

#some variables
DEFAULT_ROUTE=$(ip route show default | awk '/default/ {print $3}')
IFACE=$(ip route show | awk '(NR == 2) {print $3}')
JAVA_VERSION=`java -version 2>&1 |awk 'NR==1{ gsub(/"/,""); print $3 }'`
MYIP=$(ip route show | awk '(NR == 2) {print $9}')

if [ $UID -ne 0 ]; then
  echo -e "\033[31This program must be run as root. This will probably fail.\033[m"
  sleep 3
###### Install script if not installed
if [ ! -e "/usr/bin/mimos/agileUpdate" ]; then
  echo "Script is not installed. Do you want to install it ? (Y/N)"
  read install
  if [[ $install = Y || $install = y ]]; then
    cp -v $0 /usr/bin/mimos/agileUpdate
    chmod +x /usr/bin/mimos/agileUpdate
    #rm $0
    echo "Script should now be installed. Launching it !"
    sleep 3
    exit 1
    echo -e "\e[32m[-] Ok,maybe later !\e[0m"
  echo "Script is installed"
  sleep 1
### End of install process

### Check for updates !
if [[ "$silent" = "1" ]]; then
  echo "Not checking for a new version : silent mode."
  changelog=$(curl --silent -q http://yourgeekonthego.com/scripts/mimos/agileUpdate/changelog)
  last_version=$(curl --silent -q http://yourgeekonthego.com/scripts/mimos/agileUpdate/version) #store last version number to variable
  if [[ $last_version > $version ]]; then # Comparing to current version
    echo -e "You are running version \033[31m$version\033[m, do you want to update to \033[32m$last_version\033[m? (Y/N)
Last changes are :
    read update
    if [[ $update = Y || $update = y ]]; then
      echo "[+] Updating script..."
      wget -q http://yourgeekonthego.com/scripts/mimos/agileUpdate/mimos/agileUpdate.sh -O $0
      chmod +x $0
      echo "[-] Script updated !"
      if [[ $0 != '/usr/bin/yamas' && $ask_for_install = 'y' ]]; then
        echo -e "Do you want to install it so that you can launch it with \"mimos/agileUpdate\" ?"
        read install
        if [[ $install = Y || $install = y ]]; then #do not proceed to install if using installed version : updating it already "installed" it over.
          cp $0 /usr/bin/mimos/agileUpdate
          chmod +x /usr/bin/mimos/agileUpdate
          echo "Script should now be installed, launching mimos/agileUpdate !"
          sleep 3
          exit 1
          echo "Ok, continuing with updated version..."
          sleep 3
          exit 1
    sleep 2
    exit 1
      echo "Ok, continuing with current version..."
    echo "No update available"
### End of update process

#### pause function
function pause() {
  read -sn 1 -p "Press any key to continue..."
#### credits
function credits {
  echo -e "
            Credits To
  echo -e "\033[36m
Special thanks to:


Two things that are still pending:

  1. Automated reporting – generating dashboards and reports for both management and technical team consumption
  2. Integration with Netflix Simian Army to ensure high availability of the cloud infrastructure, also designed by MIMOS Berhad

Join me at the Agile Testing Days 2013 conference in Berlin to learn more about how the OWASP Top 10, cloud, agile, and security can be bundled together!


  1. Top 10 2013-Top 10 – OWASP, August 2, 2013,

Kiran Karnad

Proudly calling himself a hands-on lead for software penetration testing and implementation, Kiran Karnad has more than fifteen years of experience in all aspects of open source test management, data warehouse, and information security implementation. Kiran has worked with several Fortune 500 companies and mentored...
Read more about Kiran Karnad