Indistinguishable from line-noise.

CSPR.NG Blog

CMS Airship < 1.1.2 - Stored XSS Post-Mortem

Earlier today, a stored XSS vulnerability was reported by Lucas Reschke and fixed in version 1.1.2. Unfortunately, this news arrived at the same time as I discovered the auto-updater was refusing to run. If you've set up your own Airship already, you'll need to manually update to the latest version (1.1.3).

The Vulnerability

There were several locations, but most prominently in the "name" field of an Author, which could store an XSS payload. On two pages, this payload bypassed Twig's auto-escaping and could trigger Javascript in the end users' browser.

Sounds bad, and you should definitely update if you haven't already, but the impact was severely mitigated by our default configuration for Content-Security-Policy headers. In fact, these headers were so effective that it actually caused a false negative when I was testing for these vulnerabilities during the pre-1.0.0 code audit! From now on, I'll remember to turn these off when testing for XSS vulnerabilities.

How the Vulnerability Happened

Because I had hard-coded autoescape to true in our Twig_Environment, I had incorrectly assumed that everything would be escaped in the html context. It turns out, these __() calls were an exception to the rule.

Because author.name was never escaped, it was placed verbatim into the HTML, triggering the vulnerability.

What the Impact Could Be

If your target used a browser that doesn't support Content-Security-Policy headers, and they were tricked into accessing one of the vulnerable templates (i.e. they didn't notice the massive blob of HTML in the authors list before clicking the Edit or Users icons), you could potentially execute untrusted Javascript in their browser.

The cross-section of both circumstances is thin enough to consider an edge case, but don't rest on your laurels. Update immediately.

Lessons Learned

If you rely on autoescaping, make sure it's being applied everywhere. Where it's not applied, escape manually.

Be more skeptical of patterns intended to promote i18n.

Turn off Content-Security-Policy headers when testing locally so it's easier to catch these failures.

We're pretty confident that this entire avenue for exploitation has been thoroughlyexpunged from our codebase, along with other risk factors identified by Paragon Initiative Enterprises.