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?

It's common for access to some web sites to be restricted to users from particular Internet Protocol (IP) addresses. This is usually in addition to some other identification and authentication method. But other IP addresses are often added to this "allow list" and these should not necessarily be trusted in the same way.

In a typical scenario, a web site hosted on the internet that is used to administer another web application might be restricted to the company's own IP addresses. Then the developers say they need to check something on the live site, or another server needs to index the content, or someone wants to work from home for a while, or the site needs to be demonstrated at a client's location. All these additional IP addresses are added to the "allow list". These restrictions may be being applied at a network firewall, traffic management system, at the web server, in the application itself, in intrusion detection systems or in log analytical software, or in many of these. These are difficult to manage and in time there will be many IP addresses that no-one knows why they are allowed unless they are carefully documented, and subject to a fixed time limit when they are confirmed again by an appropriate person or removed. These extra addresses are quite often hard for someone else to guess.

However, there is another area where IP addresses are added to "allow lists", and this is for remote monitoring and testing services. These might be checking uptime, response times, content changes, HTML validation or security testing. The service providers publish the IP addresses of the source systems so that companies can specifically allow access to their web sites. Since the number of these services is relatively small, it's not too difficult to find which one might give access to areas of a web site or web application that the public (and malicious people) should not be able to get to. The particular danger here is that the IP addresses might be excluded from monitoring and logging, and therefore even a diligent web site manager might not realise for example the uptime monitoring service is making unusual, or excessive, requests.

Although it is not likely a malicious person is using this "trusted" address unless routing has been compromised as well, problems can go undetected, from what might seem to be a legitimate source. The IP address may have been typed incorrectly, or worse, the restrictions/exceptions may not have been implemented correctly allowing more addresses to have the privileged access than intended. Not logging a user's session is privileged access.

Allow traffic through, but be very specific what is allowed and monitor what's going on. Review all the exceptions periodically. Be especially careful about anything that bypasses authentication (such as allowing a search engine to crawl restricted-access content) on an otherwise public site.

An article on eConsultancy.com discussing the demise of the tr.im URL shortening service mentioned some information security concerns:

There are good discussions concerning URL shorteners on Joshua Schachter's blog, the Mashable social media guide and the Security Retentive corporate information security blog. These will be a little technical for many people but essentially, apart from the privacy aspect of collecting data, other things might be worth worrying about more (you need to check this!). If you can, create your own aliasing/redirecting system on your own domain. But make sure it can only be used to redirect to a limited number of your own website's URLs.

Interestingly, tr.im is another example where organisations may have been using a service for which they had no contract, service level agreement or rights when the service was withdrawn. Be careful what you reply upon.

The news that a the UK hosting company VAServ lost 100,000 web sites all at once is devastating for the organisations involved. It appears that many cannot be recovered and a considerable number do not have recent backups.

From the temporary status page dated 10th June:

The event was widely reported:

• Webhost Hack Wipes Out Data for 100,000 Sites
• Webhost Denies Poor Passwords Led to Catastrophic Hack
• U.K. Web Hoster, Customers Scramble After Attack Deletes 100,000 Sites

Particularly sobering is the news that the CEO of LxLabs, implicated as the developers of the software that was hacked, has committed suicide:

• LxLabs boss found hanged after vuln[erability] wipes websites
• Web Hacking Incident Database (WHID) 2009-45: Outcome: Death

Even if you don't have a formal disaster recovery plan, at least make sure you have backups of all your site code, database and other data.

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.

Bad (and severe) weather can have unforeseen consequences for online businesses. The virtual businesses may still be affected by human factors.

Last year, I recall during some flooding, that although a call centre was safe from the effects of the weather, its staff couldn't get to work and therefore the disaster recovery plan had to be invoked. I wonder how many online business are feeling the effects of last night's snowfall.

This message appeared on the Current Awareness service from the Inner Temple Library providing "up-to-date" UK information on new case law, changes in legislation, and legal news:

Other web sites weren't affected by lack of staff, but by too many users. This is something that website load stress testing can help analyse. Loss of availability comes in many guises and sometimes "snow" and "customers" may not be considered at the same time as other threats during a risk assessment.

Tomorrow's forecast isn't looking so good either.

Version 3 of the Open Web Application Security Project (OWASP) Testing Guide has been released after a 6-month period of addition, enhancement and review.

The OWASP Testing Guide is an ideal reference for both developers and testers—version 2 was fantastic, and this new version is even better. The testing framework now covers 66 controls and, like in the previous version, each control has a brief summary and is described in detail followed by black box (no additional knowledge) and grey/gray box (partial knowledge) testing methods and examples where appropriate.

The controls and testing methods are fully referenced to provide additional guidance and explanation.

The controls are grouped into ten categories, including new separate categories "Authorization" and "Configuration Management". I'm especially pleased to see the latter broken out on its own, since even a perfectly coded application can have vulnerabilities introduced during deployment and changes to the application.

The OWASP Testing Guide now also includes a "best practice" penetration testing framework and a "low level" penetration testing guide that describes techniques for testing most common web application and web service security issues. More information is available on the Testing Project pages.

Functions to unsubscribe, be removed, cancel or opt out from newsletters, mailings and email alerts can be used to undermine web site security.

Many techniques are used to unsubscribe including:

• Email message to a particular address, possibly with a keyword like "unsubscribe" in the subject or body
• One click opt out unsubscribe hyperlinks
• Hyperlink to a form with additional validation
• Log into an account management area to make a change to communication preferences
• Pre-paid response postcard
• Telephone call to a helpdesk.

Some examples from email alerts are shown below:

It is important to make it simple for people to opt-out of such services, but there are a number of problems that can get built into such systems:

• Hyperlinks that only pass an email address as a parameter can be used to find whether particular addresses (such as known individuals) are registered/subscribers - this could be used for user name enumeration if there is a separate log in area and the user names are email addresses
• Hyperlinks with only predictable identifiers can be guessed
• Systems could be used maliciously to unsubscribe other people's accounts
• Hyperlink options could automatically log people in to their accounts - this should not occur since the links could be accidentally forwarded on to other people
• Any validation (authentication) systems must be at least as secure as other functions such as log in to access account details, so that the unsubscribe facility cannot be used to obtain log in credentials (e.g. limit the number of attempts possible, log failed attempts, lock accounts, add delays to failed attempts, etc)
• Unsubscribe by hyperlink or email must have the same level of checks (not more or less) as non-electronic means (telephone call, written, etc) otherwise the weakest method could be used by a malicious person
• Text-only versions either not including or not rendering the unsubscribe hyperlinks correctly (e.g. wrapping the link), so that only rich-text email users can see and use the links
• Anything sent by email is normally not considered secure
• Do not give away any other sensitive information on either successful, or unsuccessful completion (e.g. "Thank you Margot Dyson, we will send a letter to your address in Hastings to confirm this request")
• Clearly distinguish between opting out of particular correspondence, types of contact (e.g. direct marketing), all correspondence and closing accounts altogether - you may have to contact the person for some other valid reason.

In all cases, the completion of unsubscribing should be accompanied by a message to the person informing them of the change of status (by email or some other method). Where this hasn't closed their account, and they can log on to undertake other processes, the event should also be recorded for them to see in a list of recent actions.