Crawlers

A spider program, such as the free HTTrack Website Copier (https://httrack.com), can crawl your site to look for every publicly accessible file. To use HTTrack, simply load it, give your project a name, tell HTTrack which website(s) to mirror, and after a few minutes, possibly hours (depending on the size and complexity of the site), you’ll have everything that’s publicly accessible on the site stored on your local drive in c:My Web Sites. Figure 15-1 shows the crawl output of a basic website.

Complicated sites often reveal a lot more information that should not be there, including old data files and even application scripts and source code.

Inevitably, when performing web security assessments, I stumble across .zip or .rar files on web servers. Sometimes they contain junk, but oftentimes they hold sensitive information that shouldn’t be there for the public to access. One project in particular stands out. When I ran across a .zip file and tried to open it, WinZip asked me for a password. Using my handy dandy .zip file password-cracking tool from ElcomSoft (see Chapter 8 for details on password cracking), I had the password in mere milliseconds. Inside the .zip file was an Excel spreadsheet containing sensitive patient healthcare information (names, addresses, Social Security numbers, and more) that anyone and everyone in the world could access. In situations like this, your business might be required to notify everyone involved that their information was inadequately protected and possibly compromised. It pays to know the laws and regulations affecting your business. Better yet, make sure users aren’t posting improperly secured sensitive information on your web servers in the first place!

Look at the output of your crawling program to see what files are available. Regular HTML and PDF files are probably okay because they’re most likely needed for normal web usage. But it wouldn’t hurt to open each file to make sure it belongs there and doesn’t contain sensitive information you don’t want to share with the world.

Google

Google, the search engine company that many love to hate, can also be used for directory traversal. In fact, Google’s advanced queries are so powerful that you can use them to root out sensitive information, critical web server files and directories, credit card numbers, webcams — basically anything that Google has discovered on your site — without having to mirror your site and sift through everything manually. It’s already sitting there in Google’s cache waiting to be viewed.

The following are a couple of advanced Google queries that you can enter directly into the Google search field:

• site:hostname keywords — This query searches for any keyword you list, such as SSN, confidential, credit card, and so on. An example would be:

  site:www.principlelogic.com speaker

• filetype:file-extension site:hostname — This query searches for specific file types on a specific website, such as doc, pdf, db, dbf, zip, and more. These file types might contain sensitive information. An example would be:

  filetype:pdf site:www.principlelogic.com

Other advanced Google operators include the following:

• allintitle searches for keywords in the title of a web page.
• inurl searches for keywords in the URL of a web page.
• related finds pages similar to this web page.
• link shows other sites that link to this web page.

Specific definitions and more can be found at www.googleguide.com/advanced_operators.html. Many web vulnerability scanners also perform checks against the Google Hacking Database (GHDB) site www.exploit-db.com/google-hacking-database.

When sifting through your site with Google, be sure to look for sensitive information about your servers, network, and organization in Google Groups (http://groups.google.com), which is the Usenet archive. I have found employee postings in newsgroups that reveal too much about the internal network and business systems — the sky is the limit. If you find something that doesn’t need to be there, you can work with Google to have it edited or removed. For more information, refer to Google’s Contact us page at www.google.com/intl/en/contact.

Looking at the bigger picture of web security, Google hacking is pretty limited, but if you’re really into it, check out Johnny Long’s book, Google Hacking for Penetration Testers (Syngress).

Buffer overflows

One of the most serious input attacks is a buffer overflow that specifically targets input fields in web applications.

For instance, a credit-reporting application might authenticate users before they’re allowed to submit data or pull reports. The login form uses the following code to grab user IDs with a maximum input of 12 characters, as denoted by the maxsize variable:

<form name="Webauthenticate" action="www.your_web_app.com/
login.cgi" method="POST">
…
<input type="text" name="inputname" maxsize="12">
…

A typical login session would involve a valid login name of 12 characters or fewer. However, the maxsize variable can be changed to something huge, such as 100 or even 1,000. Then an attacker can enter bogus data in the login field. What happens next is anyone’s call — the application might hang, overwrite other data in memory, or crash the server.

A simple way to manipulate such a variable is to step through the page submission by using a web proxy, such as those built in to the commercial web vulnerability scanners I mention or the free Burp Proxy (https://portswigger.net/burp/proxy.html).

Web proxies sit between your web browser and the server you’re testing and allow you to manipulate information sent to the server. To begin, you must configure your web browser to use the local proxy of 127.0.0.1 on port 8080. To access this in Firefox, choose Options, click Advanced, click the Network tab, click the Connection Settings button, and then select the Manual Proxy Configuration radio button. In Internet Explorer, choose the Gear icon  ⇒ Internet Options, then click the LAN Settings button under Connections, select the Use a proxy server for your LAN radio button, and enter the appropriate hostname/IP address and port number.

All you have to do is change the field length of the variable before your browser submits the page, and it will be submitted using whatever length you give. You can also use the Web Developer to remove maximum form lengths defined in web forms, as shown in Figure 15-2.

URL manipulation

An automated input attack manipulates a URL and sends it back to the server, telling the web application to do various things, such as redirect to third-party sites, load sensitive files off the server, and so on. Local file inclusion is one such vulnerability. This is when the web application accepts URL-based input and returns the specified file’s contents to the user such as in the following example of an attempted breach of a Linux server’s passwd file:

https://www.your_web_app.com/onlineserv/Checkout.cgi?state=
detail&language=english&imageSet=/../..//../..//../..//../
..///etc/passwd

It’s important to note that most recent application platforms such as ASP.NET and Java are pretty good about not allowing such manipulation of the URL variables, but I do still see this vulnerability periodically.

The following links demonstrate another example of URL trickery called URL redirection:

http://www.your_web_app.com/error.aspx?URL=http://www.
bad~site.com&ERROR=Path+’OPTIONS’+is+forbidden.
http://www.your_web_app.com/exit.asp?URL=http://www.
bad~site.com

In both situations, an attacker can exploit this vulnerability by sending the link to unsuspecting users via e-mail or by posting it on a website. When users click the link, they can be redirected to a malicious third-party site containing malware or inappropriate material.

If you have nothing but time on your hands, you might uncover these types of vulnerabilities manually. However, in the interest of accuracy (and sanity), these attacks are best carried out by running a web vulnerability scanner because they can detect the weakness by sending hundreds and hundreds of URL iterations to the web system very quickly.

Hidden field manipulation

Some websites and applications embed hidden fields within web pages to pass state information between the web server and the browser. Hidden fields are represented in a web form as <input type="hidden">. Because of poor coding practices, hidden fields often contain confidential information (such as product prices on an e-commerce site) that should be stored only in a back-end database. Users shouldn’t see hidden fields — hence the name — but the curious attacker can discover and exploit them with these steps:

1. View the HTML source code.

   To see the source code in Internet Explorer and Firefox, you can usually right-click on the page and select View source or View Page Source.

2. Change the information stored in these fields.

   For example, a malicious user might change the price from $100 to $10.

3. Repost the page back to the server.

   This step allows the attacker to obtain ill-gotten gains, such as a lower price on a web purchase.

Such vulnerabilities are becoming rare, but like URL manipulation, the possibility exists so it pays to keep an eye out.

Using hidden fields for authentication (login) mechanisms can be especially dangerous. I once came across a multifactor authentication intruder lockout process that relied on a hidden field to track the number of times the user attempted to log in. This variable could be reset to zero for each login attempt and thus facilitate a scripted dictionary or brute-force login attack. It was somewhat ironic that the security control to prevent intruder attacks was vulnerable to an intruder attack.

Several tools, such as the proxies that come with commercial web vulnerability scanners or Burp Proxy, can easily manipulate hidden fields. Figure 15-3 shows the WebInspect SPI Proxy interface and a web page’s hidden field.

If you come across hidden fields, you can try to manipulate them to see what can be done. It’s as simple as that.

Code injection and SQL injection

Similar to URL manipulation attacks, code-injection attacks manipulate specific system variables. Here’s an example:

http://www.your_web_app.com/script.php?info_variable=X

Attackers who see this variable can start entering different data into the info_variable field, changing X to something like one of the following lines:

http://www.your_web_app.com/script.php?info_variable=Y

http://www.your_web_app.com/script.php?info_variable=123XYZ

This is a rudimentary example but, nonetheless, the web application might respond in a way that gives attackers more information than they want, such as detailed errors or access into data fields they’re not authorized to access. The invalid input might also cause the application or the server to hang. Similar to the case study earlier in the chapter, hackers can use this information to determine more about the web application and its inner workings, which can ultimately lead to a serious system compromise.

If HTTP variables are passed in the URL and are easily accessible, it’s only a matter of time before someone exploits your web application.

I once used a web application to manage some personal information that did just this. Because a "name" parameter was part of the URL, anyone could gain access to other people’s personal information by changing the "name" value. For example, if the URL included "name=kbeaver", a simple change to "name=jsmith" would bring up J. Smith’s home address, Social Security number, and so on. Ouch! I alerted the system administrator to this vulnerability. After a few minutes of denial, he agreed that it was indeed a problem and proceeded to work with the developers to fix it.

Code injection can also be carried out against back-end SQL databases — an attack known as SQL injection. Malicious attackers insert SQL statements, such as CONNECT, SELECT, and UNION, into URL requests to attempt to connect and extract information from the SQL database that the web application interacts with. SQL injection is made possible by applications not properly validating input combined with informative errors returned from database servers and web servers.

Two general types of SQL injection are standard (also called error-based) and blind. Error-based SQL injection is exploited based on error messages returned from the application when invalid information is input into the system. Blind SQL injection happens when error messages are disabled, requiring the hacker or automated tool to guess what the database is returning and how it’s responding to injection attacks.

There’s a quick (although not reliable as much as it used to be) way to determine whether your web application is vulnerable to SQL injection. Simply enter a single apostrophe (’) in your web form fields or at the end of the URL. If a SQL error is returned, odds are good that SQL injection is present.

You’re definitely going to get what you pay for when it comes to scanning for and uncovering SQL injection flaws with a web vulnerability scanner. As with URL manipulation, you’re much better off running a web vulnerability scanner to check for SQL injection, which allows an attacker to inject database queries and commands through the vulnerable page to the backend database. Figure 15-4 shows numerous SQL injection vulnerabilities discovered by the Netsparker vulnerability scanner.

When you discover SQL injection vulnerabilities, you might be inclined to stop there and not try to exploit the weakness. That’s fine. However, I prefer to see how far I can get into the database system. I recommend using any SQL injection capabilities built into your web vulnerability scanner if possible so you can demonstrate the flaw to management.

If your budget is limited, you may consider using a free SQL injection tool such as SQL Power Injector (www.sqlpowerinjector.com) or the Firefox Add-on, SQL Inject Me (https://addons.mozilla.org/en-us/firefox/addon/sql-inject-me).

I cover database security more in depth in Chapter 16.

Cross-site scripting

Cross-site scripting (XSS) is perhaps the most well-known — and widespread — web vulnerability that occurs when a web page displays user input — typically via JavaScript — that isn’t properly validated. A criminal hacker can take advantage of the absence of input filtering and cause a web page to execute malicious code on any user’s computer that views the page.

For example, an XSS attack can display the user ID and password login page from another rogue website. If users unknowingly enter their user IDs and passwords in the login page, the user IDs and passwords are entered into the hacker’s web server log file. Other malicious code can be sent to a victim’s computer and run with the same security privileges as the web browser or e-mail application that’s viewing it on the system; the malicious code could provide a hacker with full Read/Write access to browser cookies, browser history files, or even permit the download/installation of malware.

A simple test shows whether your web application is vulnerable to XSS. Look for any fields in the application that accept user input (such as on a login or search form), and enter the following JavaScript statement:

<script>alert('XSS')</script>

If a window pops up that reads XSS, as shown in Figure 15-5, the application is vulnerable. The XSS-Me Firefox Add-on (https://addons.mozilla.org/en-US/firefox/addon/xss-me/) is a novel way to test for this vulnerability as well.

There are many more iterations for exploiting XSS, such as those requiring user interaction via the JavaScript onmouseover function. As with SQL injection, you really need to use an automated scanner to check for XSS. Both Netsparker and Acunetix Web Vulnerability Scanner do a great job of finding XSS. However, they often tend to find different XSS issues, a detail that highlights the importance of using multiple scanners when you can. Figure 15-6 shows some sample XSS findings in Acunetix Web Vulnerability Scanner.

Another web vulnerability scanner that’s very good at uncovering XSS that many other scanners won’t find is AppSpider (formerly NTOSpider) from Rapid7 (www.rapid7.com/products/appspider). In my experience, AppSpider works better than other scanners at performing authenticated scans against applications that use multi-factor authentication systems. AppSpider should definitely be on your radar. Never forget this: When it comes to web vulnerabilities, the more scanners the better! If anything, someone else might end up using one of the scanners you don’t use!