Further to my previous notes about HTML 5 security, a superb reference document was published earlier this month.

Michael Schmidt (Compass Security) wrote his master's thesis about HTML5 security in May 2011 and has published an extract for everyone to access.

HTML5 Web Security describes issues, vulnerabilities, threat & attack scenarios and countermeasures across 80 pages including numerous well thought-out diagrams, and is backed up with detailed references and an appendix full of attack details.

The main sections are:

• 2.2 Cross-origin resource sharing
• 2.3 Web storage
• 2.4 Offline web application
• 2.5 Web messaging
• 2.6 Custom scheme and content handlers
• 2.7 Web sockets API
• 2.8 Geolocation API
• 2.9 Implicit relevant features of HTML5
  Web workers, new elements, attributes and CSS, Iframe sandboxing and server-sent events

If you are already developing HTML, or planning to, read this document as soon as possible and update your requirements documents, specifications, design documents, coding standards, and test plans to incorporate the knowledge.

The document would be worth buying if it were a book, but it has generously been made available publicly. Yes, I am still reading the document, and so far have only one very minor complaint — it would be good to have a content list. Maybe in version 1.1?

The UK's data protection agency Information Commissioner's Office (ICO) has updated the previous guidance on the use of cookies and similar tracking technologies, under the revised Privacy and Electronic Communications Regulations which came into force on 26th May this year.

In a press release today, organisations were warned they are not doing enough during the lead-in period to formal enforcement.

The updated Guidance on the Rules on use of Cookies and Similar Technologies provides concrete advice and practical guidance on the legal requirements, their interpretation and what are considered acceptable practices. The guidance was issued as a result of a review of progress to date which shows a lack of knowledge and action from web site owners. Of most concern are likely to be persistent cookies, cookies issued by third parties, cookies issued immediately a user visits a web site, are used for any sort of profiling or which span multiple website hostnames or multiple domains.

If you have any analytics, advertising, tracking or content provision by third party web sites, beware — you may just find the terms and conditions of service state you are responsible for obtaining and managing consent.

If you are a web site owner, take note and act now, if you have not already done so. From May 2012, the ICO will be accepting complaints from users, and will then contact web site owners to ask them to respond to the complaint and explain what steps they have taken to comply with the regulations. Therefore, document what you are doing and the decisions taken.

In May, the UK's Information Commissioner's Office (ICO) published its initial guidance on how cookies and similar technologies that store information on user's devices should be deployed (see my previous posts here, here and here). The European Union's Article 29 Working Party has now published its own views concerning obtaining consent.

The working party's Opinion 15/2011 (WP 187) suggests that prior consent will always be required and this may mean that the ICO will need to update its own current guidance and enforcement guidelines.

Although the working party's opinion is quite a long document, if you are considering how to build consent for cookies, etc into your future web product development plans (e.g. web sites, mobile apps, social networking activities, e-commerce and f-commerce), it is worth the read.

They emphasize the need to obtain unambiguous explicit consent before any personal data processing can occur, and to be able to subsequently prove this was given. This does not affect mechanisms "strictly necessary" for the provision of the service as discussed before about session cookies. The examples included in the text add some realism to the intent of the opinion, and it is likely the recommendations will form part of future updates to EU legislation.

And remember not to lose sight of the other data protection principles. Obtaining consent does not negate the controller's obligations for fairness, necessity, proportionality, security and data quality.

Further to the recent guidance and announcement of enforcement plans, the first demonstration of what this might entail for web sites which undertake user-tracking or store user data, has been revealed.

The UK Information Commissioner's Office (ICO) utilises up to six cookies on the ICO web site (four relating to Google Analytics). Alexis Fitzgerald discusses the implementation in his Web Application Security - From The Start blog. There is no cookie to say you have opted out of accepting cookies — which is good — but for now the site does leave that rather annoying message at the top of every page which persists in the print version too. Giving consent also sets a cookie "ICOCookiesAccepted".

I see the ICO has stated the session identifier "ASP.NET_SessionId" is an "essential site cookie". It is set by default as soon as you visit the site, and thus presumably is exempt from the regulations for consent due to being "strictly necessary for the provision of an information society service". Take note.

Well, many web sites manage not to use session identifiers except in a subset of the site, such as for authentication and authorisation checks in areas limited to certain users. I wonder whether there really is any functionality on the ICO web site which really requires this session cookie to work?

Putting that aside, the cookie is "session-only" and should be destroyed when the browser is closed. But some web browsers are not routinely closed, and this would leave evidence that the site had been visited. In the case of the ICO web site, it would almost always be an insignificant matter, but there could be situations when even accessing the this might be deemed unacceptable or suspicious, leading to some sort of potential harm to an individual. Other web sites are likely to copy the ICO approach, so it is interesting the ICO has not removed the need for a session identifier cookie for general site browsing.

My baseline tips for cookies used for session management would be:

• Have only one session management cookie if possible
• Ensure session management cookie(s) expire automatically
• Destroy sessions server-side once they have expired, or when their use is no longer required, and after a fixed time period
• Do not store any personal data or business data in the cookie value — just store a long highly-random, difficult to predict identifier which has some meaning server-side
• Restrict session cookie scope to the site's particular domain and URL path
• Set the HTTPOnly, and if SSL is used SSLOnly, cookie attribute
• And preferably, limit where session identifiers are required (i.e. not the whole site)

These are just a starting point. If the session management cookie is part of authentication processes, there are further recommendations for implementation.

No doubt, additional advice on the new cookie regulations and standard practices will be forthcoming in due course. Of course, the ICO could have removed client-side web analytics completely, reducing the number of cookies to one (and this may not really be required either).

As mentioned previously, the new UK regulations on cookies, etc came into force today, 26th May 2011.

The Information Commissioners Office (ICO) announced yesterday that web site owners will have up to a year to comply with the law. The ICO also published guidance on its approach to enforcing the new rules and other powers as part of the revised the Privacy and Electronic Communications Regulations (PECR), which are subject to its own Data Protection Regulatory Action Policy.

The Information Commissioner's Office (ICO) has now published its initial guidance on how cookies and similar technologies for storing information on user's equipment. This becomes a legal requirement from 26th May 2011, following an amendment to the EU Privacy and Electronic Communications Directive.

I had discussed the change last month, but now the guidance has been published. It does appear to be a reasonable, practical, approach but is still work-in-progress and will be subject to change. In general, it requires UK organisations to obtain informed consent from visitors to their UK web sites in order to store and retrieve information on users' computers (including mobile devices).

The ICO advises organisations to take three steps:

• Check what type of cookies and similar technologies are implemented and how they are used.
• Assess how intrusive the use of cookies is.
• Decide what solution to obtain consent will be best in the particular circumstances.

Generally both notice to the user and consent will be required. However, two important exclusions exist for technical storage of, or access to information:

• for the sole purpose of carrying out the transmission of a communication over an electronic communications network; or
• where such storage or access is strictly necessary for the provision of an information society service requested by the subscriber or user.

This is why temporary state management session identifiers (IDs) used only for the purpose of the provision of a service requested by the user (e.g. looking at an area of a web site they have chosen to access, to log in to a member-only area, to use a shopping basket), are probably excluded from the requirement for consent. But organisations need to check what information is being collected & stored using cookies, etc, when it is being collected, and how it is being used. If session data (as cookies, etc) is transient and only used for the purpose of navigating the site, I would argue it is strictly necessary.

The guidance reminds organisations "strictly necessary" means it must be limited to a small range of activities, and encourages organisations to test whether the activity was "explicitly requested" by the user in some way. Persistent cookies which last beyond the user's current session (e.g. remember me, site customisation) are very likely to require consent, and this is an area where further guidance would be welcome (e.g. session management without authentication).

The guidance includes information on how to obtain consent, and in particular discusses passing data to third parties and the use of third party cookies. If you must allow third party content, the onus is still on you to make sure your site, and all its content, complies with the new law. See also the previously mentioned IAB Europe Self Regulation Guidelines.

Remember, this is not just about cookies — all similar technologies for storing information on the user's device which can then be retrieved are covered by the new requirements. So that will include:

• HTTP cookies
• Local Shared Objects (LSO) i.e. Flash cookies
• userData in DHTML Behaviors
• data in a Google Gears database
• data in an Indexed Database API
• local data storage in mobile applications
• HTML5 storage

...and anything similar that exists now or in the future.

It's a busy week for the ICO; this afternoon, it will publish the new Data Sharing Code of Practice (see my discussion about the consultation last year).

The 25th May is the deadline for implementing changes to the EU Privacy and Electronic Communications Directive. Organisations need to make efforts to comply with the regulations.

The changes mean organisations have to obtain consent from visitors (consumers) to their web sites in order to store on and retrieve usage information from users' computers. Whilst this is aimed at tracking cookies (e.g. behavioural advertising, site personalisation, remember-me functionality), the effect on cookies used for session management and tracking to defend privacy & security is not clear.

But what to do? Self regulation guidelines have just been issued by IAB Europe, the trade body for the European online advertising industry, but this pre-empts formal guidance. The Department for Culture, Media and Sport (DCMS) is leading on implementing the new measures in the UK while the Information Commissioner's Office (ICO) will be responsible for regulation, but the guidance is not expected until after the 25 May deadline. Part of this delay is likely to be due to wanting a joined up approach with the US Federal Trade Commission (FTC) who have been consulting on similar measures, and received a large amount of feedback. DCMS commissioned a report on regulation of internet cookies and this contains much useful information, but doesn't give any firm clues about what the guidance will be.

In the meantime, I would recommend organisation undertake the following steps if they don't already have this information:

1. Identify all their web sites and applications.
2. Determine which of these are accessed by consumers.
3. Create a schedule of all the cookies created or used, including cookies from third-party content hosted on the site (e.g. analytics, advertising, widgets, code libraries).
4. Detail other functionality which collects or stores information about users.

Then await for announcements from the DCMS and ICO.

Update today: The government's summary and response to its own consultation was published today after this item was posted. This confirms (see paragraphs 305-326) a non-prescriptive approach, that is not expected to affect the use of cookies strictly necessary for the provision of a service specifically requested by a user (e.g. session identifier, or a shopping basket). In addition, due to need for future phased implementation of technical solutions, it does not expect the ICO to take any enforcement action against organisations who are at least making some efforts to comply.

Online behavioral advertising continues to be in the news (see also previous here, here and here). The US Federal Trade Commission (FTC) has now issued a preliminary staff report which has been widely discussed (including here, here, here and here.)

The FTC's work was prompted by the lack of success with "notice-and-choice" and "harm-based" models to provide adequate and meaningful consumer protection, despite various industry initiatives such as self-regulation. The FTC report proposes a new framework and suggests organisations should adopt a privacy-by-design approach in their information systems and business processes, provide greater clarity in explaining their use of personal data and, for practices that are not "commonly accepted", provide information so that people can make informed and meaningful choices. One example of this, and the aspect which seems to have the most attention, is the ability for consumers to make a universal choice whether they allow their data to be used in behavioural advertising i.e. have the ability not to be tracked. And the FTC suggests organisations need to make their actions more transparent, and also help in the effort to educate consumers.

Note, the FTC document refers to "consumers" due to their area of responsibility, but the concepts could/should also be relevant to other personal data (e.g. employees, citizens).

But what does "no tracking" mean? There are already some initiatives in this area (e.g. the Network Advertising Initiative (NAI) Opt-out Tool and the Interactive Advertising Bureau (IAB) Self-Regulatory Program for Online Behavioral Advertising). The FTC has testified that the mechanism should be browser based allowing consumers to opt out easily and permanently. There has been debate about how "Do Not Track" might be achieved online, and a suggestion is organisations honour a new HTTP header. The "X-Do-Not-Track" header would be sent if the user (consumer?) had set this as their preference (or not deselected it?). See http://donottrack.us/ for more discussion.

Tracking might involve cookies and recording data such as the type of device, configuration, user location & IP address, and using this to serve targetted "behavioural advertising".

Cleaning your own web server log files of tracking data is not going to be enough.

Any system that receives HTTP requests, including advertisers would have to honour the setting. But this does not just apply to advertisements. Look for anything hosted on another system such as:

• inline content (news, images, videos)
• JavaScript libraries
• trust seals (e.g. SSL certificate verification, privacy seals, trust schemes, tested for security, etc)
• web analytics
• widgets (e.g. buttons).

And these might be server from your own systems, not just third parties. Personal data may also be stored by the application on the user's own system locally. The question also arises what exactly constitutes "tracking", and whether audit and security event logs would be considered as tracking. Even traffic management and anti denial-of-service (DoS) systems track users to a degree, as of course does session management. Practices necessary to perform the designated service are likely to be acceptable, providing data are not kept indefinitely, and it is the usage for purposes which the user might not have expected, which is the real concern. Do users "expect" seceuity event logging? The examples on the http://donottrack.us/ discuss prevention of logging in web server log files, not other usages such as session management or incident monitoring. So guidance will be required.

The issue of tracking and personal data leakage may come as a surprise to some web site owners, and it was to the NHS, but is rather old news really. Like knowing all the components that make up your web site, and all the allowable entry points, knowing where you are sending data really is a baseline information requirement. The NHS example relates primarily to leakage of sensitive data to other parties, and the Obama example to security risks (see extended explanation.) The results of the FTC's final report next year will affect internet users worldwide as similar policies are likely to be adopted in other countries.

The FTC is asking for comments on its proposals by 31st January 2011. Their own suggested questions are listed in Appendix A of the report.

User tracking on web sites appears to be a growing concern amongst the public. The current What They Know campaign by the Wall Street Journal (WSJ) is making marketers techniques more widely known.

The mis-use of web cookies has received significant press coverage in the past, and now the mis-use of beacons (also known as web bugs) and Flash cookies (also known as Local Shared Objects or LSO cookies) is attracting attention. The WSJ examined popular sites and reported their findings online.

The value of personal data can be calculated in more than one way, is being debated and used for data protection business cases—marketers already know its value to them.

Marketers should be concerned that their own data collection and usage practices comply with legal and other requirements, and that these are described clearly to users in a comprehensible privacy notice. But if you have third-party content included within your pages, you also need to address those organisation's usage of the data they collect from your visitors. Third-party code may not just be from advertisers, but includes users analytics, embedded data feeds, video, photos and JavaScript libraries hosted elsewhere. For behavioural advertising purposes, check out the guidance from the IAB-UK.

Where possible try to ensure your web site's core functionality and design are unaffected if users choose not to accept content from other domains whilst viewing your pages.

Oh, and check your own site out with the Privacy Choice tool and ensure it is correct. Despite the name "privacy scan", it doesn't of course cover all the privacy aspects you need to take into account!

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?