Input validation and output encoding are key aspects of web application security. This morning I've just been using a data search on a website and came across this when no results were found:

I imagine "escape(escape())" is some attempt at preventing cross-site scripting (XSS), but implemented correctly. Interestingly, when search results are found there are several "-->" appearing. Another indicator of output encoding problems.

It doesn't have to be difficult - read the OWASP XSS Prevention Cheat Sheet.

Testing a web site is important, and smoke/regression testing would normally be undertaken each time the web site's code is updated or extended. But what about third party code and data on your web site? I was using a shop's store locator and it wrongly identified the two closest store locations to Farringdon Station in Clerkenwell, EC1M. Both Euston Station NW1 and Canary Wharf E14 are further away than the third result, Cheapside.

Intrigued, I zoomed in on the map and the ordering of the first two results swapped. And the data point for Canary Wharf seems to be located in the centre of the City of London, instead of its actual location downriver on the Isle of Dogs. The data point for the first result wasn't even displayed.

So is this a third party problem, or something else? Well, without investigating further you can't really tell, but it's the concept that matters.

This inaccuracy is worrying for a number of reasons:

• Customers may have difficulty locating shops.
• It undermines customer confidence and therefore trust in the brand.
• It indicates a lack of care in the web site's development and may put off online shoppers.
• It could indicate the presence of a security vulnerability which could be exploited to damage the site, its data or its users.
• The same geo-location code may be used for other internal calculations such as marketing data processing that affect business decisions.

If you are including functionality or data from third parties, you need to know when that system or service is updated. This notification requirement should be built into contracts. In this case, the data being returned may be inaccurate, formatted in an unxpected manner or be exposing a fault in your own processing of the data. Undertaking input validation on the data provided by the third party and output validation on what you are about to send back to the web site user need to test for reasonableness as well as more technical checks. Why not cross-check that the first result's postcode is closer than the second and the third?

It may just be a problem with the company's own data, but that's even more worrying.

The Interactive Advertising Bureau (IAB) and Association of American Advertising Agencies (4A's) have published a draft revised Standard Terms and Conditions for Interactive Advertising. Whilst this is principally aimed at the USA market, due to the international nature of the Internet, I thought it worth a mention here.

Use of the template (full title "Standard Terms and Conditions for Interactive Advertising for Media Buys One Year or Less") is voluntary and open to negotiation between media companies and advertisers. However it does discuss data usage and privacy. This is important if you have advertising on your own web site and need to write a privacy notice. Without knowing the agreement between the advertiser and media company, how can you inform your web site users what will happen to their personal information? Although this is only an example template, it probably contains most of the likely issues you will come across in other ones. The definitions of "user volunteered data", "performance data", "site data" and "use of collected data" probably need careful reading and advice from a lawyer! The education version provides some further explanation of terminology and the changes since the previous version.

The template also describes the "special situation of User-Generated Content (UGC) pages" on advert placement and positioning—there could be an interesting discussion if the actual content was neither that intended by the site owner, nor that added by the user, but instead was the result of some malicious injection.

There doesn't seem to be any reference to malware on the site or malware delivered by the advert.

Of course, including third party content is a risk that should be considered in itself.

Strange as it might seem, some people publish, usually unwittingly, detailed information about the structure of their databases by revealing SQL (Structured Query Language) code.

I don't mean in error messages (which should of course never be displayed to web site users):

Nor in the generated web page source code (you wouldn't do that would you?):

Nor even when it's in a URL (I won't ask):

No, what I mean is when the code is simply indexed and appears on the site's own web pages (often as search result listings), and which then sometimes subsequently picked up by Google, Bing and so on:

So what's going on here? Without more information, I can only surmise, but I think these web sites are using catalogues (pre-built registers or collections) to index the web pages. However some of the pages have static content and others are dynamically built using database queries. So the indexing tool is recording the text from the scripting language rather than what is generated "at run time" to the web site user. These scripts should not be indexed, and thus leaked, in this way; instead the static results need to be merged and ranked with appropriate links to dynamically-created pages. If I search a dictionary web site for "query", I don't want a link to a page that has this in the code, I want the actual pages that define or reference the word "query".

The danger of automated indexing, is that it can include all types of unforeseen files in its catalogue, including backup and old copies of files, unless the indexing strategy is considered carefully:

Having the SQL displayed in this manner makes it much easier for someone to compromise the data, damage the site or its users.

This weekend the clocks change as we revert from British Summer Time (BST) to Greenwich Mean Time (GMT) at 02:00 BST on Sunday 25 October 2009 and the clocks go back, giving an extra hour.

What does this mean for web site security? Does running 01:00 to 02:00 twice matter? Well some brave web application owners will be disabling their systems like this online bank:

And, I don't think it's just being done as a finale to the current Energy Saving Week. Most people, quite rightly, won't be taking this rather severe step. Another millennium bug anyone? The date/time should be considered rather like other untrusted user input. Most problems will probably fall into the "business logic" category such as:

• Failure of time-based logic where dates are being compared.
• Assumptions of uniqueness in time-stamped output (e.g. by a single-threaded process).
• Running tasks again leading to possible:
  • loss of data due to overwriting
  • duplication of exports or emails
  • creation of inaccuracies in management information.
• Chronological ordering anomalies leading to other faults.

It's not just banks and other financial organisations that may have difficulties.

The time change may expose some other vulnerabilities that only exist at changeover time and/or during the next overlap hour.

• Circumvention of brute force attacks on user authentication mechanisms.
• Increased risk due to extension of a session's validity where local time is recorded.
• Failure in data validation routines for time-related comparisons.
• Incubated vulnerabilities where a time-related aspect causes the attack to be possible.
• Denial of service due to extension of account lock-out.
• Using time as a loop counter.
• Additional errors caused by any of the above leading to information leakage.

Recording the offset of local time to GMT/UTC and synchronisation should certainly be done, but may not resolve the time overlap issues. The effects on long-running "saga" requests might be especially difficult to determine. Time dependencies need to be specified and considered through the development lifecycle. Perhaps the bank is right after all?

The news that a the UK hosting company VAServ lost 100,000 web sites all at once is devastating for the organisations involved. It appears that many cannot be recovered and a considerable number do not have recent backups.

From the temporary status page dated 10th June:

The event was widely reported:

• Webhost Hack Wipes Out Data for 100,000 Sites
• Webhost Denies Poor Passwords Led to Catastrophic Hack
• U.K. Web Hoster, Customers Scramble After Attack Deletes 100,000 Sites

Particularly sobering is the news that the CEO of LxLabs, implicated as the developers of the software that was hacked, has committed suicide:

• LxLabs boss found hanged after vuln[erability] wipes websites
• Web Hacking Incident Database (WHID) 2009-45: Outcome: Death

Even if you don't have a formal disaster recovery plan, at least make sure you have backups of all your site code, database and other data.

The poor apostrophe gets such bad press. It's implicated in so many SQL Injection problems and now it has been banned by some local councils in the UK.

Yes Birmingham City Council and Wakefield Council have been so concerned about punctuation usage they have banned apostrophes in street names and thus on road signs, according to recent news reports such as in the Daily Mail and Yorkshire Evening Post.

I wasn't able to find confirmation on the councils' own web sites—I was also hoping perhaps the council leader or spokesperson might have had an apostrophe in their own family name. Actually no members from either council have apostrophes, or any other "unusual" characters, in their names. Birmingham's web site search kindly refused to tell me anything about the apostrophe:

This has got many people bothered by the dumbing down, especially those in the Apostrophe Protection Society.

I don't think we'll be able to get away with banning characters in the web application world to prevent issues like SQL injection. Yes there are many web apps that don't allow apostrophes in submitted data rather than tackling the root cause of the weakness. The use of database commands with bound parameters combined with appropriate validation, decoding, encoding and escaping are the answers.

PS It's not just apostrophes (or single quotation marks) you have to worry about.

Enforcing complexity is one aspect of a good password policy. But web applications often implement this poorly.

Yesterday I had to change a password on a web application provided by an information security vendor. You'd think they'd have this sorted. It began promisingly:

• the page was only available on a page transmitted over secure HTTP
• the page was only available to currently authenticated users
• there was an explanation of the minimum password complexity requirements
• the form asked for the current password
• the form asked for a new password and provided a visual indicator of the password complexity (length and mix of characters)
• the new password wasn't allowed to be blank(!)
• confirmation of the new password was sought
• password fields were initially all blank and masked as you typed
• the submission was sent by the post method over secure HTTP
• the session was ended (forced log out) and the account locked after multiple failures to change the password correctly

Also, the form had some helpful client-side JavaScript validation—but did not rely this and, correctly, was also undertaken once submitted to the web server.

The client-side validation even included an indicator of password complexity. But I was surprised when my "great" new password was rejected apparently because it did not contain solely ASCII characters:

Well, I can assure you I did use ASCII characters. In this case the client-side and server-side validation are not identical. This suggests that there may be contradictory requirements in the specification or the validation has been implemented incorrectly, and there was inadequate testing and verification undertaken.

This is a usability error, and a potential security vulnerability.

A small issue, but it demonstrates how easy it is to have faults in applications. This may not have an impact on the application's security, but it would be an area a malicious user would explore further to see if the weakness could be exploited.

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?