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.

Chris Hayes has posted an important reminder of the difference between the risk of non-compliance with the Payment Card Industry (PCI) Data Security Standard (DSS) and the risk of the defects themselves.

Read his Risk and PCI-DSS posting on Risktical Ramblings.

Cotton Traders survived a payment card data breach earlier this year and has gone on to implement tighter controls. It was not clear at the time of the breach whether they were PCI DSS compliant or not.

Chris mentions non-compliance with PCI DSS. Not many merchants should seriously consider remaining out of compliance—micro, small and medium sized enterprises in particular may not survive the consequences of a security breach followed by the effects of being found to be non-compliant.

He also refers to the Common Vulnerability Scoring System (CVSS) in his posting. It is quite a complex standardised method for rating information technology (IT) vulnerabilities and you can read his thoughts on CVSS starting at Risk and CVSS (Post 1) which highlights the dangers of applying methodologies and metrics without a full understanding of them and what aspects are being included/excluded.

I have been catching up on some reading and a paper published in October "Continuing Business with Malware Infected Customers" caught my attention.

Gunter Ollmann's paper Continuing Business with Malware Infected Customers - Best Practices and the Security Ergonomics of Web Application Design for Compromised Customer Hosts highlights the issues of building web applications where many of the users have computers already compromised by some sort of malware. This very readable paper is just as relevant to 'ordinary' transactional web sites - not only e-commerce or finance-related ones.

His concept that all customer data should be "untrusted and [may] not have been intentionally sent by the customer" is very important to realise. His suggested practices are practical and relatively easily implemented. They are worth considering for every web site.

Being able to identify users is a vital part of securing data. In practice too little or too much authentication information can be a problem.

In my posting last week on Personal Information Healthchecks Help Everyone I mentioned how the Which? Current Account Best Buy 2008 bank Smile were setting a bad example. David Lacey raised some good issues in Card fraud up - it's no surprise on his IT Security Blog where he discussed the need for mutual authentication between banks and their customers.

I have come across many banks, building societies, insurance companies, pensions funds and other organisations that phone their customers and ask for detailed sensitive information without authenticating who they are. Yes, banks regularly do this - especially when they suspect fraudulent use of your credit card or current account, but they have not thought how to prove their own identity.

But organisations often ask for too much information "for security reasons". This is getting rather like the catch-all "for health and safety" argument for petty issues or those that just require some good management. I have requested copies of bank leaflets by telephone that are readily available in their branches, but have been asked to provide account information. If I walked into the bank's branch, surely I could take a leaflet from the rack without providing details to identify who I am? Yet many web sites take this course as well, asking for all sorts of personal information to join an email list or to provide access to a document. I can understand some need to collect marketing data, but for example is a person's date of birth or full postal address really necessary? It is possible these may be used for later authentication, but it's often not clear.

When reviewing data controls, I like to think about:

• What information is being collected
• Why it is being collected
• What it will be used for
• How it will be looked after and destroyed at the end of its life
• If the data owner agreed to the above

Remember to explain to web site users why you are collecting particular data, like this good example from Classic FM:

Try to reduce the amount of data collected and stored - it's easier to manage it then, and you can't lose it.

It is not usually necessary to apply the same level of authentication to all types of data. Try to differentiate between security and marketing when asking web users to register. The security aspects are used subsequently to identify and authenticate someone - giving them access to data, processes, resources, and so on which other people are not allowed to access. Separately, marketing data might be used to analyse enquiries, to identify opportunities or to contact the person again.