Selecting and deploying a web application firewall (WAF) needs to be undertaken using robust due diligence procurement/acquisition processes.

A recent report (discussion) compares three different WAFs — two cloud-based systems and one that is integrated with web server software. The report describes testing SQL injection, cross-site scripting and local/remote file inclusion. I don't think the exact findings are of direct relevance to most real-world deployed applications, but the conclusions to be drawn are:

• Read this first
• Consider the rate of both false negatives and false positives
• Tune the WAF to your own application(s)
• Work your WAF - do not turn it on and forget about it
• Do not rely on a WAF

So, in summary, try before you buy.

See also Waffish Behaviour in 2012.

Tesco plc has been in the news in the last couple of weeks regarding security of its ecommerce web site and how this has now escalated into an investigation by the ICO.

Troy Hunt, security expert and generous contributor to application security community, reported his concerns at the end of July. The issue seems to have rolled on, and on, and and on. So it looks like there are at least password storage and cross-site scripting problems — two of the bare minimum OWASP Top Ten.

It appears Tesco has not taken application security seriously, and it has also managed to make matters worse by how it responded to valid enquiries from its customers and feedback via Twitter. Were these enquiries dealt with under an incident response plan? It seems unlikely. But this type of disregard for application security and failure to recognise valid feedback from customers is common. And, it is not limited to the UK retail sector. This isn't good enough.

Listen to your customers. Some of them might actually be trying to help you. For free. And they're not all muppets, whatever your corporate culture believes.

It is sometimes hard to find forward-looking resources about cross-site scripting (XSS).

Michal Zalewski has documented some thoughts in Postcards from the Post-XSS World inspired by his own work and by others. He describes how many XSS attacks attempt to exfiltrate data such as session cookies, alter the appearance of the targeted web site or perform state changes on behalf of the user. But where the theft of cookies is prevented by the use of the HttpOnly attribute, other common attacks are the extraction of personal data, anti-cross-site request forgery (CSRF) and capability-bearing URLs, and the alteration/destruction of legitimate content, delegation of account access, use of special privileges and propagation of attacker-supplied HTML markup.

Michal describes methods identified by himself and others that could still be able to perform XSS-like attacks even if a web site has deployed XSS defences such as using Content Security Policy.

If you are undertaking code review, security verification or penetration testing activities, this blog post is a must-read.

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?

A new edition of the OWASP Newsletter was published this week.

The December 2011 edition includes an excellent article by Gareth Heyes on protecting against cross-site scripting (XSS). He recommends a process of validating the type, whitelist checking, length validation, character restriction and context dependent output escaping, illustrating this with a number of detailed examples.

One to circulate to the development team.

While on the topic of research papers, I came across another interesting paper on the UC Berkely web site while checking the reference for the effect of development tools on security.

Joel Weinberger, Prateek Saxena, Devdatta Akhawe, Matthew Finifter, Richard Shin and Dawn Song have undertaken an assessment of cross-site scripting (XSS) sanitisation in web application frameworks. A Systematic Analysis of XSS Sanitization in Web Application Frameworks is somewhat heavy on the maths in places, but that shouldn't put off those involved in development who want to learn more about the difficulties of sanitisation and the limitations of the sanitisation methods that are supported in some frameworks.

The UK's Centre for the Protection of National Infrastructure (CPNI) has updated its guidance on protecting business applications with the publication this month of a new document on developing and implementing secure web applications.

Development and Implementation of Secure Web Applications is a well-written and digestible 81-page A4 document arranged in seven main sections:

• Introduction to web application security
• General aspects of web application security
• Access handling (authentication, session management and access control)
• Injection flaws
• Application users and security
• Thick client security
• Preparing the infrastructure

It appears to replace the good, but somewhat dated document "Briefing 10/2006 - Secure web Applications - Development, Installation and Security Testing" created by their predecessor National Infrastructure Security Co-ordination Centre (NISCC), and issued in April 2006. The new document is more compact and focused, and I think I prefer it. Yes of course it is more up-to-date, and while it would be possible to argue why some things are included and not others, these others things tend to be explained further in the references. It's clear there is considerable overlap with information from OWASP and the Microsoft SDL, but I'm sure the reverse is true to an extent too.

It is very encouraging CPNI have taken the time to produce an updated document, but that probably reflects the types of risks facing their audience. I am especially pleased to see the section on infrastructure, since application security cannot be an island on its own. I would say the guidance is probably on the medium-to-heavy weight side of advice, but that is probably appropriate for critical national infrastructure, and the document does discuss threat modelling initially. It might seem overwhelming to some organisations new to the subject, and that might need some help on what to do first.

I think the document could perhaps do with more cross-referencing to additional information resources elsewhere. Yes, documents can always be improved, and I am sure we will find niggles and faults with use, but threats evolve and so does our knowledge.

The OWASP AppSec Tutorial Series has been extended with the publication of a new tutorial about cross site scripting (XSS), probably the most common vulnerabilities in web applications.

The tutorial series project develops fast-moving educational videos which are short enough to capture the main concepts and issues in a very accessible manner. The series now comprises the following episodes:

1. Introduction
2. Injection Attacks
3. [Stored] Cross-Site Scripting

Project lead, author, narrator and editor Jerry Hoff has produced these videos with great flair, and I would recommend them as introductions to application security concepts in security awareness training. Watch out for future episodes.

A US survey of has found that 88% of companies spend more money on coffee than on web application security. We (in the UK) seem to legislate more on fruit juice than either coffee or web application security.

Whilst it was encouraging to read the section on security in the ICO's new Data Sharing Code of Practice, we do seem to have rather more detailed legislation on things like fruit juice than information security. The Fruit Juices and Fruit Nectars (England) (Amendment) Regulations 2011, which were laid before Parliament in April and come into force on Monday, define the minimum Brix levels (sugar content) for fruit juices from concentrate. Wouldn't it be great to see some similar highly specific legislation on securing online applications (and labelling) like this across Europe?

But, back to the coffee... Cenzic have issued their Web Application Security Trends Report Q3-Q4, 2010 which provides an analysis of reported vulnerabilities and breaches attributable to web applications. Its results confirm other recent reports that cross site scripting and SQL injection continue to dominate, despite these issues having being know about for a long time, and there being readily available methods to solve them.

But Cenzic and Barracuda Networks also commissioned the Ponemon Institute to survey 600 IT and IT Security professionals in the United States. The report's findings showed that most companies are spending more on coffee than keeping their web sites secure.

I'm sure the findings for tea in the United Kingdom would be similar. After all, there is a British Standard about how to make tea (BS 6008:1980/ISO 3103:1980). I can't find the application security standard from BSI (...just yet).

The third semi-annual "State of Software Security Report - The Intractable Problem of Insecure Software" has been issued by Veracode (see my previous comments on volume 1 and volume 2).

This report provides even more data on the types of vulnerabilities found and further comparison between applications by industry sector, company type, purpose, supplier type and time to acceptable quality. There is a wealth of statistics which will be useful to anyone looking to reduce software vulnerabilities including developers, testers and those in the information security industry. I'm particularly impressed by the thought that has gone into the design of the data-rich charts and the honesty about whether trends are statistically significant.

One aspect mentioned is that newer applications tested on first time submission are not much better than older ones (in this case "older" means "a year or so ago"). The reasons suggested are either lack of secure development practices, or such practices were performed but inadequately. But I wonder if this may be the result of Veracode's customers beginning to work backwards through their legacy applications, to assess and thus rank them for remediation effort? Therefore, these legacy applications will not have had the same degree of care and attention as perhaps more recently developed software.

The mine of information presented over 50 pages also discusses the relatively low level of security knowledge of developers, and the need to provide better awareness and training. But a new section in this report attempts to examine the remediation efforts. I really appreciate the effort that has gone into this and the presentation of so much data analysis. We have to thank Veracode's customers for allowing their data to be included in this aggregated data.

The report also discusses how there is a growing usage of third-party risk assessments, where the software is assessed independently using multiple testing techniques. In some sectors, software suppliers are increasingly being held accountable for the security quality of the applications they produce. I think that is a good thing.

While there is a comparison of different sectors, I wonder if it will be possible to delve greater into some details in future? For example, some large providers of outsourced development are also active in the software security space, and have their own products for static & dynamic security testing, and even provide software security consultancy services. Do those companies take their own medicine? Do they apply the knowledge and tools they offer in another part of their business in their own software development services? We probably won't find out any time soon, but it would be fascinating to know.

The report's data suggests web applications are still plagued by vulnerabilities such as cross-site scripting (XSS), information leakage and injection (SQL injection as CRLF injection). Meanwhile the most frequently found issues for non-web applications are buffer overflow, error handling and potential backdoors. Cryptographic issues are also very common. The majority of applications tested suffer from these well-known defects, and all of which are well documented and have a range of methods to solve them.

Good reading for the beach this weekend!