Almost every sale, citizen enquiry and support request now seems to lead to being asked to complete an online customer survey. Almost without exception, the user experience, privacy and security of these online customer surveys are worse than the service being asked to comment on. Here are a couple of customer surveys I was asked to complete last week.

Problems with using SSL, such as shown above, do occur but more often than not people are asked to submit personal identifiable information and other forms of personal data without the use of SSL. Bad layout, poorly designed questions, missing privacy notices and improper validation are extremely common. Many forms have mis-configured web sites that give away sensitive information about how the site and server are set up when they don't work:

And on Saturday I was given a coupon given at a shop's physical checkout to provide feedback on how they did with the chance of winning an iPod or cash for doing so. Yesterday I typed in the URL from the coupon, entered the required store code, and... that was the end of that marketing exercise:

I didn't time out as the message suggested, unless you have less than 5s to answer one question. Perhaps there is only one custom error page for all server-side errors, or the wrong error page is assigned? Points for hiding internal error messages, but still a failure.

Is 3/3 customer surveys tried in the last fortnight broken just bad luck? Or does it indicate a poor standard of such efforts? One of these is an international consumer brand, another a major UK High Street retailer and the other, a medium-sized business services company. I can't quite remember the the previous customer survey to these three, but I think it may have been a salary/skill survey. That had poorly thought-out questions and although it didn't obviously fail, it did ask me to log in on submission. So I'm not sure if that meant my efforts had been saved or not.

Do all these problems and errors mean the data from other people's forms that were successfully submitted (if any) are less valid? I can imagine management decisions are being made as a result of the survey feedback (if not, why waste everyone's time?). What is the effect on data quality? It could be that some forms fail when a particular answer is selected or left blank—this could be important marketing knowledge, and if no responses include the particular option it may be incorrectly assumed no-one selected it. The management decisions will be being based on poor data.

Perhaps part of the problem is that customer surveys are often managed, operated and hosted by third parties due to the ease of implementation. But "easy" doesn't mean it meets your own organisation's standards, or general good practice. You are still accountable for the web issues and it's your organisation's reputation that will be affected detrimentally.

Good design, privacy and security impact assessments, thorough testing and verification are required like any other other addition to a web site. Analytics should be used to track survey users through forms and this data combined with server logs of access and errors generated by the web server. Prove your marketing data are valid before you use it in business decisions.

The next Open Web Application Security Project (OWASP) London meeting is this week.

The London chapter meeting is on Thursday 14 January 2010 in EC1. Everyone is welcome, but you need to register first (free).

There will be talks on Top Ten Deployment Mistakes That Render SSL Useless by Ivan Ristić and Using Selenium to Hold State for Web Application Penetration Testing by Yiannis Pavlosoglou, who recently joined the OWASP Global Industry Committee.

Unfortunately I am unable to attend the meeting but hope to read the presentations afterwards.

Today the Council of Registered Ethical Security Testers (CREST) and CESG, the UK national technical authority for information assurance, are running the first Ethical Security Testers Conference at Royal Holloway, University of London.

I am attending the conference on behalf of the Open Web Application Security Project (OWASP) Global Industry Committee. Apart from the web security related presentations, I am particularly looking forward to hearing about CREST's progress and the future of CREST/CESG certification schemes.

I will update this posting at the end of the day tomorrow.

Update 16th December 2009: There were many familiar faces at the well-attended first conference. CREST and CESG had put on an interesting programme of mainly technical speakers—the demonstration of the Context App Tool was particularly useful for the application testers present, and I'm looking forward to trying the beta 3 version. Infrastructure security testing presentations were given on USB drivers, Windows authentication, CISCO IOS, deployment solutions and full disk encryption products.

CREST and CESG outlined their vision for information assurance professionalism, and it sounds like the CREST scheme is growing in momentum both in the UK and overseas. It seems there may soon be CREST services available in South Africa abd Benelux, and mention was made of some potential partnership with the SANS Institute.

As I prepare to go to OWASP BeNeLux Day 2009 tomorrow to speak about compliance driven vulnerabilities in web applications, the aspect of auditability came to mind.

Audit logs record user-initiated activity (human or otherwise) in a system or application. They are a trail to establish accountability and responsibility for processed transactions i.e. what, when, where and who. Some form of audit trail is often specified in a web site's requirements, but this is often incorrectly seen as independent to other requirements. All software test cases should also identify the expected audit trail outputs and check they are being generated correctly:

• It is not sufficient for the user functionality to match the requirements alone.
• The generated audit trail must match the tests undertaken.
• It must be possible to determine the original actions from the audit trail.
• Mis-use cases should generate appropriate trails as well.

In-built audit hooks (embedding code in applications for the examination of selected transactions) and continuous auditing (near real-time auditing logic) must not introduce their own vulnerabilities:

• The extra complexity of audit code in an application requires additional security verification.
• Identify the trust boundaries around these parts of the application.
• Ensure the audit code cannot be used by malicious users to circumvent other controls such as authentication and authorisation.

Test cases will also need to be prepared to verify the protection and management of the audit trail. Ensure the integrity of the audit trail:

• The trail must be protected from subsequent modification (alteration and deletion).
• Even if the amount of logging is configurable, the default should provide sufficient detail for the business's needs.
• It should not be possible to completely inactivate all audit trail generation.

NIST have a useful document SP 800-92 on management of security logs—many of the considerations are similar for the protection of audit trails.

The extraction and examination of audit trail data must be controlled:

• Audit trails may contain personal and other sensitive information.
• The data may give away information regarding the application's code and logic.
• Consider whether parts of the data may need to be excluded, masked or encrypted.
• The privileges to read audit trails should be restricted and reviewed periodically.
• All access to the audit trail must be recorded and monitored by a separate manager.
• Audit trail data must not be destroyed before the duration of its required data retention period, and not kept beyond this time.

Remember that in some jurisdictions, capture of any personal data or monitoring of employees may need particular approval and safeguards, and some data may not be allowed to be stored at all. Happy verification!

What are the business risks of using cloud services? Well, the European Network and Information Security Agency (ENISA) has published a thorough review of cloud computing benefits, risks and recommendations.

I have mentioned web application security in the cloud on two occasions previously, but what are the wider issues? Risk assessment explanations can sometimes be rather dry and lacking in practical examples. The majority of ENISA's document is a walkthrough of a risk assessment for a real SME use case. Wow, not a bank!

In this particular use case, and it would of course be different for each organisation, the greatest risks were found to be loss of governance, compliance challenges and risk from changes of jurisdiction.

Whilst the analysis does not represent a real company nor any particular cloud services, the approach can be used by anyone wanting to undertake an analysis of the cloud computing risks in its own context. The document examines the risks for:

• software (application) as a service (SaaS)
• platform as a service (PaaS)
• infrastructure as a service (IaaS)

and details:

• technical risks
• legal risks
• risks not specific to the cloud.

A non-exhaustive list of vulnerability categories and asset types is included together with recommendations for an information assurance framework, legal recommendations and a thorough checklist of information assurance requirements. Overall, extremely useful.

If you have already assessed the risks and want more detail about information security, the guidance document from the Cloud Security Alliance is worth reading. Dennis Hurst (HP) spoke about the forthcoming update to this document at OWASP AppSec Washington DC 2009.

Web applications that process, store or transmit payment card data fall under the Payment Card Industry Security Standards Council (PCI SCC) Data Security Standard (DSS) requirements where they are being enforced by the merchant's acquiring bank or card processing company.

PCI DSS

PCI DSS 6.5 (version 1.2) requires the use of secure coding practices that cover prevention of common coding vulnerabilities in software development processes including the vulnerabilities listed at 6.5.1 through 6.5.10 (taken from the OWASP Top Ten 2007).

PCI DSS 6.6 (version 1.2) requires addressing new threats and vulnerabilities on an ongoing basis and ensuring public-facing web applications are protected against known attacks by either review via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes or by installation of a web application firewall (WAF). This is to ensure web applications exposed to the public internet are protected against the most common types of malicious input. If a WAF is used, a recommendation is that it "react appropriately (defined by active policy or rules) to threats against relevant vulnerabilities as identified, at a minimum, in the OWASP Top Ten and/or PCI DSS Requirement 6.5.".

OWASP Top Ten

Therefore the OWASP Top Ten is inherently linked with PCI DSS Requirements 6.5 and 6.6, and updates to it affect PCI DSS compliance. At the OWASP AppSec DC2009 in Washington, the OWASP Top Ten project announced release candidate 1 (RC1) for the Top Ten 2010. The RC1 document is open for comment until 31 December 2009 and is expected to be finalised in January 2010. This will affect every merchant and payment gateway with a web-facing application in scope that is required to be PCI DSS compliant (e.g. merchants and service providers where Self-Assessment Questionnaire validation type 5 applies).

The Top Ten has been revised to focus on risk rather than vulnerabilities. For each web application security risk, the Top Ten document provides an explanation of the risk, how to determine if a web application is vulnerable, how to prevent the problem, example attack scenarios and references. Yes, that's right— you can actually prevent all of these risks, unlike many other risks that business fave which can only be reduced, accepted or ignored.

There has already been discussion concerning:

• the use of a risk-based ranking;
• the degree to which umbrella categories (e.g., A1 Injection) should be used to group multiple risks;
• whether proper error handling is included within A6 Security Misconfiguration; and
• the use of business-related language rather than attack/weaknesses language.

Actions

So what needs to be done? Well, nothing immediately unless you have some feedback on the new document. But prepare for a change in PCI DSS compliance requirements. If requirements 6.5 or 6.6 apply to your systems, this could include the following:

• If you have explicitly detailed the ten vulnerabilities listed in 6.5.1 through 6.5.10 in any internal compliance documents, standards or policies, these will need to be updated to the new risks.
• The vulnerabilities covered in the software development processes of your own web applications may need to be altered.
• Web application vulnerability assessments and/or web application firewalls, need to ensure they address the new listed risks.
• Discuss with your advisors or auditors when the changes apply to your own operations to achieve continuous compliance.

In practice, you may also want to start looking at the Application Security Verification Standard (ASVS) for web applications which gives a broader view of application security issues than those in the Top Ten.

But remember, the Top Ten was of course only meant to be the most important risks to web applications and as the new 2010 RC1 version states, the Top Ten is only the first ten. Your processes, reviews and controls should already be addressing the "new" risks. They are new in the Top Ten, not new problems.

Two recent reports discuss the growth in web application vulnerabilities.

The latest Microsoft Security Intelligence Report on threats, vulnerability disclosures, exploits and malicious software in the the first half of 2009 highlights, amongst many other things the growth of automated SQL injection attacks. It is both broad and deep, but with coverage on all types of software — operating systems, applications and web applications.

There is more detailed information about web application vulnerabilities in the previously discussed WASC Web Application Security Statistics and to a certain extent in the IBM X-Force Trend and Risk Report which suggested the growth of vulnerabilities in standard (off-the-shelf) software web application is beginning to plateau.

The IBM report suggests that web application vulnerabilities account for around half of all vulnerability disclosures. These are mainly cross site scripting (XSS), SQL injection, and file include vulnerabilities.

I had made a note to write about web site awards, only to find a whole year has passed.

Well I had a look at this year's AOP Awards, especially the ones for web sites and web applications. At a glance browsing a few pages on each of the winners' web sites, you can immediately see web vulnerabilities. I wonder how many more security faults would be found in a simple security verification assessment of the winners of this and other competitions and awards?

Shouldn't web awards have some minimum standards, and shouldn't these be requirements for nomination? I'd suggest there should be a threshold level for privacy, security, usability, accessibility and compliance with legal requirements, before an entry can be accepted.

After all, we wouldn't expect to give a prize in a boat show to something that doesn't float.

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?

The Web Application Security Consortium (WASC) has published its Web Application Security Statistics Project 2008.

The data has been gathered from anonymous submissions by eight organisations about their web application security assessment projects in 2008. The large number of projects gives a good spread of data, though of course it excludes web sites and web applications that have never been tested.

The owners of web sites and web applications that are not included here will include those validated/tested by others, tested internally and not tested at all. The latter may include simpler, less functional web sites or those where the potential damage is considered to be less than the cost of application security validation/testing. Nevertheless, the data are important for web developers, testers and auditors for many reasons:

• The most common vulnerabilities are listed—they are nothing new and demonstrate where greater effort is often required to standardise code and stamp these out.
• The risk assessment methodology is explained and can be used as a guide for internal assessments.
• High risk vulnerabilities are common (more than 80% have urgent and critical vulnerabilities), even in applications that are likely to be considered more important, and therefore are being tested by independent third parties.
• Organisations that are required to be PCI DSS compliant, may be failing to ensure their web sites meet the requirements.
• Manual white box (full knowledge) testing is needed as well as automated scanning to detect many vulnerabilities.

All the contributors to this project should be thanked for sharing their insights with us.