PAS 124:2011 (Defining, Implementing and Managing Website Policies and Standards) has been updated, superseding PAS 124:2008 which has been withdrawn. It was issued by BSI in March.

Publicly Available Specifications (PAS) are industry-led initiatives, are not full British Standards and generally not free. They can be withdrawn and replaced at any time. However, the topic is relevant enough to make it worth mentioning here. This PAS was originally commissioned by Magus, but members of the steering group also included the Cabinet Office, LBi, Olswang LLP, SDL Tridion, Shell International B.V. and Unilever plc.

So what does this document concern itself with? PAS 124 describes how to define, implement and manage web site policies and standards, and provides suggested areas they should cover, and example governance policy and further sources of information.

The scope says whilst PAS 124 can be used for "all types of website including: static websites, dynamic websites, web portals, mobile websites, e-commerce websites and content published by organizations on external sites such as social media sites", it does not cover "web-based services and applications: software-as-a-service (SAAS)/cloud computing services, virtual learning environments and internet enabled widgets and applications (e.g. mobile applications)". That's quite odd, because dynamic web sites and e-commerce web sites are applications.

Some of the benefits in taking the approach suggested by PAS 124:2011 are "protection of brand and company reputation by ensuring a consistent high quality user experience", "minimization of online risk through compliance with legal requirements" and "securement of appropriate protection of intellectual property" and "increased user confidence through a consistent, high quality user experience". I agree with those.

And what areas does it consider should be included to "govern the content, function and appearance of websites" to acheive these benefits? These ten key areas are listed:

• Accessibility
• Brand and template
• Co-branding
• Domain name and URL structure
• Editorial and copywriting
• Legal
• Search engine optimization (SEO)
• Social media
• Usability
• Website governance policy

Now, PAS 124 does state "this list... is not exhaustive...". True. There is no mention of affiliates, advertisers, wider marketing (not just SEO), testing, analytics, optimisation, performance monitoring, supply chain management, intellectual property, disaster recovery, business continuity, and use of multiple channels.

But how are aspects like information privacy and security, and the protection of assets belonging to the company, other organisations and individuals governed? "Data protection and privacy" are mentioned briefly as an example legal issue that "might" need to be considered.

Also, the PAS explains it does not cover "the following types of technical standards: infrastructure standards (e.g. connectivity, performance and availability), security standards, code standards, or the use of semantic web technologies."

I am disappointed. Technology requires governance too. And security is not just about technical controls — the administrative and physical aspects are just as important for preventative, detective and corrective actions necessary to achieve the benefits listed in PAS 124. In Appendix C (Useful Sources of Information) under the heading "security" is states "This is an area where there are a lot of standards. Visit the BSI website to review the range of available standards", but I'm not sure that really does the area justice. No mention of untechnical aspects? Also, surely there are some technical aspects in the listed key issues of accessibility, templating, domain name and URL structure, legal and usability? I can think of quite a few.

There really is more to governing a web product today than what is listed here. PAS 124 seems to reflect the thoughts of a somewhat silo-style organisation which does not have a connected overall viewpoint. It feels like the old-fashioned web manager in the corner office; someone disassociated from the business and out-of-touch with supporting legal, marketing & information systems services. What it covers is good, but its vision is too constrained.

So, I think the PAS has set too narrow a focus for its scope — PAS 124 is more 2001 than 2011.

Following an extended period of development and consultation, BSI has announced the publication of BS 8878:2010 Web Accessibility - Code of Practice.

At the launch event this morning, Jonathan Hassell (Committee Chair BSI IST/45), introduced a series of presentations on the development, content and use of the new standard.

The standard replaces the somewhat outdated PAS 78:2006 Guide to Good Practice in Commissioning Accessible Websites, and provides a practical 21st century view of accessibility addressing a wider view of the web, varied delivery and consumption mechanisms, the rise of user-generated content, use by older people, and the increasing use of off-the-shelf services, frameworks and components. It is not a technical standard, but instead describes an approach to addressing web accessibility through the development lifecycle from commissioning through to operation—building accessibility in to the organisation as it were.

The fundamental driver for the standard in the UK are the Disability Discrimination Act 1995 (now Northern Ireland only) and the Equality Act 2010 (rest of the UK), which came into force in October and describes how organisations have a duty to make reasonable adjustments, but not anything that would fundamentally alter the nature of the "service". The standard uses the interesting term "web products" to include workplace applications, widgets, RIAs, SaaS and mobile apps, as well as web sites.

The standard describes 16 steps, from Step 1 - Define the Purpose of the Web Product, through to Step 16 - Plan to Assure Accessibility in All Post-Launch Updates to the Product. But the appendices, that account for more than half the document, provide some very useful supporting material. I suspect these partially came about from the large number of responses received to the consultations, and from the extensive experience of the committee members. The appendices include information on the legal requirements (UK), making a business case, example policy wordings, how to allocate responsibilities, metrics, procurement advice and information of a more technical nature for production & operational teams.

Do you need to read this? If your organisation is established in Great Britain, yes, and then even if you are not subject to the Equality Act but are looking for good web accessibility practices, yes too. Then act on it.

Last Friday, I was going to travel to Oxford by express coach, but there had been a road traffic accident which had caused delays to the normally frequent service. After standing in a very long queue at Marble Arch for 10 minutes, and seeing one full coach go past, I decided to catch the train from Paddington instead.

The earliest "off peak" train was at 19:17 hrs and I was intrigued to see on the display boards "TV Entertainment in coach D". Fearing having to watch a football match for the whole journey, I boarded the train just after coach F, expecting that to be coach E. But no, it was coach D. Rather than some sort of large screen at the end of the carriage, I was surprised to see airline-style back-of-seat type displays, and sat down before the rest of the crowd arrived.

I thought a description of the user interface might be of interest to some readers of this blog, especially considering that apart from headset jacks, a screen power button, volume and brightness controls, all interaction is using the touch screen. The interface constraints, need to allow for train vibration and use by untrained public users affect what's possible.

The video on-demand in-train entertainment system is provided by Volo who suggest on their website the mobile payments are integrated by RingGo. I had a look at the safety video which had stop, start and pause buttons available like a conventional media player. The "try me" button let you navigate the juke-box of television shows categorised by genre. The interface felt like "CD multi-media" rather than "web browser". After a while the nag dialogue box popped up in a couple of permutations.

The adjacent passenger seemed to want to go further, but without a valid payment code, their attempt to "log in" was rejected.

The code entry field indicated the required format with underscores and hyphens once touched, and a backspace key appeared once the first character was entered. It did not seem to be possible to enter longer codes than required.

Entry of an invalid "login" code, led to a 20s delay (see countdown timer bottom right) before another attempt could be made, but there did not seem to be any limit on the number of attempts allowed. It is possible the payment code activation period is time limited as well as being for a fixed duration, and they might even be train-specific. Therefore the 20s delay could have been deemed sufficient to protect against guessing unused codes (brute force attack). I would be intrigued to see the risk assessment for the system. The codes could theoretically be tied to seat numbers, but the "special offer" at the cafe didn't seem to suggest you needed to know your own seat number, and that might put off people going for a day's duration to cover their outward and return journeys.

Presumably codes are issued in real time, rather than from prepared lists, so the system will rely upon a semi-continuous communication connection. But it is nice to know if you have a problem, they have "controllers" rather than "helpdesk staff". The code entry screen also reverted back to the main welcome screen after 60s of inactivity.

Without logging in, not much else seemed to be available to the adjacent passenger, but they did manage to get another slightly amusingly worded message screen when randomly tapping on the screen just after starting to watch the safety video once more.

So some interesting constraints on authentication and access control to deal with. Spelling aside, the resolution and related font size does make some screens a little cramped. Having an on-screen keyboard which is only numerical plus A-F does feel a bit techie, and maybe old-fashioned when people are used to much greater flexibility with touch devices. It might indicate the range of values for each code character, and thus reveal something about how it is generated? The touch screen appears to be the only method of user input—perhaps no other way to increase accessibility. Will it be a success? Hard to tell, but very few early-evening commuters seemed to be interested—many had smartphones, game consoles, netbooks, laptops and e-readers to hand, or were asleep.

Perhaps that is why there apparently weren't any power sockets available at the seats.

On the short journey, maybe passengers would be more tempted by live news, travel and weather, or even web browsing if mobile reception was poor, rather than old television shows. But on longer routes it will have greater appeal.

Early last year I mentioned the security implications of the Web Content Accessibility Guidelines 2.0 and the scope for accessibility testing. I also spoke about whether an accessible web application be secure at the OWASP AppSec EU09 conference.

At that time, I found it fairly difficult to identify many web sites that were making WCAG 2.0 conformance claims.

The US Department of Justice is now seeking comments on proposed rule changes to the Americans with Disabilities Act that might make compliance to Level AA of WCAG 2.0 more widely mandated. A full analysis of the legal implications and timescales are presented on the Outlaw web site. As we see increased take-up in the US, it's likely similar levels of compliance will be required elsewhere.

In my conference presentation, I discussed how some security vulnerabilities could occur if WCAG 2.0 is implemented poorly.

One of the most common issues that arise when discussing accessibility and security, is the use of CAPTCHA images on web pages. These are used to differentiate between real human users and automated systems that might want to submit forms to register fake users, create spam or add links to malicious web sites in forum postings, blog comments and the like. CAPTCHAs are also in the news again after Google acquired reCAPTCHA, one of the larger free CAPTCHA providers.

CAPTCHAs also sparked a new topic in the Web Security Mailing List yesterday, Complex CAPTCHA Solutions raised the subject of the benefits and usability issues relating to CAPTCHA and alternative complex methods.

An article in this quarter's issue (Issue 74 Summer 2009) of Ability Magazine discusses the problem and alternative approaches such as audio versions, logic puzzles and image recognition or even having a human operator available to help.

Using CAPTCHAs on web sites where there are particularly sensitive data or as part of authentication mechanisms before providing access to sensitive or high-value information, is almost never justified. The identification and authentication mechanisms should be sufficient in themselves.

The most appropriate use for CAPTCHAs is on high usage web sites where the criticality of information is low, and the benefits to successful abuse greater. But then the owners of these sites have the resources to develop effective CAPTCHA systems and spend time maintaining the robustness of the method against automated systems and other attacks. The larger the user base, the greater the incentive there is to break the method. See also suggestions on an effectiveness test and my discussion on the security implications of Web Content Accessibility Guidelines 2.0 compliance.

So, normally there are simpler ways to prevent spam on most sites that might consider using CAPTCHAs. There is a good summary on the WebAIM blog and discussion list, based on ideas like the Honeypot Captcha. These measures should be used in the first instance for response forms, forum registration and the like. Proceed from there only if a problem occurs, and spend time thinking about other security matters.

Ability Magazine can be obtained by subscription but it is also a free benefit to members of the British Computer Society (BCS) Assistive Technology Group, formerly the BCS Disability Group.

Update 28th September 2009: I just read Using Web Analytics to Assess CAPTCHA Usability on Smiley Cat Web Design which describes an assessment of how many visitors to a web page had difficulty with the CAPTCHA by looking at how often they reloaded it.

Insufficient session expiration in the context of a web site or web application, is when the site allows someone to reuse old session credentials or session identifiers for authorisation, and is one of the threats included in the Web Application Security Consortium (WASC) threat classification.

Once a user has logged on (authenticated), the idea is that restricting the period of inactivity before they have to re-authenticate is beneficial. But this aspect needs to be considered carefully in the context of user behaviour, the risks to information and accessibility. The other side to the problem is ensuring the session is terminated (destroyed permanently) when a user actually logs out or they time out.

In the context of a train journey (the session), the ticket (session identifier) may allow me to travel on a particular route but may not specify the particular train. This means that train operators have to ensure they invalidate the tickets by marking or punching them at the time of travel (terminating the validity of the ticket).

If this were not done, an open, unrestricted, ticket could be used by the purchaser forever, or if discarded, used by someone else who acquired it.

These example tickets have restrictions such as the type of traveller, routes and start date but also have an expiry date, although this is depends on the type of ticket and may be the same day as the purchased journey, or perhaps a month in the case of some return tickets. Data are also recorded on the magnetic strips on the reverse (not shown). After these dates, the ticket is invalid. Like web site terms and conditions, travel by train is subject to the National Rail Conditions of Carriage. Interestingly, these ticket examples bought online have the passenger's name printed on them.

Of course, you don't want users to make their own tickets up, especially if the station and on-board facilities don't have any way to validate the authenticity of the ticket other than by visual inspection. That's why self-service ticket machines print "VOID" on mis-printed tickets.

Or at least they should do. I found the above pair of ticket blanks—one voided and one not—lying on top of a ticket machine. Don't let users make up or predict session identifiers for your web site either. For further guidance read session management.

"Can An Accessible Web Application Be Secure" was the title of my presentation at OWASP AppSec EU09 last week in Kraków, Poland.

Kraków is a beautiful, friendly and safe city, and was an excellent location for the well-organised conference which attracted delegates from all over Europe. The Open Web Application Security Project (OWASP) has the best resources, documents and tools on web application security, and it's all freely available, under an open source licence. All the presentation slides are now uploaded to the conference website for 13th May and 14th May, and video recordings will be added in due course. Most of the speakers were also interviewed for the OWASP Podcast.

In my presentation I discuss how compliance requirements can lead to additional complexity and thus an increased likelihood of vulnerabilities. In the presentation I focus on accessibility, which has become an accepted part of many web site and web application development projects, especially those aimed at consumers or that belong to governmental organisations. The key standard in this area is the Web Content Accessibility Guidelines 2.0 which became a W3C recommendation in December 2008. I identified eight classes of security issues that people involved with specification, design and verification should be aware of. In particular, I examine 'alternative forms of CAPTCHA', 'flexible session timeouts' and 're-authentication recovery'. In conclusion, accessible web applications can be secure, but it adds complexity to the problem of securing the application.

The presentation slides and additional resources are available on the OWASP web site:

• Can An Accessible Web Application Be Secure? Assessment Issues for Security Testers, Developers and Auditors
• Mapping of WCAG 2.0 Principles, Success Criteria and Conformance Levels to Security Issues
• Mapping of WCAG 2.0 Sufficient Techniques to Security Issues

See also my related posts on Security Implications of WCAG 2.0 and What's the Scope for Accessibility Testing?.

Reminder: The OWASP London chapter meeting is this Thursday (21st May). It's free to attend, but prior registration is required for access to the venue (see the previous link for details).

Update 21st May 2009: Matt Tesauro, leader for the OWASP Live CD Project, has kindly given my presentation his "winner of my unexpected security problem of the conference" award in his posting Talks of Interest - Some Personal Notables from AppSecEU 2009 on the new AppSecLive.org blog.

Update 5th June 2009: The presentation video is now available on owasp.blip.tv.

All forms of testing require a definition of scope. Testing accessibility requires the whole web page to conform—what does this mean for security?

I will presenting "Can an Accessible Web Application be Secure?" at OWASP AppSec EU09 in Kraków next Thursday. I will be showing the following diagram, based on a similar Venn diagram by Whittaker and Thompson 2003, demonstrates how the client's requirements and what the development team intend to build always differ. But the important thing is: what the application does is something else completely:

Many security vulnerabilities occur in the area describing what the application does, but wasn't intended to do. This gets more complicated when we consider a client who wants a usable website and perhaps conforming to a particular level of Web Content Accessibility Guidelines (WCAG) 2.0 (see also Security Implications of WCAG 2.0):

What the application actually does is usually not fully known. If we want the whole web site to conform to WCAG 2.0 Level AA, what should be tested against the success criterion? The client's specified requirements, the developed product's documentation, or what the application does?

Fortunately WCAG provides information on conformance claims which states a claim can be for a single page, unless it is part of a complete process, in which every page of the process must conform at the specified level or better.

Does then a single security vulnerability (i.e. additional undocumented functionality which is also not accessible) on a web page or the process, imply it cannot conform to any conformance level of WCAG?

Therefore, methods used for security verification are necessary to have sufficient assurance of the conformance level. I believe the argument is very strong. What do you think?

Update 19th May 2009: See also Can An Accessible Web Application Be Secure? concerning my presentation at OWASP AppSec EU09.

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.