As many of my readers know, I have a keen dislike for regular expression based HTML sanitisation. Regular expressions simply do not understand HTML’s nested nature and the numerous possible HTML/CSS standards it must abide by. The result is that far too many developers try to program this understanding (and unfortunately their lack of comprehensive understanding) into home grown sanitisers using as little code and tests as possible.  It’s a horrendous and reprehensible practice that has created a large field of so-called sanitisers and XSS cleaners which are riddled with obvious vulnerabilities despite all their sincere and utterly false claims to the contrary. The perception of safety they create is almost always a fantasy. As I’ve said before, this serves only one purpose – to lend support to claims that PHP is insecure. And why disagree given PHP’s prominence on the internet and this continuing refusal by developers to just do the right thing and use a secure solution that really does work?

Since I’ve completed my research into a broad set of these, for now, I’ll close with a final example given its widespread usage, confusing documentation and lack of a clear disclosure to date of security vulnerabilities.

On April 7, EllisLab released CodeIgniter 2.0.2 as a security maintenance release prompted by a report I sent to EllisLab shortly before St. Paddy’s Day (around mid-March). That report indicated the expected response and my own disclosure policy. This blog post is being published in accordance with those. The disclosure to date of the vulnerabilities afflicting previous CodeIgniter versions is mentioned only in the CodeIgniter 2.0.2 news release (from April 7) as follows:

An update to both CodeIgniter Reactor and CodeIgniter Core (v 2.0.1) was released today. This is a security maintenance release and is a recommended update for all sites. The security fix patches a small vulnerability in the cross site scripting filter.

EllisLab’s news release for CodeIgniter 2.0.2 makes mention of “a small vulnerability”. This small vulnerability is mentioned no where else (not even the actual changelog for 2.0.2). In reality, I reported seven distinct vulnerabilities across two classes. These vulnerabilities might allow an attacker to inject arbitrary HTML, CSS or Javascript, i.e. Cross-Site Scripting (XSS) into an application’s output. It would be nice if, in the future, EllisLab aim for more accuracy in their news releases and disclosed both the number and nature of the security vulnerabilities fixed in their release changelogs.

Users of CodeIgniter 2.0.x and 1.7.x are strongly urged to upgrade to CodeIgniter 2.0.2 (or later) as soon as possible to avail of these critical security fixes.

In addition, users are urged to follow some basic steps when writing or updating CodeIgniter applications:

  1. Escape ALL data being injected into views using PHP’s htmlspecialchars() function, remembering to pass the character encoding being used as the third parameter. A helper function may be useful to keep the typing to a minimum.
  2. Use HTMLPurifier when you need to sanitise HTML data or user input such as HTML comments, HTML emails, or RSS/Atom content (basically any HTML you do not explicitly generate yourself!).
  3. Ensure that all HTML pages are served with a valid Content-Type HTTP header and/or a meta tag equivalent which also declares the charset for that page. Note that HTML5 offers a separate charset element for this purpose. This helps prevent character encoding based XSS attacks by informing the browser of the correct character encoding to use.
  4. Ensure that all views/templates distributed by third parties are likewise reviewed to ensure they utilise proper escaping and XSS sanitisation.

CodeIgniter is one of the most prominent “micro frameworks”, web application frameworks that prosper by offering their users unparalleled simplicity. It is unusual as a framework in that it does not make any reference to standard escaping mechanisms for views/templates such as the PHP htmlspecialchars() function anywhere in its source code, examples or documentation. This may create the unfortunate impression that users should instead filter input using an XSS filter function in the CI_Security class and do nothing on output. Users taking this approach may be particularly at risk from these security vulnerabilities.

My recommendation to the CodeIgniter developers, as documented in my original report, is to deprecate and remove the CI_Security class’ XSS filter. Responsible vendors should never persist in distributing and advocating the use of insecure software. I also urge them to revise their documentation to ensure that best security practice is noted in the area of writing views/templates and offer a shortcut function to an escaping mechanism for HTML output to standardise and ease its use by members.

Enhanced by Zemanta

Related posts:

  1. Regex HTML Sanitisation: Off With Its Head!
  2. Open Letter to Gareth Heyes: Regex HTML Sanitisation Doesn’t Work
  3. HTML Purifier 2.0.0 – new version of the PHP HTML filter library
  4. Zend Framework Proposal: Zend\Html\Filter (HTML Sanitisation And Manipulation)
  5. HTML Sanitisation: The Devil’s In The Details (And The Vulnerabilities)