The following tips will help your web application resist the surveying techniques we’ve described in this chapter:
• Consolidate all JavaScript fi les to a single directory. Ensure the directory and any fi les within it do not have “execute” permissions (i.e., they can only be read by the web server, not executed as scripts).
• For IIS, place .inc, .js, .xsl, and other include fi les outside of the web root by wrapping them in a COM object.
• Strip developer comments. A test environment should exist that is not Internet- facing where developer comments can remain in the code for debugging purposes.
• If a fi le must call any other fi le on the web server, then use path names relative to the web root or the current directory. Do not use full path names that include drive letters or directories outside of the web document root. Additionally, the script itself should strip directory traversal characters (../../).
• If the site requires authentication, ensure authentication is applied to the entire directory and its subdirectories. If anonymous users are not supposed to access ASP fi les, then they should not be able to access XSL fi les either.
SUMMARY
The first step in any methodology is often one of the most critical, and profiling is no exception. This chapter illustrated the process of profiling a web application and its associated infrastructure from the perspective of a malicious attacker.
First, we discussed identification of all application-related infrastructure, the services the applications are running, and associated service banners. These are the initial strokes on the large canvas that we will begin to paint as the rest of this book unfolds.
Next, we covered the process of cataloging site structure, content, and functionality, laying the groundwork for all of the subsequent steps in the web application security assessment methodology described in this book. It is thus critical that the techniques discussed here are carried out consistently and comprehensively in order to ensure that no aspect of the target application is left unidentified. Many of the techniques we described require subtle alteration depending on the uniqueness of the target application, and as always, clever inductions on the part of the surveyor will lead to more complete results. Although much of the process of surveying an application involves making valid requests for exported resources, we did note several common practices and misconfigurations that can permit anonymous clients to gain more information than they should.
Finally, we discussed countermeasures to some of these practices and misconfigur- ations that can help prevent attackers from gaining their first valuable foothold in their climb toward complete compromise.
At this point, with knowledge of the make and model of web server software in play, the first thing a savvy intruder will seek to do is exploit an obvious vulnerability, often discovered during the process of profiling. We will cover tools and techniques for web platform compromise in Chapter 3. Alternatively, with detailed web application profile information now in hand, the attacker may seek to begin attacking the application itself, using techniques we discuss in Chapters 4 through 9.
REFERENCES & FURTHER READING
Reference Link
Relevant Vendor Bulletins and Patches
Internet Information Server Returns IP Address in HTTP Header (Content-Location)
http://support.microsoft.com/ ?kbid=218180
Web Server/App Firewalls
Teros application fi rewalls http://www.teros.com F5’s Traffi cShield Application Firewall: http://www.f5.com
Reference Link
Netcontinuum Web Application Firewall
http://www.netcontinuum.com
Microsoft’s URLScan http://learn.iis.net/page.aspx/473/using-urlscan
Eeye’s SecureIIS http://www.eeye.com
Web Search Engines
Google http://www.google.com
Bing http://www.bing.com/
SHODAN http://www.shodanhq.com/
Web Crawling and Research Tools
Lynx http://lynx.browser.org/
Wget http://www.gnu.org/directory/wget.html
Teleport Pro http://www.tenmax.com/teleport/pro/home.htm
Offl ine Explorer Pro http://www.metaproducts.com
OWASP DirBuster http://www.owasp.org/index.php/
Category:OWASP_DirBuster_Project
Melissa Data http://www.melissadata.com/lookups/
Maltego http://www.paterva.com/
web4/index.php/maltego
Burp Suite http://www.portswigger.net/suite
General References
HTML 4.01 FORM specifi cation
http://www.w3.org/TR/html401/ interact/forms.html
PHP scripting language http://www.php.net/
ASP.NET scripting language http://www.asp.net/ The File Extension Source, a
database of fi le extensions and the programs that use them
http://fi lext.com/
Hacking Exposed: Network Security Secrets & Solutions, Sixth Edition, by McClure, Scambray & Kurtz (McGraw- Hill Professional, 2009)
87
3
Hacking Web
Platforms
T
he most prominent components of web applications that intruders will first seek to exploit are vulnerabilities within the web platform. The web platform is comprised of common (not necessarily commercial!) off-the-shelf (COTS) software that sits atop the host operating system but below the custom application logic. The web platform commonly includes:• Web server software (such as IIS or Apache)
• Extensions to the web server, such as ISAPI fi lters and extensions, or Apache modules
• Dynamic execution environments like ASP.NET, PHP, and J2EE (also referred to as application servers)
• Services and daemons, such as user forums or web guestbook packages
In contrast to our definition of the web platform, we consider application-layer components to be anything that is not COTS and thus unique to a particular site or application. For example, Google’s search-engine logic would be considered an application-layer component.
In this chapter, we will also focus on software defects rather than misconfigurations. We’ve done this to focus reader attention on what we believe are two separate classes of web platform vulnerabilities: issues that web site administrators and developers can fix directly, and those they must rely on their software suppliers to help fix through software version updates and patches. We’ll discuss misconfiguration vulnerabilities in Chapter 8. One last scope clarification: this chapter will focus on the nuts and bolts of web platform attacks and countermeasures, mostly using small-scale tools and techniques. Please see Chapter 10 for a discussion of large-scale automated web security assessment using web security vulnerability scanners.
Historically, web server software vulnerabilities were one of the easiest ways to exploit a web site, but more recently, many popular web server software development teams have become increasingly security conscious, primarily because their products have taken a tremendous beating from hackers for so many years. Microsoft’s IIS is the poster child for this phenomenon. Although severe vulnerabilities used to be found with startling regularity in the IIS product line circa versions 4 and 5, newer versions have been relatively untouched, thanks largely to an invigorated attentiveness to security in the IIS development process.
None of this should be taken to mean that you can ignore web platform vulnerabilities, of course. We’ve seen situations where six vulnerable web servers out of a farm of over 10,000 resulted in the total compromise of an entire enterprise network within a few days. Even worse, as we will demonstrate in this chapter, the hacking community continues to evolve their toolset to enable ever easier identification and exploitation of such faults.
This chapter will describe how to find, exploit, and defend common security vulnerabilities in the most popular web platforms. Our discussion will be organized as follows:
• Point-and-click exploitation • Manual exploitation • Evasion techniques
As always, we’ll wrap up with coverage of common countermeasures and security best practices to protect against these attacks.