Surprisingly, there were only a few changes between the 2010 Top Ten and 2013 Top Ten lists, including one addition, several reorders and some renaming. The most prevalent theme was probably that both cross-site scripting (XSS) and cross-site request forgery (CSRF) dropped in importance: XSS dropping apparently because safer scripting libraries are becoming more widespread, and CSRF dropping because these vulnerabilities are not as common as once thought. In any case, the current entries in the OWASP Top Ten Web Application Security Risks for 2013 are:
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 unauthorized data.
Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys, session tokens, or exploit other implementation flaws to assume other users’ identities.
XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation and 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.
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.
Good security requires having a secure configuration defined and deployed for the application, frameworks, application server, web server, database server and platform. All these settings should be defined, implemented and maintained as many are not shipped with secure defaults. This includes keeping all software up to date.
Many web applications do not properly protect sensitive data, such as credit cards, SSNs, tax IDs and authentication credentials. Attackers may steal or modify such weakly protected data to conduct identity theft, credit card fraud or other crimes. Sensitive data deserves extra protection such as encryption at rest or encryption in transit, as well as special precautions when exchanged with the browser.
Virtually all 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 unauthorized functionality.
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.
Vulnerable components, such as libraries, frameworks, and other software modules almost always run with full privilege. So, if exploited, they can cause serious data loss or server takeover. Applications using these vulnerable components may undermine their defenses and enable a range of possible attacks and impacts.
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, malware sites or use forwards to access unauthorized pages.
This is the fourth edition of a list that comes out every three years, and with the limited changes between 2010 and 2013 it is fair to say that OWASP’s popular Top Ten list has matured. With maturity and popularity, automation and utilities that directly address the items on the list have arrived, and some of the best are summarized in the chart below. Those of you who read Russ McRee’s 2010 Top Ten security tools article will notice that most of the tools listed here were also identified in his 2010 survey. However, my approach differs from McRee’s in terms of breadth; whereas McRee aimed to provide a different tool for each of the top ten items, I aim to provide you with a smaller number of tools that should cover most of the top ten so you can concentrate your efforts on mastering fewer tools that do more. Along those lines, it is worth noting that several of my recommended tools, notably the Zed Attack Proxy (ZAP) and new entrant OpenVAS, have increased the breadth of their services to cover more Top Ten items since their original release. In fact, it may be worth taking a closer look at additional capabilities of any recommended tool on this list because many of these tools are still under active development. (For example, WATOBO now has a SQL injection probe, although I haven’t explored it far enough to recommend it yet.)
Two main types of web vulnerability tools
If you scan the chart you will notice that two tools are mentioned the most: OWASP’s Zed Attack Proxy (ZAP) and OpenVAS. These two tools represent two different classes of application scanning that every security researcher should familiarize his or herself with. First, there are the tools that look for common misconfigurations and outdated software, including default settings, sample content, insecure configurations, and old versions that harbor known vulnerabilities. These tools are represented in the chart above by OpenVAS, an open source project with several heavyweight sponsors including the government of Germany. Similar tools include Tenable’s Nessus and eEye’s Digital Security Retina, and perhaps about two dozen more actively development open source projects and commercial products. Second, there are the tools that help dig into specific web applications by automating SQL injection, authentication, session, XSS, directory traversal, redirect and other probes for common and serious vulnerabilities. These tools are represented in the chart above by ZAP. Most of these tools, including ZAP, use a combination of a local web proxy, web session recorder, web playback and thousands of variations on input manipulation to look for vulnerabilities. Similar tools include HP WebInspect, IBM AppScan (originally by WatchFire), dozens of other general-purpose web vulnerability scanners and hundreds of specific case utilities.
Other web vulnerability tools
In addition to these two main types of tools, most security practitioners will find themselves drawn to additional tools that allow them to dig further into certain classes of vulnerabilities. For example the “other tools” in my list were selected to cover areas where I worried about the thoroughness of my main tools, or where I wanted a second pair of eyes because of the risk. Your list of “other tools” will vary depending on the specific capabilities of your main tools, the needs of your clients or employer, your available operating systems and many other factors, but I selected mine for a few specific reasons.
SQL Inject Me for #1 Injection – Although ZAP covers this, I selected a second tool to give me a second pair of eyes on this most common and deadly of vulnerabilities. (I never want to be caught with my pants down on OWASPs’ #1 vulnerability). HTTP Directory Traversal Scanner and Burp Suite for #4 Insecure Direct Object References – Although ZAP also covers this item, I like the breadth of scan and the output provided by either of these tools much more than ZAP’s breadth and output. WATOBO for #5 Security Misconfiguration – This is the highest-rated item that known vulnerability scanners like OpenVAS can detect. I wanted a second pair of eyes to make sure I am detecting more configuration issues, and to get a second opinion on questionable detects. Qualys SSL Server Test for #6 Sensitive Data Exposure – This could be my most controversial recommendation, but having dealt with the innards of SSL/TLS while developing several security products (including the FIPS 140 validation process with three different companies). I always feel like I have an incomplete picture of my SSL/TLS capabilities until I hit my app with Qualys’s SSL Server Test. None of the other local tests I’ve found (or written on my own) have quite the breadth of this hosted test. Tamper Data (Samurai WTF) and WebScarab for #8 Cross-Site Request Forgery (CSRF) – CSRF vulnerabilities can be surprisingly hard to pin down, because what often looks like a detect turns out to be false positive, and what looks like a clean access denial often really changes something interesting on the backend. To chase these vulnerabilities down (to the point where they are reproducible) you usually need to master a local web proxy that can help you manipulate specific fields. Two of the best are Tamper Data and WebScarab, and you will often find yourself switching to your favorite proxy after your main tool registers an initial detect. (Yes, I know ZAP is also a proxy, but it’s not my favorite proxy; it’s my favorite detector.)
One other tool that web security practitioners should be familiar with is OWASP’s WebGoat package. This tool isn’t a scanner, probe or proxy: instead, WebGoat is an intentionally insecure web application that we can probe with these and other web security tools.
Specific web vulnerability applications (main tools)
Deep probe into specific applications: OWASP’s Zed attack proxy (ZAP)
(Probes for Cross-Site Scripting, Injection, Sessions, Directory Traversal, Unvalidated Redirects and Forwards, and acts as a web proxy to locate CSRF and similar vulnerabilities.) OWASP has recently sponsored the development of its own web application vulnerability scanner called the Zed Attack Proxy (or ZAP for short). It automatically spiders a target URL and looks for common vulnerabilities, especially issues with cookies, headers and cross-scripting.
Installing and running Zed Attack Proxy
Download and install the program from http://code.google.com/p/zaproxy/downloads/list Run the program from your Start menu When prompted, use the wizard to create an “SSL root certificate”
Type in the URL of a target application in the “URL to attack” field on the “Quick Start” tab
To avoid unwanted attention until you know what you’re doing, please stick to “http://localhost” URLs, such as your local copy of WebGoat
Much of the power of ZAP comes from using it as an “inline” proxy rather than as an interactive application. To try this mode:
Open “Tools | Options | Local proxy” and set the proxy port to an acceptable value (8080 is the default, but if you’re running multiple proxies and web applications on your local machine, things can get a little crowded). Open your web browser and set its proxy settings to “localhost” and port 8080 (or whatever you configured). Browse to a few sites in the web browser. Flip back to ZAP. Notice that the sites you visited (and a few referenced through advertisements and inclusions) are now listed in ZAP’s “Sites” list. Click the “History” tab in the lower half of ZAP. This will show the URLs that caused content to be added to ZAP’s “Sites” list.
Once you have started to gather URLs in your sites list, you can expand, gather more information about or actively attack them.
In the “Sites” tab, find a URL of a web page that you recognize on a site that you know has more content. Select it and then click the “play” icon on the “Spider” tab at the bottom of the screen to follow the links on the page. To look for SQL Injection or XSS vulnerabilities in a page, select the URL in the “Sites” tab and right-click it to list “Attack” options. To set your attack options (e.g. to just check for XSS and avoid SQL injection attacks), select “Analyse | Scan Policy…” to turn various tests on and off.
Bad configuration and old software scanner: OpenVAS
(Probes for Security Misconfiguration, Missing Function Level Access Control, Using Components with Known Vulnerabilities.) I took my original formal security training in the late 1990s so I “grew up” on Nessus when it was still a free security scanning application. Since its switch to a commercial application, a handful of forks of the original Nessus code have carried on Nessus’s original promise of a free remote security scanner. My favorite alternative to Nessus these days is the OpenVAS project, which counts among its backers the national government of Germany. As noted in my chart above, this project is best at finding security misconfigurations, missing function level access controls (formerly known as “failure to restrict URL access”) and components with known vulnerabilities. It includes some SQL injection and other probes to test application input, but since it is mainly designed to scan networks for machines with bad configuration and outdated software, I think you should use it the same way.
Installing and running OpenVAS
The OpenVAS software is available for several popular Linux distributions including CentOS, Fedora and Red Hat Enterprise Linux. It is also available on virtual appliances for Oracle VirtualBox and EMC VMware. Once installed, a web-based interface is available to guide you through the scanning process. You’ve likely seen the types of reports that this application generates before: rating findings by severity, and ranking multiple machines from least secure to most secure depending on the number and severity of findings on each machine. For more information, please see: http://www.openvas.org/
Other top ten web application vulnerabilities utilities
Injection utility: Security compass’s SQL inject me
Even if you have moved to Chrome or Safari for your daily web browsing, it’s hard to give up Firefox entirely because of its extensive library of add-ons. One of the best SQL injection tools available today is a Firefox add-on called “SQL Inject Me” from Security Compass.
Installing and running SQL inject me
Install and run the latest version of Firefox (I am currently using v20). Install the add on from: https://addons.mozilla.org/En-us/firefox/addon/sql-inject-me/
After installing the SQL Inject Me plug-in, follow these directions to use it:
Navigate to the page or application you want to test. Right-click on the target page and select “Open SQL Inject Me Sidebar”. Once the side-bar is open, use the drop-down and buttons to perform specific attacks.
Advanced web proxy and CSRF utility: OWASP WebScarab
OWASP’s WebScarab is a Java-based web proxy that displays and allows you to manipulate the specific fields that are passed between browser and server. It is highly extensible, but you often need to know what you want to chase after and how to code to chase it with this tool. Further muddying this project is the fact that a “next generation” edition was started but has not been touched since 2011. For more information, please see: https://www.owasp.org/index.php/WebScarab_Getting_Started or https://www.owasp.org/index.php/Category:OWASP_WebScarab_Project
Insecure direct object reference utility: Burp Suite
In 2010, Russ McRee’s 2010 security tools article went into detail about how to use the Burp Suite to ferret out path and directory traversal issues. Path and directory traversal issues have been problematic for web servers and web applications since their inception, perhaps most famously in the 2000 IIS vulnerability that fed worms such as Nimda. Rather than repeat McRee’s work with Burp Suite, I will just agree that Burp Suite is good. For more information, please see: http://portswigger.net/burp/
Insecure direct object reference utility: HTTP directory traversal scanner
Another tool that I like for directory traversal issues is the free HTTP Directory Traversal Scanner by John Leitch, an independent application security consultant in Michigan.
This tool scans a given URL about ten thousand URL variants in an attempt to find a named file. It helpfully groups its results by return code and content, which makes it easy find needles in haystacks. For more information, please see: http://www.autosectools.com/Page/HTTP-Directory-Traversal-Scanner
Security misconfiguration utility: WATOBO
Russ McRee’s 2010 security tools uses WATOBO to look for security misconfiguration issues and the tool is still a good choice: it’s open source and maintained by an active community. For more information, please see: http://sourceforge.net/apps/mediawiki/watobo/index.php?title=Main_Page
Sensitive data exposure utility: Qualsys SSL server tester
I normally avoid web-based tools for application scanning for several reasons: the data may not just be reported back to me, they might be pulled or changed at any time and they need to hit an Internet-facing application. However, I recommend Qualsys’s SSL Server Tester page to test the quality of your web application’s HTTPS connection before and after deployment into production. Qualsys tests for basic quality issues such as whether your server supports SSL 2.0, which ciphers are supported, and the strength of your server certificate. It also tests more advanced quality measures such as whether or not client-initiated renegotiation is allowed and whether or not the BEAST attack would be mitigated. For more information, please see: https://www.ssllabs.com/ssltest/index.html (This is a resource hosted by a third party. For maximum protection, only allow traffic from “ssllabs.com” to the target resource until the necessary issues are resolved.)
CSRF utility: Tamper data (Samurai WTF)
A Tamper Data utility is available in the Samurai WTF collection and is part of Russ McRee’s coverage of CSRF utilities in his 2010 security tools review. The “Tamper Data” plug-in for Firefox is not currently recommended because of ongoing stability issues with recent versions of Firefox. Instead, I currently recommend configuring Firefox (or Chrome or any other web browser) to use a web proxy such as WebScarab or ZAP, and then use the functions within the web proxy to manipulate individual cookies, headers, form fields and URLs.
WebGoat: The perfect target
In addition to the top ten web vulnerability list, OWASP develops and distributes software that allows students and security professionals to practice their skills against a deliberately insecure web application. The name of OWASP’s tilting dummy is “WebGoat,” and it is available in both .NET and Java editions.
How to download, install and set up WebGoat on Windows
Although there is a .NET edition of WebGoat available for Windows platforms, I’ll stick with the Java edition in this article because the edition supports Linux and Mac OS platforms in addition to Windows. The Java edition also appears to be the more actively developed applications, as its official ambitions include growing into a security benchmarking platform and a honeypot.
WebGoat prerequisites
The Java edition of WebGoat requires Java, of course, and uses Tomcat to provide its web interface.
Download and install Oracle Java from http://www.java.com
Java Version 1.6 (a.k.a. “Java 6”) is recommended Download and install Tomcat from http://tomcat.apache.org/
Tomcat Version 6 is recommended
Tomcat Version 7 is supported but requires additional setup not documented here Once installed, open http://localhost:8080/ to confirm that Tomcat is working Once you confirm the service is working, stop the Tomcat service
How to install WebGoat
Download and unzip WebGoat from http://code.google.com/p/webgoat/downloads/list
Download the “Zip” file and unpack the contents into a local folder
Open your local folder and double-click “webgoat.bat”
A Java window labeled “Tomcat” will open and display messages Once the “Server startup in XXXXX ms” message appears, open http://localhost to confirm that you are hitting a live Tomcat application on port 80 Next, test WebGoat by opening http://localhost/WebGoat/attack. Sign on with username “guest” and password “guest” when prompted.
How to run WebGoat
Start WebGoat by opening http://localhost/WebGoat/attack. Sign on with username “guest” and password “guest” when prompted. Click the “Start WebGoat” button.
