Happy Birthday Armoredcode and 4 Rails Advisories

The goal, it’s useful to recall it, is to talk to developers about application
security. And this evening there are three new security advisories for
the Ruby on Rails MVC framework.

Is rails under attack?

Yesterday, @tenderlove reported 4 new security
advisories for Ruby on Rails. Two of them are
advisories about Cross site scripting vulnerabilities affecting sanitize
helpers, therefore it’s critical to upgrade to the latest rails version.

CVE-2013-1857
XSS Vulnerability in the sanitize helper of Ruby on Rails

Tenderlove also gave some monkey patch to apply in case you can’t patch your
rails installation.

@tenderlove monkey patch for CVE-2013-1855

123456789101112131415161718192021222324252627282930

moduleHTMLclassWhiteListSanitizer# Sanitizes a block of css code. Used by #sanitize when it comes across a style attributedefsanitize_css(style)# disallow urlsstyle=style.to_s.gsub(/url\s*\(\s*[^\s)]+?\s*\)\s*/,' ')# gauntletifstyle!~/\A([:,;#%.\sa-zA-Z0-9!]|\w-\w|\'[\s\w]+\'|\"[\s\w]+\"|\([\d,\s]+\))*\z/||style!~/\A(\s*[-\w]+\s*:\s*[^:;]*(;|$)\s*)*\z/return''endclean=[]style.scan(/([-\w]+)\s*:\s*([^:;]*)/)do|prop,val|ifallowed_css_properties.include?(prop.downcase)clean<<prop+': '+val+';'elsifshorthand_css_properties.include?(prop.split('-')[0].downcase)unlessval.split().any?do|keyword|!allowed_css_keywords.include?(keyword)&&keyword!~/\A(#[0-9a-f]+|rgb\(\d+%?,\d*%?,?\d*%?\)?|\d{0,2}\.?\d{0,2}(cm|em|ex|in|mm|pc|pt|px|%|,|\))?)\z/endclean<<prop+': '+val+';'endendendclean.join(' ')endendend

@tenderlove code to place into a file in config/initialized to fix CVE-2013-1857

True to be told, I see the high number of security issues for Rails as a
symptom that the framework is gaining in popularity.

The cross site scripting menace

It’s one of the widespread security vulnerabilities affecting web applications
nowadays. For the Owasp project is one of the most
prevalent security risks for enterprises, in the 2010 it was the second item in
their Top 10 and in the 2013 it’s going to be third in this security risks
standing.

It looses a place but it’s far from being mitigated.

The idea behind cross site scripting it’s easy. A web application is vulnerableif it takes an input (either from a web form or from HTTP request) and it usesit without proper validation or escape.

There are three different type of cross site scripting (aka XSS) attacks:

reflected

stored

DOM based

Reflected cross site scripting

A reflected cross site scripting occurs when a web application consumes a user
input using it in one of its pages. A common scenario is a search result page
when the search key is echoed to recall the user about his choice.

Following there is a Sinatra web application that takes
a parameter from the URL and it uses in the view to say hello to the user.
Of course this application is far from being something to be used in production
but it can be used to exploit a reflected XSS.

Stored cross site scripting

Stored cross site scriptings occur when a vulnerable web application stores
user input in a database or a file for a further usage.

In a past web application penetration test, with a source code review, I found
this:

a web application exposes a page for user feedback with a textarea html
element in it

web application saves users’ feedback in the database without filtering or
sanitize them

an internal web application read that database for datamining activities

It was possible to submit, as fake feedback, a cross site scripting pattern
attack that is eventually stored in the database. When the second web
application (that is not Internet exposed) reads that database trying to build
a table with users’ feedback, the pattern is used and the attack exploited.

That’s a stored cross site scripting in brief.

DOM Based cross site scripting

A DOM based xss attack occurs when the attack payload is executed by modifiying
the DOM document in the victim browser using an attack pattern executed client
side.

Richer user interfaces perform a lot of task client side, using parameters to
build forms or mask or populate values without passing such parameters to the
application server. This is done to save some traffic request and achieve
better performances.

If DOM is updated without filtering the values read by the user, then it’s
possible to inject arbitrary javascript code that it will be executed client
side. Bear in mind that since no code is passed to the server, it’s unlikely
that a web application firewall will save you from this kind of attack.

Let's talk about this

I'm an application security specialist and this my blog about software
development, testing and security stuff. Feel free to leave a comment
telling me if you liked this post or not. You can even follow @thesp0nge and @armoredcode on twitter.

If you liked this post, don't miss any armoredcode.com update. Subscribe
to rss feed or receive new posts directly into your
mailbox.
Service is courtesy by Google, I won't store your email address in
any case.