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?

A couple of weeks ago I mentioned listings of user agent (browser identifications). But can this data be helpful in validating logged in user sessions?

Session data (relating to the user) should be stored on the server rather than in cookies or locally on the client (browser) and this is often referenced by a unique, difficult to predict, session identifier, usually set as a secure, httpd-only, temporary cookie. It is sometimes better to validate the session identifier is still being used by the same user it was issued to. Apart from checking the session is still valid (exists and has not expired), you can also check that it corresponds to the same IP address, or at least an IP address range. It's also possible to build into this, checks that the following Hypertext Transfer Protocol (HTTP) request headers haven't changed:

• User agent
• Acceptable languages for response
• Acceptable encodings for response

by storing these properties, or a hash of them, along with the session identifier in the web application's database. They should not change. These additional checks make it harder for someone else to impersonate the (authenticated) user.

You might wonder how unique user agent data can be. In an attempt to determine the uniqueness of browser information and whether this constitutes personal data for privacy protection because it identifies them, the Electronic Frontier Foundation (EFF) has released a new online tool called Panopticlick to let you calculate how unique your own web browser fingerprint is. The test identifies the user agent string, HTTP accept headers, browser plug-ins, time zone, screen size, screen colour depth, system fonts, whether cookies are enabled and storage settings. There is a good write-up about the personal data issues on the Tech and Law blog. But can we use this data for session tracking?/p>

I tried three browsers with Panopticlick:

• Firefox 3.6 running several add-ons (FF3.6)
• Opera 10.10 with JavaScript enabled (O10)
• Internet Explorer 8.0.6 (IE8)

which indicated that all three browser's fingerprints were "unique among the 71,823 tested so far" with at least 16.13 bits of identifying information.

The differences appear to be related to how much information could be gleaned from the browser and system, with plug-ins, screen dimensions and system fonts being very unique—the computer has two graphics packages installed and several custom fonts. Making the browser full screen reduced this aspect's uniqueness, but had no overall change in the browser's identifiability.

This means that some of these data could be used to check for impersonation or even to help identify returning site visitors without setting cookies or requiring people to log in, but you would have to be careful because some browsers won't send all of this data e.g. if JavaScript is disabled. For example, with NoScript enabled, FF3.6 reported as only one in 2,433 browsers with the same fingerprint and that it conveyed 11.25 bits of identifying information instead of over 16 bits.

Further reading about the scary things here and here that JavaScript might be able to detect about your computer and network.

You may have heard some news about cookies, consent and the Council of the European Union in the consideration of the confidentiality the communications. Well, the legislation has been passed and the regulators is each nation have until 26th April 2011 to implement it.

The legislation amending Directive 2002/22/EC on universal service and users' rights relating to electronic communications networks and services, Directive 2002/58/EC concerning the processing of personal data and the protection of privacy in the electronic communications sector and Regulation (EC) No 2006/2004 on cooperation between national authorities responsible for the enforcement of consumer protection laws, will require that prior consent is required before cookies are set:

What will this this mean for authentication and authorisation cookies that use cookies for session management? If the cookies are a mandatory part of the purpose for which the user is undertaking (i.e. requested access to an area that requires authentication), there is an exception:

Note that there is no exception for cookies for advertising, web analytics software, security logging, usability testing etc., and it would seem that prior consent will be required for those. Although 2011 may seem a long way off, new applications in development and changes to existing applications should certainly be considering the implications, and owners of existing web applications should be assessing the possible effects and make plans once UK legislation is passed and guidance issued.

Additional discussion:

• Telecoms package conciliation: MEPs and Council representatives agree on internet access safeguards
  Press release, Euroepan Parliament, 6 November 2009
  http://www.europarl.europa.eu/news/expert/infopress_page/052-63798-309-11-45-909-20091105IPR63793-05-11-2009-2009-true/default_en.htm
• An Analytics Problem for the UK Public Sector
  The Pickards, Blog, 25 October 2009
  http://www.thepickards.co.uk/index.php/200910/an-analytics-problem-for-the-uk-public-sector/
• Consent will be required for cookies in Europe
  Out-Law News, 9 November 2009
  http://www.out-law.com/page-10510

I don't feel as pessimistic about this as Out-Law seem to be. Perhaps we'll see opt-in services being provided by the advert distribution agencies, rather than by each individual web site.

This weekend the clocks change as we revert from British Summer Time (BST) to Greenwich Mean Time (GMT) at 02:00 BST on Sunday 25 October 2009 and the clocks go back, giving an extra hour.

What does this mean for web site security? Does running 01:00 to 02:00 twice matter? Well some brave web application owners will be disabling their systems like this online bank:

And, I don't think it's just being done as a finale to the current Energy Saving Week. Most people, quite rightly, won't be taking this rather severe step. Another millennium bug anyone? The date/time should be considered rather like other untrusted user input. Most problems will probably fall into the "business logic" category such as:

• Failure of time-based logic where dates are being compared.
• Assumptions of uniqueness in time-stamped output (e.g. by a single-threaded process).
• Running tasks again leading to possible:
  • loss of data due to overwriting
  • duplication of exports or emails
  • creation of inaccuracies in management information.
• Chronological ordering anomalies leading to other faults.

It's not just banks and other financial organisations that may have difficulties.

The time change may expose some other vulnerabilities that only exist at changeover time and/or during the next overlap hour.

• Circumvention of brute force attacks on user authentication mechanisms.
• Increased risk due to extension of a session's validity where local time is recorded.
• Failure in data validation routines for time-related comparisons.
• Incubated vulnerabilities where a time-related aspect causes the attack to be possible.
• Denial of service due to extension of account lock-out.
• Using time as a loop counter.
• Additional errors caused by any of the above leading to information leakage.

Recording the offset of local time to GMT/UTC and synchronisation should certainly be done, but may not resolve the time overlap issues. The effects on long-running "saga" requests might be especially difficult to determine. Time dependencies need to be specified and considered through the development lifecycle. Perhaps the bank is right after all?

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.