Web Application Auditing:

From HORSE - Holistic Operational Readiness Security Evaluation.
Jump to navigation Jump to search

Web Application Auditing

Web applications are most frequently the weakest link of any network environment. A Web application has to be accessible to all of your customers and employees. TCP Ports 80 and 443 must be open to the global community to provide ubiquitous access to your company's web applications. The trouble is that in general, these feature-rich web applications are connected to the Corporation’s database storing a plethora of information such as employee, customer, order, and pricing information. The implication is that these web applications become the shortest paths for an attacker to take to reach the organization’s crown jewels. Securing web enabled applications is critical and by no means an easy task. Outlined below are some simple steps to audit the security of a web application. Be prepared! While this audit is very simple and far from comprehensive, many of your flagship applications will not pass this test. A more complete audit will include source code reviews and other more advanced techniques to circumvent security measures.

NOTE: You will need WRITTEN permission from your company to perform this audit. Failure to obtain such permission may get you fired and or prosecuted.

Your First Steps

Let's not forget the obvious. A quick portscan with product such as nmap may reveal an unprotected VNC server or a database server with no password. Any penetration test should start with a quick portscan, likely followed by a vulnerability scan with a tool like Nessus. The use of a more web-specific scanner (like Nikto) will save you a lot of tedious work. Nikto, in particular, is good at scanning for common problems like default installations of vulnerable tools, outdated versions, and left-over backup and configuration files.

Tools

Before we get started, let's talk about some tools. In order to perform your audit, you need appropriate tools to attack the application under test. You already have the most important tool for auditing web applications: a browser. If you use Firefox, you will be able to use a number of free toolbars that will make it much easier to launch the attacks outlined below.

The following plugins are recommended:

  • Web Developer toolbar (https://addons.mozilla.org/firefox/60/) A Swiss Army knife-like extension every Web developer should have installed. For our purposes, the important feature is the ability to modify forms on the fly to remove some of the restrictions imposed by forms. For example, you are able to enter strings beyond the designed length, or you are able to edit locked fields.
  • Hackbar (https://addons.mozilla.org/firefox/3899/) Nice tool to decode Base64 and URL Encoding. It is also helpful in obfuscating SQL injection attacks.
  • SwitchProxy Tool (https://addons.mozilla.org/firefox/125/) If you decide to use a proxy server like WebScarab, Switch Proxy allows you to quickly switch proxies.
  • Add N Edit Cookies (https://addons.mozilla.org/firefox/573/) The Add N Edit Cookies cookie editor will allow you to edit cookies on the fly. This tool gives you one less reason to require a full proxy server to intercept requests.
  • Tamper Data (https://addons.mozilla.org/firefox/966/) This extension, much like a proxy server, will allow you to intercept requests and responses. Either may be manipulated at will.


These toolbars allow you to do most of what is required to quickly test a web application. However, for some of the more advanced techniques, the usage of a proxy server can be helpful.

Probably the most full-featured free proxy server for auditing purposes is WebScarab (http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project).

The Open Web Application Security Project (OWASP) web site is also a good resource to learn more about web application security.

Preparation

Before you start, configure your browser to show hidden fields and comments and to ignore form limits. This will make some of the tests discussed later a bit easier to complete. Here is how to adjust the Web Developer toolbar:

In the Options menu, select Persist Features. This will make your selections stick, so you don't need to adjust them for each new page.

Now move to the Miscellaneous menu and select Show Hidden Elements as well as Show Comments. In Forms, select Make Form Fields Writeable and Remove Maximum Length. Later, you may want to use the Convert POST to GET function to make it easier to manipulate form content.

As a quick test, start browsing the site you are testing and become familiar with it. You will see yellow exclamation marks within the web page displayed by Firefox whenever there is a comment. The current version of the Web Developer toolbar appears to have a bug in that the hidden fields are not shown all the time. It may be easier to use WebScarab if you find a lot of hidden fields, because WebScarab will make them editable.

In a worst case scenario, you will find things like passwords or account names in comments listed in the Web Developer toolbar. At this point, your quick audit would likely be complete. There is no need to go any further if the goal is just to show that a side is vulnerable.

The Audit

With browser and toolbars ready and armed, we are all set to dive into the actual audit. The steps below are listed in the order in which they are most likely to deliver results, staying with our theme to find problems quickly.

  1. robots.txt: A vulnerability roadmap. The robots.txt file is often misunderstood by Web developers. The file will not protect or hide content. It is only used by well-behaved search engines to avoid indexing content that should not be indexed. A good robots.txt file includes content like image directories or locations that are generated dynamically and do not work if a search engine accesses the page. A bad robots.txt file, on the other hand, will list admin pages, Web logs, and similar locations. Access all the locations listed in robots.txt and see what you find. If, as part of this experiment, you hit a page with Web logs, browse the Web logs for any administrative pages. If they are not obviously named /admin, look for pages hit by only very few hosts. Your quest to prove that the web application is vulnerable may already be over if you find a non-password-protected admin page. For each password-protected admin page, try a few obvious username/password combinations. But don′t spend too much time on it. After all, we only have 1 hour to break the site.
  2. XSS: trial and error. Cross site scripting (XSS) is probably the most common vulnerability. Not all XSS issues are easily exploitable. However, the presence of these errors demonstrates lack of attention to input validation and output sanitation. The most likely place to find XSS is in the search function. Enter a "e;>"e; as a search string and see what you get. In particular, watch for pieces of HTML code that may all of the sudden be visible or for skewed formatting in forms. As a next step, enter "><script>alert("xss")</script>. Even if you don't see the popup message, try to find the string in the result. See how the application dealt with the quote. As a note, many applications will escape single quotes (′) but not double quotes ("). If you try to inject JavaScript, you may need to use double quotes only. Again, for this 1 hour exercise, we are only trying to find XSS problems. Exploiting them may take a bit more time. More dangerous XSS issues arise if content is stored in a database and not escaped properly if returned. The most likely location for this XSS vulnerability is any mailing or shipping address. Try to set up an account with the Web site, and use > or similar strings as street or city name. These issues are almost always exploitable to retrieve administrator cookies because they retrieve addresses for order fulfillment or customer service.
  3. SQL Injection: trial and error. The procedure to find SQL injection is similar to what we did for XSS. Start by entering a single quote in various form fields. As an indication of SQL injection is going to be possible, you may see a database error returned. Once you have the database error, it should tell you more about the nature of the problem. Some Web sites do a decent job of hiding the error messages. In this case, SQL injection is a bit more tricky. Try to guess a valid, but bad, SQL query. For example if you get an error for page.html?id=1′ , try page.html?id=1%20or%201 and page.html?id=1′%20or′1′=′1 or page.html?id=1-- to see if you still get the error page. This can easily be the most time-consuming part of the audit. If you suspect SQL injection issues, try to use a tool like Paros, which can assist you in finding SQL injection problems. In addition to the obvious quotes, try to use characters like double-dash (--), semi-colon (;) or comma (,). Blind SQL injection, which is frequently necessary if no error messages are displayed, is a more advanced topic and is beyond the scope of this paper.
  4. Cookies and Hidden Fields: Cookies and hidden form fields are just another form of user-provided input. However, a lot of Web developers don't see it that way and treat cookies and hidden fields as trusted data. So, if you are still looking for vulnerabilities, try to inject some single quotes and XSS characters and see what you get. The Add N Edit Cookies toolbar is all you need for this. The Web Developer toolbar will allow you to edit hidden fields that you find.
  5. Sessions: With sessions, you will find developers who are using a standard toolkit, in which case the sessions are likely reasonably secure, or you will find developers using homemade toolkits that are frequently flawed. Take a look at the session ID. Does it look like a long random string? Start playing with it. Remove and add characters. Again, try to add a single quote or XSS. Is the text cleaned up? If your session ID is numeric: Try to replace the session ID with the next number. Also, try and increment the last two numbers by 1 each (in case the last digit is a checksum). Are you able to get someone else's session? At the very least, your session ID should change after you log in. In the best case scenario, the session ID should change on each page view. Webscarab can help with session ID analysis if you need to dive in deeper. Webscarab is a proxy server. It can be configured to intercept all data passed to the server or to the browser. Before it passes the data to the server or browser, the user can edit the data at will. Webscarab offers a large number of additional features to analyze the content passing between browser and server. The session ID analysis is one of these features. Session ID analysis will graph session Ids collected from the website to make it easy to spot patterns.
  6. Google Hacking: Take a look at Google and check what it knows about the site. You can limit Google's focus by adding a?site:example.comato the search. Strings to search for include: "sql", "error", "password", "cvv2".
  7. Spidering: Run wget -m http://www.example.com to retrieve a mirror of the site. This will cause wget to create a directory called www.example.com. Use grep to find any errors or other odd contents like error messages or comments. This is essentially the same thing the Google search will do, but grep is more complete. Note that Google as well as wget obey robots.txt. At this point, you are likely a bit more familiar with the application you are testing. Google can help to find default locations for configuration files (e.g. global.asa) or administrative consoles for the particular Web application.

Conclusion

These tests will only find obvious problems and are less likely to find more complex issues. We totally neglect some common problems like response-splitting or secondary SQL injection issues, and we spent little time on actually exploiting these problems. See this 1 hour audit as a due diligence test that should be done periodically. It is also a great learning tool for Web developers. By involving them in such an audit, they will find out more about how easy it can be to exploit some of the problems the audit identifies. Have them actually perform the test or perform the test with them. If they are part of the audit team it will be much easier to explain what is going on and they won't see the test in a confrontational manner.

In order to do a more exhaustive test, it is highly advisable to use the source code for the Web application. Again, this is easy if you have cooperating Web developers. With source code, it is much easier to validate a problem and estimate its impact.

Not much about how to defend against each of these tests has been presented. However, the persistent approach should not be to fix vulnerabilities one at a time as they are found, but to develop strategies and procedures that will prevent these vulnerabilities in the first place. It is imperative for a web application developer to create a library kit of authentication, access control, session handling, and validation functions that are used consistently throughout the application.

References

http://www.owasp.org: Open Web Application Security Project.
http://www.cgisecurity.com/articles/xss-faq.shtml: The Cross Site Scripting (XSS) FAQ
http://www.spidynamics.com/papers/SQLInjectionWhitePaper.pdf": SQL Injection White Paper
http://www.robotstxt.org: The Web Robots Page
http://johnny.ihackstuff.com: The Google Hacking Database

Retrieved from "http://horseproject.wiki/index.php?title=Web_Application_Auditing:&oldid=3930"