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!

In November I discussed Content Security Policy (CSP), a new method to help mitigate Cross Site Scripting (XSS) vulnerabilities.

Earlier this month Content Security Policy was formally submitted to the World Wide Web Consortium (W3C) as an unofficial draft. This is a very early, but encouraging, step on its way to becoming more formally accepted.

Last week Firefox 4, which supports CSP, was officially launched by Mozilla Foundation. There is a good summary of all the security features on the SANS web site.

A new study from IBM has highlighted the prevalence of certain types of vulnerabilities found in JavaScript on many web sites.

The report was the result of an investigation to find DOM-based Cross Site Scripting (XSS) and open redirects by an automated testing process. The investigation examined JavaScript code from 500 web sites of the largest private listed US organisations and 175 otherwise popular sites. IBM's approach automated the analysis using both static and dynamic testing.

JavaScript is highly prevalent due to the use of Web 2.0, AJAX and rich internet applications. Slightly over 14% of the sites were found to contain vulnerabilities, the majority of which included OM-based Cross Site Scripting issues. The vulnerabilities could be exploited by malicious people to infect users with malware, hijack user's sessions, perform phishing attacks on the users or to spoof the content. A third of these problems related to third-party JavaScript code such as widgets, embedded code and JavaScript libraries.

Even though the investigation "only" examined a sub-set of about 200 pages per site, and did not submit forms or access areas requiring authentication, the findings are significant. They show that it is possible to identify these types of vulnerability in an automated manner, but whether this can be done accurately with low false positive and false negative detection rates is still to be determined. The degree of coverage was not disclosed in the report, so the 14% value could be under reporting the problem.

And remember, "don't try this at home" — you really do need permission to test other people's web sites.

Content Security Policy is a way for site owners to define how content in their web site or web application is meant to behave, and have this enforced by the web browser.

Content Security Policy is not a magical solution to every security issue, but it addresses one aspect in particular. The primary goal of Content Security Policy is to mitigate Cross Site Scripting (XSS) by providing a way for site owners to specify which domains the browser should treat as valid sources of script. Therefore, the policy defines a whitelist of sources and the type of content those sources can contain. Compatible web browsers (user agents) or add-ons/extensions which support CSP will then only execute scripts from thee whitelisted domains. CSP can also be used to help mitigate clickjacking and packet sniffing attacks by specifying which domains can embed resources and specify which protocols (schemes) and porst can be used (e.g. serving a site over HTTPS on port 443 only). Non-supporting browsers will disregard the Content Security Policy (CSP) header and will default to the standard same-origin policy for web page content.

Episode 75 of the OWASP Podcast Series was an interview with Brandon Sterne (Mozilla), chief author of CSP. He highlighted that when a site declares and enables a CSP, even if only a small proportion of users are using a CSP compatible browser, both the site owners and other users will benefit. This is because the site owner can receive notifications whenever the policy is broken, using a real-time violation reporting mechanism, and this would alert the owner to there being some sort of script being injected or the existence of some other type of content that wasn't explicitly whitelisted. This allows the site owner to investigate and adjust the policy or mitigate/fix as appropriate. He used the analogy of a "canary in a coal mine" which gives advance warning of a coming crisis.

If you have read the specification and are considering implementing CSP for an existing web site or application, ensure your development environments has all the up-to-date code including JavaScript libraries. The first thing to understand is whether existing code and included libraries violate the base restrictions. These are independednt of content originating from other domains, and need to be addressed before any consideration is made of third-party content.

Base restrictions

The base restrictions, regardless of your own policies, are all good practice:

• no inline scripts
• no script code created from strings
• no data from URLs (unless allowed by policy)
• no XBL bindings except for those loaded by the "chrome:" or "resource:" protocols

Usually the first of these is probably the most common problem to have unless development practices have excluded inline scripts from working practices. It is far too easy for inline scripts to creep into page templates, if only for simple event handling such as "click", "rollover" and "rollout". When reviewing replacement code for these types of event, do consider whether the functionality can be replaced with non-script alternatives (e.g. CSS rollovers, HTML5) before developing new JavaScript code. At the same time, take the opportunity to review accessibility requirements at the same time—WCAG 2.0 has plenty to say about events.

Replacing inline JavaScript events with separate files with a content-type of application/javascript or application/json, often involves having to build in more adjustments to make the code compatible with the range of web browsers in use currently. This is more awkward and not necessarily straightforward.

The base restrictions can be weakened using the "options" directive but the risk of doing this, and the reduction in benefit to the site owner, need to be balanced with the effort in moving/changing/removing code. In the longer term, try not to modify the default behavior.

Bespoke and third-party JavaScript libraries, frameworks and widgets used within the site or application also need to be reviewed. This can be where the process becomes more difficult; if third party code doesn't meet the baseline restrictions, you have to consider whether to patch it, or replace it with something else, or remove the associated functionality, or weaken the baseline restriction as described above.

The "out of the box" experiences with some common libraries are shown below. These results are for a tight "allow 'self'; frame-ancestors 'none';" policy where the code library is included in a web page—but not making any calls to the functions. "-" indicates no violation of base restrictions occurred when the library was loaded.

Rico was unavailable to download at the time of the tests. These quick checks didn't exercise use of the libraries—you will need to test relevant code in your own context yourselves. Of course, it could be argued that medium-high risk web sites and applications shouldn't be using third party code, but using these established libraries saves effort, and may reduce faults in custom JavaScript code.

Policy

Before creating the policy itself, you need to understand all the content included in the site and from which sources (scheme, host, or port) they are drawn from. It would be nice to believe this is already documented, but even if it is, check it is up-to-date. Extra code might include a widget, inline advertising or tracking code. These can usually be identified by an examination of the site source code and/or the results of spidering (traversing) the web site or application.

The policy can be defined in its entirely within the X-Content-Security-Policy HTTP header, or the header can reference a URL (policy-uri) with the same origin (scheme, host, or port) of a file containing the security policy. If you use the file method, make sure this is included in any application entry point permissions.

Security violation report

The security violation report is used to alert site owners of content that does not comply with the CSP. Ensure that all requests sent to the URL specified are logged securely. You may want the option to issue alerts to administrators and/or build this into existing integrated security event management systems. If an application has been thoroughly tested, violation reports should be treated with due attention. However, the site may also receive direct requests for the URL itself (by web crawlers, or people probing the site) and the report content could be forged. So, do add an exclusion for the URL to your robots.txt file, and treat the content with suspicion.

The mandatory "allow" directive defines the security policy for all types of content, but this can be tailored for particular content types (images, audio, video, scripts, style sheets, fonts, frames, XMLHttpRequests and object, embed & applet elements) using other directives. begin with assuming that all content only comes from the same source (allow:'self') and check what contravenes this. Before allowing an additional source for particular content types, consider whether the content can be included locally, or replaced in some way. For example can the font files referenced in CSS files be stored on the site instead of referencing another site? This reduces also inter-site dependencies.

File caching may mean that you receive violation reports some time after you have corrected your code to match the policy.

Note that by the inclusion of an "X-Content-Security-Policy-Report-Only" HTTP header, you can operate in Report-Only mode, suppressing enforcement of the policy in the browser, but continuing to receive the violation reports.

Concluding thoughts

CSP will be a great benefit for site owners and (some) users alike.

You may get some push back when it is realised there is some effort to implement CSP correctly, so be wary of online services being taken off the primary corporate site to make it easier to use CSP, especially when the services are moved to possibly less-secure third-party providers hosted elsewhere. That doesn't actually reduce the organisation's risk, nor that of the users.

For additional background on CSP, read the paper by Jeff Hodges and Andy Steingruebl of PayPal The Need for a Coherent Web Security Policy Framework, the references in the paper, and some discussions during the idea's development. See also the additional information including a link to download a beta version of Firefox 4 which supports CSP, a demo and a link to a plugin for WordPress.

Some other blog posts relating to Content Security Policy within the last week or so are:

• Content Security Policy introduction
• Preventing XSS with Content Security Policy
• Progress towards fully implementing X-Content-Security-Policy

CSP is not an excuse not to do proper input validation and output encoding, but it does assist identification of problems if they occur, and will help to protect some users who are using a CSP-compliant browser or extension/add-on. That may not be a huge number of people at the moment, but there are efforts to make this more mainstream. For example CSP is listed as deliverables of the new W3C Web App Security Working Group. Keep your eyes and ears open, but do begin to consider the issue in new projects and larger changes to existing web sites and applications.