Content Security Policy for Rack

A long time ago I have implemented Content Security Policy as Rack middleware for my Ruby on Rails project. In short, CSP is a XSS mitigation mechanism. Server responds with HTTP header which defines trustworthy sources for different types of content (js, css, images) and browser restricts content from other sources. It's very powerful and you definitely should implement it along with other header-based security features (like X-Frame-Options, Origin, Strict-Transport-Security) especially as long as it won't take much time.

A couple of days ago I decided that it worths to publish middleware as a separate gem. I googled a bit and found csp_easy. However, it lacked few features (hash-based directives configuration, support to WebKit, Report-Only mode) and specs, so I decided not to fork and push my changes (I know it looks bad), but just to publish my own version.

Project is on Github. Read instructions and improve security of your Rack-based web application!

Exploiting IE MIME-sniffer vulnerability in Drupal

IE always loved to create vulnerabilities where they would never be. Not many people know, but there is an old bug in IE MIME-sniffer, which can be easily exploited. The essence of the bug is that when IE renders file, which was sent along with Content-type: text/plain header, it tries to identify its MIME type. So, if file contains HTML code inside, IE will think its text/html and render it. Simple example of exploit in Drupal:

1. There is a Drupal site with enabled Upload module.

2. Attacker uploads *.txt file with HTML code inside. By default Drupal allows *.txt files.

3. Attacker sends a link to that file to victim.

4. Victim opens it in IE and HTML code is rendered.

It's pretty bad that Drupal core, which is tough by default, can be exploited in such a simple manner. I understand that it's not Drupal issue, but Microsoft isn't going to fix it. Instead, they suggest to send X-Content-Type-Options: nosniff HTTP response header. But, it's not possible to do this in Drupal and Drupal Security Team didn't fix it for 2 years and won't do this in future. So, if you are aware of your users' safety, remove .txt from allowed tags. You can do this in Administer -> Site configuration -> File uploads.

Redmine UTF-7 XSS Vulnerability

I keep on looking through Redmine. And one of the most basic persistent XSS - problem of placing <title> prior to <meta> - still often ignored by developers. The same thing occurred in Drupal some time ago. Same thing is currently in Redmine.

The idea of this XSS vector is that tag <title> is placed before tag <meta>, which specifies character encoding of page. Good browsers look for <meta> upon page opening, ignoring its position, but Internet Explorer 6/7 (not quite sure about latest one), in case described above, uses <title> to define encoding. So if you create page (within Redmine, it will be "Issue") with title

+ADw-script+AD4-alert('XSS');+ADw-/script+AD4-

and open it in IE with Auto-Select Encoding on, browser will think that encoding of the page is UTF-7 and will interpret +ADw- as < and +AD4- as >. Thus arbitrary JavaScript will be executed, evading built-in filters .

P.S. Vendor was contacted and Eric Davis informed me, that this vulnerability will be fixed in new version along with CSRF, which wasn't fixed in 0.8.7.
P.P.S. Proof-of-Concept is here