The Web Content Accessibility Guidelines 2.0 (WCAG 2.0) have created some challenges for those who wish to meet the criteria and also develop to high web security standards.

The WCAG 2.0 became a full W3C Recommendation in December 2008 (see Accessibility and Security Roundup). The WCAG 2.0 contain much more related to transactional systems and there are many criteria which existing development frameworks are unlikely to meet. Inflexible generic methods for navigation, data entry and validation will not always be possible—the context is so important in consideration of accessibility.

The four principals (perceivable, operable, understandable and robust) comprise 12 guidelines and associated testable success criteria. The most difficult issues are related to the highest level of conformance. There are still three conformance levels—A (lowest), AA, and AAA (highest).

The Techniques for WCAG 2.0 are worth reading as these give a guide to developers as how some of the success criteria could be achieved and checked.

Session management

The following are of particular interest:

• G5: Allowing users to complete an activity without any time limit
• G105: Saving data so that it can be used after a user re-authenticates
• G133: Providing a checkbox on the first page of a multipart form that allows users to ask for longer session time limit or no session time limit
• G180: Providing the user with a means to set the time limit to 10 times the default time limit
• G181: Encoding user data as hidden or encrypted data in a re-authorization page
• G198: Providing a way for the user to turn the time limit off
• SCR16: Providing a script that warns the user a time limit is about to expire

Session management where authenticated users are authorised to perform certain actions is a fundamental building block of web application security. There are potential issues here if tokens are not expired on time out and log out. This is a particularly important issue on shared computers.

Data entry

And for data entry and validation, the following techniques have security implications:

• G89: Providing expected data format and example
• G155: Providing a checkbox in addition to a submit button
• G98: Providing the ability for the user to review and correct answers before submitting
• G139: Creating a mechanism that allows users to jump to errors
• G177: Providing suggested correction text
• G99: Providing the ability to recover deleted information
• G75: Providing a mechanism to postpone any updating of content
• G76: Providing a mechanism to request an update of the content instead of updating automatically
• SCR18: Providing client-side validation and alert

Getting data entry, checking, confirmation and validation correct is key, and I like the empahsis being placed on this aspect, but there are dangers in poorly thought-out implementations. More accessible web applications are better for everyone—not just people with less experience, knowledge or ability.

Final thoughts

Overall, WCAG 2.0 increases the complexity of specification, design, development and testing of web applications. Many of the techniques could introduce security vulnerabilities, and the listed techniques could be used to develop misuse test cases.

I'm pleased to see in one of the script examples:

Very true.

Update 19th May 2009: See also What's the Scope for Accessibility Testing? and Can An Accessible Web Application Be Secure? concerning my presentation at OWASP AppSec EU09.

Happy new year. In a recent edition of a mobile phone provider's newsletter for business customers, it heralded the growth of mobile applications.

Regarding Nokia's purchase of the Symbian mobile operating system and making it free to other mobile manufacturers in an attempt to combat Google's Android mobile phone operating system. The newsletter mentions that an advantage of Android being an open source platform:

Armageddon perhaps?

Input data validation is a fundamental practice that web applications need to get right to protect users, their data, your data and your web site. But free text entry fields in web forms can be problematic - we all make mistakes, misread the instructions, type in the wrong fields, avoid filling in the mandatory items and so on. But how should the web application respond to these?

Users can submit data to web applications in many ways - file uploads, page requests, URL parameters, form parameters, file uploads, request headers, cookies and so on, but it is in conventional forms where we need to be somewhat lenient in how we respond to data validation issues.

Form data must be checked for integrity, business rules and validity of the following:

• Required (whether the field must be submitted, not null)
• Type (e.g. positive integer, text string, date, true/false boolean)
• Length/Range (e.g. numerical limits, number of decimal places, length of text, applicability of a date)
• Format (e.g. DD/MMM/YYYY for a date, international format for telephone numbers, allowed/disallowed characters)
• Character encoding/character set.

HTML forms allow radio buttons, checkboxes and drop down lists where the value(s) meant to be submitted are predetermined. In these cases it is reasonable that some of these failures are likely to be caused by malicious users tampering with values, or some fault in the application itself.

But what about text fields where users can enter any value in free format? I mentioned in Separate the Text from the Code a posting elsewhere about the display of form entry error messages. At what point to you reject the user input completely as malicious?

You may have mechanisms looking for dangerous input such as custom application code, an application filter module, security settings in your web server software or a web application firewall. If a user accidentally or without malice types text that could be construed as malicious because it matches a signature for something like cross site scripting or SQL injection, when they submit the form they could be presented with something much less friendly. This could occur if the control points are set to intervene rather than simply monitor, and so the 'friendly' message will never appear and they will see something else, like these three examples:

So be wary about validation and active blocking. In some cases, user data should be accepted and then sanitised before explaining the problem and possibly re-displaying their data appropriately encoded. The problem might be as simple as putting an item of text in a date field, or using an "incorrect" date format. If the filtering mechanisms are too strict, the usability of the application will be much degraded.

For each item of user input, try to identify:

1. What is allowed to be received by the web application for each field
2. Exact validation rules before the application can use, store or transmit the data value
3. Which control points will be checking and enforcing these
4. The sensitivity of the values
5. How the data will be used subsequently
6. How the data values should be encoded when output.

In some cases nos. 1 and 2 will be the same, but more often they will be different. Build these into your application test cases.

After all, some people live near "Alert Street" and "Script Drive":

For more information on integrity checks, validation and business rules, see data validation from OWASP's Development Guide. I'll discuss client-side validation, whitelisting and blacklisting in future posts.

Documenting all the inputs and outputs is a good strategy when developing a web application. Every piece of textual content should also be identified and stored centrally. This leads to consistency and means identical text can be replaced globally and alternative translations provided more easily. Remember, the context is always important in the decision how to split up text, and how to translate it.

The text of instruction, confirmation and error messages should be handled in the same way... and of course it needs to be changed to something appropriate. I came across the following rather unhelpful message in a Siebel customer relationship management system:

The users of this public system are about as likely to have its documentation to refer to as go on a trip to the moon. Perhaps during development and acceptance testing, not all possible conditions were tested, so what else wasn't checked? It seems this should instead say something like:

Of course, telling the user first there is some sort of length limitation would be better. If all such pieces of text are located in a single repository (database table, configuration file, and so on), it can be easier to ensure that any system defaults are replaced with user-friendly and understandable messages. The only saving grace here is that the message implies the system might be doing some sort of type, length checks on data input by users.

A reminder for auditors: check what default text is stored in a system. And, make sure that changes to these text items follow a change control process.

When output text is scattered through developer's code, it is not usually a good sign. Using development frameworks that already have secure and tested error handling modules and separate the logic from words and layout are the way forward.

Update 19th November 2008: Christian Watson has posted a message about Error Message Design Showcase in his SmileyCat Web Design Blog giving an overview of how many sites handle the display of form entry error messages.