Qwicap and the OWASP Top 10 for 2007

The Open Web Application Security Project (OWASP) has issued two "top 10" lists of critical web application security flaws, the first in 2004, and another in 2007. Qwicap's development began in 2003, with an early emphasis on automatically providing the security features that I had previously been required to waste time re-implementing for each web application that I created. Therefore, it was not surprising that Qwicap compared favorably with the original edition of the OWASP Top 10. With the arrival of the 2007 edition, and with Qwicap's significant evolution over the intervening years, a fresh comparison of Qwicap's abilities relative to the current top 10 threats is called-for.

Issues Summary

The table below summarizes Qwicap's vulnerability to each of the OWASP Top 10 security issues. The phrase "automatically immune by default" denotes a case in which Qwicap has no in-built vulnerability, but in which a sufficiently determined application developer could, conceivably, create one. (A system able to prevent determined application developers from ever doing the wrong thing would be remarkable, indeed.)

OWASP Issue		Qwicap Vulnerability Summary
1.	Cross-Site Scripting (XSS)	Automatically immune by default.
2.	Injection Flaws	Automatically immune by default.
3.	Malicious File Execution	Automatically immune by default.
4.	Insecure Direct Object Reference	Immune by default to direct file references. No other object type is directly supported. Also, Qwicap's application structure eliminates most cases that would ordinarily tempt a developer to expose a direct object reference of any other kind.
5.	Cross-Site Request Forgery (CSRF/XSRF)	Automatically immune by default.
6.	Information Leakage and Improper Error Handling	Automatically immune by default.
7.	Broken Authentication and Session Management	Automatically immune by default.
8.	Insecure Cryptographic Storage	Not applicable. Qwicap does not provide storage services.
9.	Insecure Communications	Secure communication (HTTPS) is a standard feature of application servers, but developers must choose to use it.
10.	Failure to Restrict URL Access	Automatically immune by default.

Issues in Detail

In the material below, the italicized quotes, and the bold/italic protection suggestions, are all from the 2007 edition of the OWASP Top 10 document, ©2002-2007 OWASP Foundation.

1. Cross-Site Scripting (XSS)

"XSS flaws occur whenever an application takes user supplied data and sends it to a web browser without first validating or encoding that content. XSS allows attackers to execute script in the victim's browser which can hijack user sessions, deface web sites, possibly introduce worms, etc." See the Wikipedia "cross-site scripting" article for more information.

There are a number of recommended practices:

• Input validation – Of the 14 methods the Qwicap class supplies for input retrieval, all but two perform automatic input validation, and then return the input as a standard Java type (int, float, String. BigDecimal, boolean etc.). Bad inputs for any of the standard types automatically cause a Qwicap web application to cease processing further inputs, embed the inputs (good and bad) into the "form" markup from whence they came, add an appropriate explanatory error message into the page markup, highlight the "form" control that supplied the bad input, transmit the page back to the client so that the input can be corrected, and causes execution of the web application to block until the next hit is received.

  The two input retrieval methods supplied by the Qwicap class that do not perform input validation are present as methods of last resort for retrieving inputs that do not correspond with any of the aforementioned standard Java types. A simple, standard mechanism (the Qwicap.rejectInput methods) is provided for rejecting bad inputs that are discovered by the web application's own input validation logic, and that mechanism triggers all of the automatic "bad input" behaviors described above. This means that authors have no motivation for avoiding input validation, even when the built-in mechanisms are insufficiently specific for their needs.

• Strong output encoding – Qwicap solves this problem automatically. Its solution is to differentiate between markup, and everything else. All objects that are subclasses of Qwicap's Markup class represent structurally valid XML, while everything else is regarded as something other than markup, and therefore is something that will be automatically HTML encoded before adding it to markup, or automatically HTML decoded upon extraction from markup. User input is supplied to a Qwicap application as String, int, double, BigDecimal, etc. objects, none of which are subclasses of the Markup class. Therefore their insertion into page markup can never cause an injection attack.

  Note: Qwicap does not prevent developers from requesting that String objects be interpreted as XML markup, but, to do so, the String objects must be explicitly wrapped in XMLString objects. (XMLString is a subclass of Markup.) So, if a developer wants to insert the literal contents of a String into markup and have it interpreted as markup, they can do so easily, but it's never the default behavior. By default, there's never any confusion about the nature of objects (markup vs. content), so it is always unambiguous to Qwicap when HTML entity encoding, or decoding, should be performed, and when they shouldn't.

• Specify the output encoding – Qwicap always specifies the output encoding of the web pages it handles, even if it has to perform a tedious analysis of the bytes of a page in order to identify the encoding of a web page that does not identify its encoding method through any of the standard mechanisms (UTF byte-order-marks, the "encoding" attribute of the XML declaration, a "<meta http-equiv="Content-Type" content='....'/>" tag in the XHTML "head" tag, etc.)

• Do not use "blacklist" validation – Qwicap never has, and never will, use any technique as half-assed as "blacklist" validation.

• Watch out for canonicalization errors – Qwicap automatically decodes inputs before validating them, or supplying them to the web application. Also, because it never loses sight of the distinction between markup and everything else, it never makes the mistake of performing extra encodings or decodings.

  Strictly speaking, determined developers can create the conditions for canonicalization errors, but it takes work. Specifically, the developer must take the time to indiscriminately wrap strings in XMLString objects before manually inserting them into a page's markup. Wrapping a string in an XMLString is only possible if the string being wrapped contains no "begin" or "end" tags, or, if it does, the tags represent a valid tag hierarchy, so indiscriminate wrapping is only possible for some strings. (In other words, eventually, an arbitrary string being wrapped will run afoul of some of those requirements, and the developer will, hopefully, notice their mistake.)

2. Injection Flaws

"Injection flaws, particularly SQL injection, are common in web applications. There are many types of injections: SQL, LDAP, XPath, XSLT, HTML, XML, OS command injection and many more. Injection occurs when user-supplied data is sent to an interpreter as part of a command or query. Attackers trick the interpreter into executing unintended commands via supplying specially crafted data."

Qwicap does not have database or directory layers, so the only type of injections it could be subject to are HTML and XML. Its protections against those are the same as its protections against cross-site scripting attacks, as discussed above.

3. Malicious File Execution

"Malicious file execution vulnerabilities are found in many applications. Developers will often directly use or concatenate potentially hostile input with file or stream functions, or improperly trust input files. On many platforms, frameworks allow the use of external object references, such as URLs or file system references. When the data is insufficiently checked, this can lead to arbitrary remote and hostile content being included, processed or invoked by the web server."

The only case in which a client may specify a file for Qwicap to act upon is the case of the standard HTTP "GET" command. Requests for files outside of the web application, or for potentially sensitive files within it (the files within the "WEB-INF" subdirectory), are caught and disallowed by the Servlet engine, e.g. Tomcat, so they never even reach Qwicap.

Developers writing Qwicap web applications could create their own malicious file execution vulnerabilities, but they'd have to invest some effort in doing so, and even those efforts might be blocked by the Java security manager, if their server has it enabled. Leaving that aside, Qwicap's design would complicate attempts to exploit such vulnerabilities, because it includes strong validation of user input (as recommended), and it requires all user input to be accompanied by a combination of page- and form-specific nonces, which means that no attempt at exploitation could be made with a static data set, because such a data set would lack the correct nonces.

4. Insecure Direct Object Reference

"A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter. An attacker can manipulate direct object references to access other objects without authorization, unless an access control check is in place."

With regard to file references, everything mentioned above in the discussion of "Malicious File Execution" is relevant. With regard to other object references – like database record IDs – because Qwicap provides no database, LDAP, etc. layers, it does not include any support for such references. Also, by always maintaining the complete execution state of its applications (not just the objects it is using, but also the local variables of its executing methods) between hits, developers have no need to embed context or state information in the pages of their applications, since they never have to rebuild that state or context. A database record ID, for instance, can kept in a local variable in the method that is sending related pages to the user (and processing the from data sets produced by those pages). So, the record ID would never leave the server. Placing it in a page would be extra, and entirely unnecessary, work for the developer, and is therefore unlikely to be a strategy that Qwicap developers would employ.

5. Cross-Site Request Forgery (CSRF or XSRF)

"A CSRF attack forces a logged-on victim’s browser to send a request to a vulnerable web application, which then performs the chosen action on behalf of the victim. [....] Applications must ensure that they are not relying on credentials or tokens that are automatically submitted by browsers. The only solution is to use a custom token that the browser will not ‘remember’ and then automatically include with a CSRF attack." See the Wikipedia "cross-site request forgery" article for more information.

There are a number of recommended practices:

• Ensure that there are no XSS vulnerabilities in your application – As discussed above, in the section devoted to Cross-Site Scripting (XSS) attacks, Qwicap has no XSS vulnerabilities by default, due to a strong markup-related data typing model, and therefore would make developers go out of their way to introduce such vulnerabilities into their applications.

• Insert custom random tokens into every form and URL - Qwicap inserts random nonces in all pages, in each "form" element within each page, and in every URL that will supply data to the web application. In principle these nonces are used only once, but the need to accept input from pages in the browser's cache (in order not to completely break the browser's "back" button) necessitates accepting some nonces more than once. Even so, the nonces remain useful security features in this case because they are not automatically submitted by the browser (as cookies are, for instance), which is enough, in and of itself, to meet this requirement for preventing CSRF attacks. In addition, Qwicap's nonces are not predictable, and, even when used more than once, they have short, unpredictable life-spans.

• For sensitive data or value transactions, re-authenticate or use transaction signing – Qwicap does not directly address these issues, because (1) it has no way of knowing when particularly sensitive operations are taking place, and (2) transaction signing requires that users be issued with hardware devices, which is beyond the scope of a software product like Qwicap. However, Qwicap does provide applications with an easy-to-use authentication/authorization interface. They can create implementations that require re-authentication, by whatever means they choose, when the application code reaches particularly sensitive areas.

• Do not use GET requests (URLs) for sensitive data or to perform value transactions – Qwicap leaves the decision about using GET or POST to web page authors. However, regardless of the method by which a data set is provided to Qwicap, the requirement that it include one, or more, valid nonces remains in effect. This prevents GET requests from being used for CSRF attacks. As the OWASP document states: "the URL may contain the random token as this creates a unique URL, which makes CSRF almost impossible to perform."

• POST alone is insufficient as protection – Agreed. However, as the OWASP document goes on to state, adding random tokens to each POST request is an effective defense. Qwicap's page- and form-specific nonces are just such tokens, and they are included, and verified, automatically.

6. Information Leakage and Improper Error Handling

"Applications can unintentionally leak information about their configuration, internal workings, or violate privacy through a variety of application problems. Applications can also leak internal state via how long they take to process certain operations or via different responses to differing inputs, such as displaying the same error text with different error numbers. Web applications will often leak information about their internal state through detailed or debug error messages. Often, this information can be leveraged to launch or even automate more powerful attacks."

The following information applies to versions of Qwicap beginning with 1.4b13(TEST-23) of 16-Jan-2008:

• Ensure that the entire software development team shares a common approach to exception handling – In many respects this is beyond the scope of Qwicap, but Qwicap does provide standard methods for reporting to users the problems created by exceptions. By default, those methods implement the best-practices described below.

• Disable or limit detailed error handling – By default, Qwicap reports exceptions only as opaque "incident codes" composed of the day's date and a random number, for example: "20080131-A073C9". The exception, along with its incident code, is recorded in the server's log files, but the user sees nothing but the incident code.

• Ensure that secure paths that have multiple outcomes return similar or identical error messages in roughly the same time. If this is not possible, consider imposing a random wait time for all transactions to hide this detail from the attacker. – Qwicap's incident codes satisfy the requirement for "similar or identical error messages". With regard to transaction duration, Qwicap imposes a random delay when reporting all such error messages.

• Various layers may return fatal or exceptional results, such as the database layer, the underlying web server (IIS, Apache, etc). It is vital that errors from all these layers are adequately checked and configured to prevent error messages from being exploited by intruders – To the extent that these errors are based on exceptions, and Qwicap's standard exception reporting mechanism is used (the Qwicap.reportException method), this requirement is satisfied by the automatic reduction of all error reports to the opaque "incident codes" discussed above. If developers go to the trouble of rolling their own error reporting mechanisms, it's up to them to implement those mechanisms in a secure manner.

• Be aware that common frameworks return different HTTP error codes depending on if the error is within your custom code or within the framework’s code – Qwicap does not do that; its error reports are placed in normal web pages, and therefore always arrive with the HTTP error code 200, which states that the request was satisfied without error. There are two exceptions to that rule: (1) when a GET request for a document cannot be satisfied because the document does not exist, a 404 ("not found") error is returned; (2) when an authentication/authorization implementation tells Qwicap that a user is not authorized to use a web application, a 401 ("not authorized") error is returned.

• Some larger organizations have chosen to include random / unique error codes amongst all their applications. This can assist the help desk with finding the correct solution for a particular error, but it may also allow attackers to determine exactly which path an application failed – While Qwicap cannot prevent developers from implementing such error reporting mechanisms, its built-in error reporting mechanism, based on random "incident codes" that change continuously, even for identical errors, gives attackers nothing to work with, while allowing support staff with access to a server's logs to readily identify the detailed log entry associated with each incident code.

7. Broken Authentication and Session Management

"Proper authentication and session management is critical to web application security. Flaws in this area most frequently involve the failure to protect credentials and session tokens through their lifecycle. These flaws can lead to the hijacking of user or administrative accounts, undermine authorization and accountability controls, and cause privacy violations."

Session management is provided to Qwicap by the application server, e.g. Tomcat. Therefore the implementation of session management should be a sound, and well-scrutinized, one.

8. Insecure Cryptographic Storage

"Protecting sensitive data with cryptography has become a key part of most web applications. Simply failing to encrypt sensitive data is very widespread. Applications that do encrypt frequently contain poorly designed cryptography, either using inappropriate ciphers or making serious mistakes using strong ciphers. These flaws can lead to disclosure of sensitive data and compliance violations."

This falls beyond the scope of Qwicap's responsibilities, because Qwicap provides no information storage services.

9. Insecure Communications

"Applications frequently fail to encrypt network traffic when it is necessary to protect sensitive communications. Encryption (usually SSL) must be used for all authenticated connections, especially Internet-accessible web pages, but backend connections as well. Otherwise, the application will expose an authentication or session token. In addition, encryption should be used whenever sensitive data, such as credit card or health information is transmitted. Applications that fall back or can be forced out of an encrypting mode can be abused by attackers."

HTTPS encryption is available, of course, because it is a standard feature of the application servers within which Qwicap applications run.

10. Failure to Restrict URL Access

"Frequently, the only protection for a URL is that links to that page are not presented to unauthorized users. However, a motivated, skilled, or just plain lucky attacker may be able to find and access these pages, invoke functions, and view data. Security by obscurity is not sufficient to protect sensitive functions and data in an application. Access control checks must be performed before a request to a sensitive function is granted, which ensures that the user is authorized to access that function."

Qwicap provides an API for implementing/supporting the authentication and authorization scheme of your choice. That API makes it possible to independently regulate access to the web application itself, and the static content within it. Access control for specific pages (in the sense of non-static pages whose input is acted-upon by the application) is not a feature offered by Qwicap, but, for security (and other) reasons, neither does Qwicap support the concept of discrete pages within a web application being accessed by a static URL, or, generally speaking, by any URL at all. In this respect, Qwicap is immune to this issue.

Normally, there is just one URL for an entire Qwicap web application. The page with which a user is interacting, therefore, is determined by the internal state of the web application, and not by the URL, or anything else over which the user might have direct control.