If you’ve spent any time defending web applications as a security analyst, or perhaps as a developer seeking to adhere to SDLC practices, you have likely utilized or referenced the OWASP Top 10. Intended first as an awareness mechanism, the Top 10 covers the most critical web application security flaws via consensus reached by a global consortium of application security experts. The OWASP Top 10 promotes managing risk via an application risk management program, in addition to awareness training, application testing, and remediation. Yet, to manage such risk as an application security practitioner or developer, an appropriate tool kit is necessary. As WhiteHat Security is a significant contributor to the Top 10, I’m comfortable citing a few key elements from the 11th edition of their Website Security Statistic Report. First, “information leakage” surpassed cross-site scripting by a few tenths of a percent. The report defines information leakage as “a catchall term that describes a vulnerability in which a website reveals sensitive data, such as technical details of the Web application, environment, or user-specific data.” You’ll see how information leakage serves as a meta-vulnerability when considering the whole of the Top 10. Second, the lessons offered in the WhiteHat report are worthy of repeating as they are entirely applicable to our discussion. Lesson 1: Software will always have bugs and by extension, security vulnerabilities. Therefore, a practical goal for a secure software development lifecycle (SDLC) should be to reduce, not necessarily eliminate, the number of vulnerabilities introduced and the severity of those that remain. Lesson 2: Exploitation of just one website vulnerability is enough to significantly disrupt online business, cause data loss, shake customer confidence, and more. Therefore, the earlier vulnerabilities are identified and the faster they are remediated the shorter the window of opportunity for an attacker to maliciously exploit them. The conclusion is therefore simple: reduction and remediation of web application security flaws will shrink the number of attack vectors and improve security posture. Ground breaking, right? No, it’s old news, “security posture” is a worn out buzz phrase, and if everyone was diligent about the above mentioned reduction and remediation, we’d likely not need a Top 10 list or a 12th Website Security Statistic Report (count on one). But hey, then we’d have to find different work, right? Gifford Pinchot once said “Never bet on a race unless you are running in it.” As solutions are always better than complaints, let’s discuss how to get in the race with some tooling options as we explore each of the Top 10, but first a quick overview. The OWASP Top 10 Web Application Security Risks, as of the 2010 list, are:
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 unauthorized data.
A2: Cross-Site Scripting (XSS)
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.
A3: Broken Authentication and Session Management
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.
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: Cross-Site Request Forgery (CSRF) (UPDATE 4/21: New in-depth article on CSRF here)
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.
A6: Security Misconfiguration
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, including all code libraries used by the application.
A7: Insecure Cryptographic Storage
Many web applications do not properly protect sensitive data, such as credit cards, SSNs, and authentication credentials, with appropriate encryption or hashing. Attackers may steal or modify such weakly protected data to conduct identity theft, credit card fraud, or other crimes.
A8: Failure to Restrict URL Access
Many web applications check URL access rights before rendering protected links and buttons. However, applications need to perform similar access control checks each time these pages are accessed, or attackers will be able to forge URLs to access these hidden pages anyway.
A9: Insufficient Transport Layer Protection
Applications frequently fail to authenticate, encrypt, and protect the confidentiality and integrity of sensitive network traffic. When they do, they sometimes support weak algorithms, use expired or invalid certificates, or do not use them correctly.
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.
For nine of the OWASP Top 10 web application security risks I will suggest a tool to help you identify and mitigate these risks within your organization’s web applications and services. I will further endeavor to provide a unique tool for each risk thus avoiding redundancy while providing you with multiple options. Following is a risk and tool matrix. There are a plethora of tools available to conduct this work; this is simply a list of those I have used for various engagements, research, and daily job duties. I guarantee that if you chose to you could define entirely different set of tools with which to assess these vulnerabilities. I will point you to a few very useful and related resources. Samurai Web Testing Framework (WTF) is an excellent Linux-based LiveCD distribution created by Kevin Johnson of Secure Ideas and Justin Searle of InGuardians to include what they believe are the best of the open source and free tools that focus on testing and attacking websites, selections based on the tools they use as part of their job duties. As part of the Samurai collective there is also the Samurai WTF Firefox add-ons collection which includes web application penetration testing and security analysis add-ons for your Firefox browser. My favorite platform against which to test tools and methods is OWASP’s WebGoat, a “deliberately insecure J2EE web application designed to teach web application security lessons.” I recommend WebGoat 5.3 RC1 Standard Release as the ultimate learning/teaching tool as it more lab-centric. See the download site includes guidance on solving the WebGoat Labs. Finally, FoxyProxy, part of the above mentioned collection is one of those “can’t live without” tools for me as I bounce between proxies regularly.
A1: Injection – SQL Inject Me
Most people are familiar with SQL injection as it is both prevalent and of severe impact. The Firefox add-on SQL Inject Me, part of the SamuraiWTF add-on collection, is useful to test the application you’re browsing where you can test all forms or selected parameters with all available attacks or the tool’s predetermined top nine tests. When selected from Tools, then SQL Inject Me, this tool will run as a sidebar as seen in Figure 1, including adding or removing attack strings via Options.
Figure 1 – SQL Inject Me> Results will be reported to a separate Firefox tab when the test run is complete.
A2: Cross-Site Scripting (XSS) – ZAP
The Zed Attack Proxy (ZAP), also an OWASP project, is “an easy to use integrated penetration testing tool for finding vulnerabilities in web applications.” It’s also a code fork of the Paro Proxy project (no longer supported). ZAP has ongoing support and a roadmap for future releases; expect continued feature enhancements. Version 1.2.0 includes an intercepting proxy, automated, passive, brute force, and port scanning, as well as spidering capabilities. While ZAP is capable of a variety of web application security checks, we’ll use it here to test for cross-site scripting (XSS). Be sure to define ZAP up as one of your proxies with FoxyProxy, fire it up after installation, set Firefox to run traffic through it via FoxyProxy, and set about to some testing. I pointed ZAP at my lab-installed version 3.5 of Newscoop, repaired in 3.5.1 after coordinated disclosure with the vendor. After viewing an application, the ZAP UI will populate with visited pages. I right-clicked newscoop, then chose spider. This will crawl all pages accessible per your current permissions. I typically tune my Scan Policy via Analyze to avoid unnecessary tests, and then select Scan to assess the selected application. Figure 2 exhibits the discovery of the disclosed Newscoop XSS bug.
Figure 2 – ZAP> I appreciate ZAP as much for its spidering capabilities as I do for its scanning functionality and consider it my second favorite proxy behind only Burp.
A3: Broken Authentication and Session Management
A common failing that leads to exposure via Broken Authentication and Session Management is weak protections for session IDs. They’re either often exposed without SSL/TLS, poorly stored (not cryptographically), or revealed via URL rewriting. I’ve actually seen apps where the session ID is an MD5 or SHA1 hash of the password established by the user. If an attacker is playing Man in the Middle or is able to acquire session ID via XSS, assuming it isn’t subject to replay without being reversed, one could use the Firefox add-on HackBar. Once installed, hit F9 to show HackBar, then select Encryption, followed by MD5 Menu or SHA1, then Send to, which will pull results, if available.
Figure 3 – HackBar> In addition to XSS and SQLi checks, HackBar is very useful for encoding and decoding Base64, URLs, and HEX.
A4: Insecure Direct Object References – Burp Suite
I’m of the opinion that path or directory traversal is the worst of Insecure Direct Object References when left unchecked as an attacker could gain access to the likes of /etc/passwd. While I use Burp as my primary web application security flaw analysis tool, the commercial version in particular, you can also use the free version (minus the Scanner feature) to discover path or directory traversal. Burp also runs as a proxy; again configure FoxyProxy accordingly. Fire up Burp (you’ll need Java), then point your browser at the target site. Via WebGoat, this is the Access Control Flaws – Bypass a Path Based Access Control Scheme lesson. Right-click the target URL (http://localhost/WebGoat/attack?Screen=17&menu=200) as populated in Burp’s left pane and choose send to repeater. Navigate to the repeater tab, and modify the Backdoors.html entry, as submitted to the File parameter, to BackDoors.html………………..windowswin.ini, then click go. Figure 4 clearly indicates that we’ve acquired direct access to the host system’s win.ini file.
Figure 4 – Burp> An attacker would clearly use a more harmful string (think the SAM) if attacking your Windows based web server.
A5: Cross-Site Request Forgery (CSRF) – Tamper Data
There is one tool with which I test for cross-site request forgery (CSRF) flaws than any other: Tamper Data. Also one of the SamuraiWTF add-on collection, Tamper Data makes interacting with web forms incredibly simple. Targeting an arbitrarily renamed application (GalleryApp), I used Tamper Data to determine that GalleryApp was susceptible to CSRF attacks via all parameters submitted to the admin.php script. Such CSRF vulnerabilities allow the ability to create or delete accounts by tricking an administrative user into visiting a malicious web site. With Tamper Data running (in Firefox: Tools then Tamper Data), I visited my GalleryApp test instance. To validate the CSRF vulnerability, I first created a second user, selected Start Tamper in Tamper Data, and then choose to click Delete to analyze the POST parameters submitted to complete the action. As the application makes use of common logic it assigned the second user an id of 2. Logic like this allows for predictability that an attacker can make quick use of as seen in Figure 5. Again, note the absence of a token/formkey of any kind; this is often a key indicator that CSRF vulnerabilities exist.
Figure 5 – Tamper Data> My attack proof of concept took the form of an HTML page that included a form with name (deleteID) and action parameters, as well as a POST method and hidden inputs. To round out the effort, the page included script for a quick timing delay and document.deleteID.submit(); to complete the intended task. As seen in Figure 5, to complete my validation with the values seen via Tamper Data, the hidden input included: Passing a value of my choosing via my POST form allowed me to create a privileged user, a directive issued in the context of the authenticated user, at my bidding.
A6: Security Misconfiguration – Watobo
Watobo enables security professionals to perform highly efficient, semi-automated web application security audits and is a good tool for discovering certain misconfigurations in addition to other audit functions for the likes of XSS and SQLi. I used it against one of my lab servers that is intentionally vulnerable as intended for convenient, internal use only. As this would be the text book definition of security misconfiguration were it to be exposed to the Internet, I pointed Watobo at it for an “audit.” Watobo runs as a proxy, and is Ruby-dependent so you’ll need a Ruby interpreter on your system. Configure FoxyProxy to push traffic to Watobo over default port 8081. You’ll need to define a Project, then a Session, then browse to your target site via you browser of choice. Select the target, then the big green arrow (it’s that easy). You’ll need to define scope; I selected Apache, Misc, and File Inclusion. Figure 6 exemplifies the directory listing finding, a common security misconfiguration.
Figure 6 – Watobo>
A8: Failure to Restrict URL Access – Nikto/Wikto
It’s one thing to ensure that your app check URL access rights before rendering protected links and buttons, but if the application doesn’t perform similar access control checks each time these pages are accessed attackers will be able to gain access to these hidden pages, particularly of the application hierarchy is well known (think WordPress) via tools such as Nikto or Wikto (Nikto-like GUI for Windows).
Nikto, from cirt.net (whose motto is; suspicion breeds confidence), is a “web server scanner which performs comprehensive tests against web servers for multiple items, including over 6400 potentially dangerous files/CGIs, checks for outdated versions of over 1000 servers, and version specific problems on over 270 servers.”
Nikto requires a Perl interpreter. Running it on a Linux system is as simple as ./nikto.pl –h
Figure 7 – Nikto> You’ll have some definite false positives with Nikto, but you’ll also pull some gold from that pan. Note the bottom of Figure 7 wherein it recommends restricting access.
A9: Insufficient Transport Layer Protection – Calomel Add-on
Describing Insufficient Transport Layer Protection is easy enough. You’re not using SSL. See how easy that was? Lots of web application security testing tools let you know when you’re application fails to utilize SSL/TLS where recommended (think administrative or login functions) or is using a lesser version (SSL v1 or 2). Another interesting Firefox add-on, this one not in the SamuraiWTF collection gives excellent feedback on a certificate’s status. As an example, the Calomel add-on quickly noted that my own self-signed cert for holisticinfosec.org is total crap (it’s for me, not for you) as seen in Figure 8.
Figure 8 – Calomel> Calomel will validate the grade of security of the SSL connection and the toolbar button will change color depending on the strength of encryption from red (weak) to green (strong). All the certificate state details are offered in drop down window as well.
A10: Unvalidated Redirects and Forwards – Watcher
Watcher is Chris Weber’s Fiddler add-on (IE only) and works incredible well as a passive analyzer. Also useful for spotting the above mentioned transport layer issues, Watcher also nabs open redirects and forwards should you be running Fiddler with Watcher as you browse. Once installed along with Fiddler using Watcher is as easy as ensuring that IE traffic proxied through Fiddler and that Watcher is enabled in Fiddler. Then browser your target site and interact; Watcher will monitor and alert passively as seen in Figure 9.
Figure 9 – Watcher Open redirects are problematic as they make it even easier for phishers to exploit their victims given that URLs appear to originate from known good sites. If you’re ever bored and want to see how widely available open redirects are, try this Googledork: inurl:”redirect.asp?url=”. Honorable Mention: W3AF, skipfish & Websecurify I’ve used all of three of these tools and like them very much; I quite simply didn’t find a spot to squeeze them in for this article. I’ve covered skipfish before in my monthly column in the ISSA Journal. Tools such as these are comprehensive in their checks and offer similar functionality and features albeit with different approaches and interfaces. The Web Application Attack and Audit Framework or W3AF is also preinstalled on SamuraiWTF, another good reason to grab that LiveCD iso. Cooler still, W3AF even includes an OWASP_TOP10 profile to allow you to run a predefined audit against an application for all Top 10 concerns.
Summary
I recommend reading the OWASP Top 10 wiki in full before you begin testing as it will give you the full complement of details specific to vulnerabilities, impact, severity, mitigation, and remediation. Remember the standard cautions: don’t unleash these tools on sites or applications that aren’t yours. The easiest approach to getting started is with two virtual machines, one running SamuraiWTF, the other any system capable of hosting WebGoat. I recommend a LAMP-capable VM in order to install any number of vulnerable or yet-to-be-discovered as vulnerable web applications. Update me on your progress driving improvements to your organization’s web applications, and let me know if you have questions via russ at holisticinfosec dot org. Cheers, and good luck. Would you like to test your skills further with a CTF challenge? Check this out:
