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.

A friend forwarded me a wine offer from his bank. But the email from his bank included additional information meant to verify the authenticity of the sender.

The bank included the last part of his postcode in the body of the message as well as his title and family name. If those were meant to be for verification purposes, why did it suggest he forward the email to someone else?

Yes, the forwarded email has all the verification details embedded in it. No, it's not the username and password, but it's everything someone would need to construct a phishing email that would be very hard to distinguish from a real one.

This has the feel of using a security measure as a marketing gimmick. Mixing marketing emails and those necessary for servicing a bank account is a difficult balance, but this is way off the mark.

Input masking on can reduce data entry errors by providing a visual indicator of the data required. This isn't masking as in hiding, but rather format filtering. The Masked Input Plugin on digitalbush.com looks like it has some potential.

You would still want to provide labels and a textual description, but I think the concept here would help many users. Earlier feedback on data mis-matches improves the user experience and reduces the chances that the submitted information will contravene the web site's type, format and length requirements.

Oh, and always perform re-validation once the data hits the web server!

Information leakage is a term we are hearing more about these days. But what is it, and what does it look like?

There's a useful briefing document Information Leakage available from the Information Security Forum (ISF), that describes the what information leakage is, why it's important and ways to reduce the likelihood of information leakage occurring. It describes information leakage as "an incident where the confidentiality of information has been compromised" but I'd also include privacy breaches within that description. An alternative application development view of information leakage is published by the Web Application Security Consortium (WASC).

We've all heard about lost laptops and misplaced USB memory sticks, but in what other more subtle ways can information leakage occur? Well, certainly by malicious hacking, but also by more ordinary actions too. This week, I was looking for a location to host a meeting, and some of the possible venues had web site enquiry forms to collect my requirements. One of these form submissions appeared to work okay, but shortly afterwards I received a message from their mail server informing me that it had been unable to deliver an email from me to two of the company's email addresses:

I've mentioned previously about using email in business processes in Keep The Emails Coming and Application Data Flows by Email. But what else did this fault lead to? Well it gave away (leaked) two email addresses and an internal document that was attached. In fact, I don't think there was any information that I hadn't added myself in the attachment, but it may be that the two email addresses were not intended to be known publicly.

This seemingly small, and hopefully transient fault, has leaked some information. Whilst it is not major in any way—more like a couple of drips than a flood—you can see how information can be divulged in unexpected ways.

In this example, using an external email address as the "from" or "reply-to" fields within internal business processes may be convenient, but in error situations the sender may be notified, so do this with care. A similar situation might also occur if your own mail server rejects the message as spam, or has an out-of-office auto-responder set up for the recipient email account.

I was surprised to see the latest advice Stop Password Masking from Jakob Nielsen.

Jakob Nielsen's has raised many usability topics in his Alertbox but he is not always correct. Although I used to read his column with an open, somewhat sceptical, mind I gave up some time ago*.

No, password masking isn't just some legacy design artefact. Like other design choices relating to user identification and authentication, these have a significant impact on user trust and data privacy, confidentiality and integrity. It is wrong to suggest that masking should be removed by default. By all means inform users of the risks and let them choose to display the characters being typed, but don't have this status set by default. More-and-more web sites are being accessed away from home, and being overseen by other people or surveillance equipment is commonplace almost everywhere.

On e-commerce sites, the need to log in can often be removed completely, or made non-compulsory. Too often security controls are applied for other reasons, such as to generate information for sales and marketing reports, rather than to ease the purchasing process. For more critical data, the use of authentication mechanisms other than static passwords should be considered.

* I stopped reading Alertbox after Jakob Nielsen became very defensive about his training material only being available on DVD and not VHS tape, as many people had requested. His argument was that DVD players were so cheap, people should upgrade. Yet at the time, he was promoting the idea that web sites would render in all browsers—including old legacy ones.

Update 7th July 2009: Password Masking Update.

We all have to deal with too many email messages. Sometimes you opt in for something, or it's a requirements for access to some service, and some time later you want to opt out again.

Well, one email too many from Haymarket Publishing (I can't really remember choosing to opt in for 3Dconferences anyway) and I copied the unsubscribe hyperlink (like http://ecm.hbpl.co.uk/public/unsubscribe.jsp but with some additional parameter values) into a secured browser to visit the unsubscribe form:

But the email text field was not activated—I could not tab to or click on the field to enter my email address. The field had the disabled attribute set:

Usability failure. Accessibility failure. Security challenge. Well, not so much a challenge as a minor annoyance.

Don't Haymarket Media Group check their response forms? Cynical people might suggest they don't want people to opt out from their mailings. However, allowing user to unsubscribe from marketing emails is not an optional obligation. The The Privacy and Electronic Communications (EC Directive) Regulations 2003 states:

Oh, and where are the privacy policy and company contact details?

Compliance failure.

In How Much Logging, Monitoring and Alerting? I suggested logging implementations are often incorrect for most web sites and web applications.

The logging should be defined in terms of its intended use. We're talking here specifically about information security, so what might the uses and logging be?

1. To confirm data and process integrity and availability:
   • completeness and consistency
   • response times
   • function/process abandonment
   • session timeout
   • up-time
   • data changes
   • data mirroring, back-ups and archiving
2. To identify and provide enough information for investigation of:
   • errors and unexpected conditions
     • code errors
     • database access and performance
     • web server errors
     • third party services
     • lack of storage space
   • data breaches
   • use and mis-use
     • authentication successes and failures
     • access (authorisation) failures
     • excessive use
     • data validation failures
     • fraud and other criminal activities
     • suspicious, unacceptable or unexpected behaviour
   • modifications to configuration
   • security reports from users and third parties
3. To provide data:
   • subject access requests
   • freedom of information requests
   • litigation document requests
   • police and other regulatory investigations
4. To monitor content changes:
   • database fields
   • file contents
   • generated web page content
5. To demonstrate compliance:
   • internal policies and standards (e.g. information security policy, quality standards)
   • contractual obligations (e.g. PCI DSS)
   • change control
   • use of other's intellectual property
   • legislation (e.g. Data Protection Act)
   • regulation (e.g. Financial Services Authority)
   • external standards (e.g. Web Content Accessibility Guidelines [WCAG] 2.0 conformance claim)

It's important the logging is centralised so that alerts and reporting can be drawn from across all sources (web, application, file and database servers, network devices, etc). The scope and extent of logging ought to be be determined by business needs and the threats. For a typical e-retail site, the payment, check-out and any registration facilities will require greater logging than other parts. In some cases it may be appropriate to set particular thresholds for additional logging (e.g. transactions above a certain value, requests from particular clients, users in some geographic locations). This is easier if the requirements can be built into projects at an early stage.

The logging then needs to be tied in with appropriate monitoring, alerting and reporting. If you want alerts raised automatically, you'll have to think of what conditions initiate these. Referring back to specifications, threat models and test cases can be of use with this.

Organisations tend to do far too little or far too much web site logging, monitoring and alerting. And thus, meaningful reporting becomes infeasible.

I took the following photograph at the Brunswick residential and shopping centre in Bloomsbury, London. I pity the person who has to work out which fire alarm bell is ringing and which part of the building it relates to.

Web sites and web applications I review usually fall into one of three monitoring classes:

• None
• Marketing related only
• All the bells and whistles.

The marketing-related aspects usually include server log analysis including visitor analytics, search engine monitoring, click-through rates, conversion rates and sometimes availability monitoring. Security aspects are normally never considered, even though these affect customer trust and the ability for organisations to protect and monitor their own and their customer's data.

A few web sites have detailed systems monitoring and alerting, watching for reputational aspects, sales process monitoring, unauthorised file and configuration change monitoring, successful and failed log ins, error conditions, usage patterns, fraud identification, network intrusion detection, computer systems log analysis, and so on.

The latter type often have too much monitoring, and alerts begin to be disabled. The level of security monitoring, alerting and reporting needs to be set during the requirements and design stage of projects, and should be proportional to the information security risks. There is no one size fits all solution, and a blind checklist approach can lead to un-necessary "alarm fog" that means real problems go undetected.

I will list some of the type of things worth monitoring for typical types of web applications in a subsequent post on security logging.

Update 20th February 2009: See subsequent post Security Logging Requirements.

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.

It is very common to find web applications where part of the business process, not just acknowledgements, is undertaken using electronic mail. These processes need to be designed securely and tested as well.

I've mentioned previously in Keep The Emails Coming about testing email alerts used for errors, problems and other unusual conditions, but it's common for email also to be used as a short-cut for developing some parts of business processing.

A recent project I was working on included an link to unsubscribe from marketing emails. Clicking on the link gave a slightly sparse single phrase confirmation—not particularly usable and it didn't validate me in any other way or notify me of the change by anything other than the screen message, but it was probably okay for the type of system.

However, within a few minutes I had received another email - an auto-responder:

Very interesting. What does this tell us?

• There is an administration mailing list
• The unsubscribe process sent a message to the administration list with my email address as the sender
• Posting to the list is restricted to certain people, and thus could be a way to identify administrator's email addresses
• The list may be using Mailman, the GNU Mailing List Manager
• The list administration address begins with /mailman/confirm/admins_******/

And, I suppose the implication is my email address has not been removed from the mailing list yet.

If this were a web application penetration test, it might be that some of the mailing list administrative usernames and perhaps passwords are the same as for the web application. Or, content of messages in the list contains useful information to help access the web application. The email responder is sending too much information, and actually this message shouldn't be being sent to a subscriber at all, and the information leakage then stems from using the subscriber's email address as the sender.

So, remember a web application's security is only as good as its weakest link. The security architecture needs to address the whole business process, not just the web page parts.