On Sunday morning, I was intrigued to read on Web Application Security - From the Start about a security vulnerability supposedly found on the Child Exploitation and Online Protection Centre (CEOP) web site.

But it is apparently true, the short story on the BBC web site seemed to be confirmed in their interview with CEOP which was mentioned by @StewartRoom, @xklamation, @siliconglen, and received further coverage yesterday in IT Pro and IT Week. I wondered where this report came from and how the Information Commissioner's Office (ICO) became involved so quickly. IT Week suggests a member of the public tested the CEOP site and then told them of the problem; presumably CEOP then reported it to the ICO.

Don't get me wrong, I think the ICO should investigate whether there has been a breach of the Data Protection Act 1998, but some of the information released so far doesn't seem correct. The BBC story includes several statements supposedly attributed to CEOP's Chief Executive Peter Davies. But I cannot quite believe CEOP would say some of these things about a web form to report alleged offenders, so perhaps sadly there is some over-zealous PR going on, or misinterpretation by the BBC's journalist.

A later item on The Register Child protection Website Insecurity Fixed paints a slightly different picture, suggesting the form is, and always has been, using SSL only, but that there was a link to a non-SSL address which then redirected. I must say, I'm inclined to believe The Register's version more than the BBC. I think we have to leave it up to whoever is investigating to get to the true facts, but it does seem to be creating a link between personal data protection and the use of SSL.

It is perhaps not always clear to government agencies what administrative, physical and technical security practices should be implemented to protect a web site, and who makes the decisions. The government's Central Office of Information (COI) have never published any web standards and guidlines on security or privacy protection, perhaps feeling it is some other agency's responsibility (maybe CESG, CPNI or even the ICO?).

The security measures implemented for a web form like this ought to be similar to those defined in open standards, and common sense alone would tell you this is an obvious place for using appropriately designed HTTPS. Anyone auditing or verifying the security aspects would have made this clear in large red letters, but waiting until after being made live is incomprehensible too. Security and privacy need to be considered from early stages in every project, and built in to the final system. There are existing standards for that too.

But I am concerned about some statements which have been reported. If they are true, I am worried.

"All secure website carried the prefix https, compare[d] to http for insecure ones"

False. Using HTTP over SSL does contribute to the protection of a user's, or organisation's, data in transit and also gives some degree of identity assurance. There is even a campaign to increase adoption. But SSL is not the same thing as a web site being secure. A web site using SSL can still be vulnerable to attacks (e.g. SQL injection, cross-site scripting, cross site request forgery) leading to contamination with malware or data damage, loss and destruction.

SSL does not stop breaches of the Data Protection Act.

"It's been fixed now"

Really, that quickly? There's more to implementing SSL than just turning it on. Last year I mentioned some other concerns about CEOP and trust, but you cannot check or test a web site without authorisation. On Sunday, @siliconglen also asked why they CEOP were not using an extended verification (EV) SSL certificate. For many purposes I'm on record as saying EV certificates are not needed, but here I agree, I think an EV certificate should be used. And really, why not have the whole site SSL.

Of course, all organisations would do well to ensure that their SSL certificates are valid, applied appropriately to the applications and that SSL is configured securely, such as ensuring weak protocols and ciphers are not available. They should also think about whether any data can be cached locally on the web browser, whether other domains have access to the web page contents, and what exactly is done with the sensitive data once it is saved on the web site. How secure are the information systems and subsequent processes?

Fix and verify.

Conclusion

Other public and private sector organisations take note. It will be interesting to see the outcome of the ICO investigation and whether this incident leads to a change in attitude, or even sets a precedent for online data protection requirements.

SSL has its problems, see here, here and here, but it would be wrong not to implement it. After all we've been using it for over ten years to help protect credit card data in online shopping; information from children about possible offenders is an order of magnitude more important than payment card data.

I just hope some of the statements that appeared in the BBC article about SSL were misinterpreted, and don't become the accepted understanding. CEOP please set the record straight.

The Web Hacking Incident Database 2010 semi-annual report was published in early September. I have only just managed to find time to read it.

This latest report for January to June 2010 analyses actual reported incidents (e.g. data breaches) collected by the Web Hacking Incident Database (WHID), a project of the Web Application Security Consortium and supported by Trustwave SpiderLabs. The WHID's goal is to raise awareness of the web application security (webappsec) problem and provide information for statistical analysis of web application security incidents. The data only include disclosed and reported targetted (i.e. non-random) attacks against specific organisations (see Zone-H for wider data on random or opportunistic defacement hacks).

The information is very clearly presented and includes attack source geographic location, the drivers (outcomes), attack methods, weaknesses exploited and organisation type. It will be very useful for risk and security professionals who want to prioritise resources protecting their web sites, applications and the associated data. In case you haven't guessed "SQL injection is still the top known attack category".

If you haven't seen them yet, the "real-time" interactive charts on the project's home page are fantastic. Other ways to keep up-to-date are using the RSS feed or Twitter.

Sometimes when I'm out socially and people ask what I do, the conversation progresses to concerns about their own web site. They may have a hobby site, run a micro-business or be a manager or director of a small and medium-sized enterprise (SME)—there's all sorts of great entrepreneurial activity going on.

It is very common for SMEs not to have much time or budget for information security, and the available information can be poor or inappropriate (ISSA-UK, under the guidance of their Director of Research David Lacey, is trying to improve this). But what can SMEs do about their web presence—and it is very unusual not to have a web site, whatever the size of business.

Last week I was asked "Is using <company> okay for taking online payments?" and then "what else should I be doing?". Remember we are discussing protection of the SME's own web site, not protecting its employees from using other sites. If I had no information about the business or any existing web security issues, this is what I recommend checking and doing before anything else:

• Obtain regular backup copies of all data that changes (e.g. databases, logs, uploaded files) and store these securely somewhere other than the host servers. This may typically be daily, but the frequency should be selected based on how often data changes and how much data the SME might be prepared to lose in the event of total server failure.
  • check backup data can read and restored periodically
  • don't forget to securely delete data from old backups when they are no longer required
• Use a network firewall in front of the web site to limit public (unauthenticated user) access to those ports necessary to access the web site. If other services are required remotely, use the firewall to limit from where (e.g. IP addresses) these can be used.
  • keep a record of the firewall configuration up-to-date
  • limit who can make changes to the firewall
• Ensure the host servers are fully patched (e.g. operating system, services, applications and supporting code), check all providers for software updates regularly and allow time for installing these.
  • remove or disable all unnecessary services and other software
  • delete old, unused and backup files from the host servers
• Identify all accounts (log in credentials) that provide server access (not just normal web page access), such as used for transferring files, accessing administrative interfaces (e.g. CMS admin, database and server management/configuration control panels) and using remote desktop. Change the passwords. Keep a record of who has access and remove accounts that are no longer required and enable logging for all access using these accounts.
  • restrict what each account can do as much as possible
  • add restrictions to the use of these accounts (e.g. limit access by IP address, require written approval for use, keep account disabled by default)
• Check that every agreement with third parties that are required to operate the web site are in the organisation's own name. These may include the registration of domain names, SSL certificates, hosting contracts, monitoring services, data feeds, affiliate marketing agreements and service providers such as for address look-up, credit checks and making online payments.
  • ensure the third parties have the organisation's official contact details, and not those of an employee or of the site's developers
  • make note of any renewal dates
• Obtain a copy of everything required for the web site including scripts, static files, configuration settings, source code, account details and encryption keys. Keep this updated with changes as they are made.
  • verify who legally owns the source code, designs, database, photographs, etc.
  • check what other licences affect the web site (e.g. use of open source and proprietary software libraries, database use limitations).

Do what you can, when you can. Once those are done, then:

• Verify the web site and all its components (e.g. web widgets and other third party code/content) does not include common web application vulnerabilities that can be exploited by attackers (e.g. SQL injection, cross-site scripting).
  • use resources such as the OWASP Top Ten and WASC Threat Classification
  • build security requirements into future developments
• Check what obligations the organisation is under to protect business and other people's data such as the Data Protection Act, guidance from regulators, trade organisation rules, agreements with customers and other contracts (e.g. PCI DSS via the acquiring bank).
  • impose security standards and obligations on suppliers and partner organisations
  • keep an eye open for changes to business processes that affect data
• Document (even just some short notes) the steps to rebuild the web site somewhere else, and to transfer all the data and business processes to the new site.
  • include configuration details and information about third-party services required
  • think about what else will need to be done if the web site is unavailable (does it matter, if so what exactly is important?)
• Provide information to the web site's users how to help protect themselves and their data.
  • point them to relevant help such as from GetSafeOnline, CardWatch and Think U Know
  • provide easy methods for them to contact the organisation if they think there is a security or privacy problem
• Monitor web site usage behaviour (e.g. click-through rate, session duration, shopping cart abandonment rate, conversion rate), performance (e.g. uptime, response times) and reputation (e.g. malware, phishing, suspicious applications, malicious links) to gather trend data and identify unusual activity.
  • web server logs are a start, but customised logging is better
  • use reputable online tools (some of which are free) to help.

That's just the basics. So, what would be next for an SME? If the web site is a significant sales/engagement channel, the organisation has multiple web sites, is in a more regulated sector or one that is targetted particularly by criminals (e.g. gaming, betting and financial), takes payments or does other electronic commerce, allows users to add their own content or processes data for someone else, the above is just the start. Those SMEs probably need to be more proactive.

This helps to protect the SME's business information, but also helps to protect the web site users and their information. After all, the users are existing and potential customers, clients and citizens.

Oh, the best response I had to someone when I was explaining my work: "You're an anti-hacker than?". Well, I suppose so, but it's not quite how I'd describe it.

Any comments or suggestions?

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.