<img height="1" width="1" style="display:none;" alt="" src="https://analytics.twitter.com/i/adsct?txn_id=nv7vl&amp;p_id=Twitter&amp;tw_sale_amount=0&amp;tw_order_quantity=0"> <img height="1" width="1" style="display:none;" alt="" src="//t.co/i/adsct?txn_id=nv7vl&amp;p_id=Twitter&amp;tw_sale_amount=0&amp;tw_order_quantity=0">

Will it Pwn? CVE-2016-6316

Ajin Abraham on Sep 01, 2016

cvebanner.gifRails is again affected by a major CVE, a potential cross-site scripting vulnerability (XSS) arising from a flaw in Rails’ ActionView component. The ID of the newly-identified CVE is CVE-2016-6316.

This vulnerability is part of the Rails framework itself. It affects certain versions of Rails (see the RubySec advisory for details) so that any website running the flawed code on these vulnerable versions is potentially at risk of exploitation via XSS.

The important thing to remember if you’re using the affected versions of Rails is that the quality of the code your developers write is irrelevant to your level of risk. In many cases, XSS vulnerabilities arise from sloppy coding, but that’s not the case here.

The Exploit Explained

This particular vulnerability occurs due to the absence of Context Specific escaping with respect to attribute context. For those who are not familiar with attribute context, the following is an example:

<p id=”UNTRUSTED_USER_INPUT”>Content Goes here </p>

In the attribute context, Rails fails to escape the user input properly. Text that is marked as HTML Safe doesn't get correctly double quote escaped, and is therefore vulnerable to XSS. (For a full breakdown of the vulnerability, how it can be exploited, and how it can be blocked in real time, check out our video.)


The vulnerable code is as follows:

<%= content_tag(:div, "Hello", title: @user_input.html_safe) %>

Many helper functions like sanitize() are also vulnerable in the attribute context.
For example:

<%= content_tag(:div, "Hello", title: sanitize(@user_input)) %>

If the user input is XYZ, it will be rendered as

<div title="XYZ">Hello</div>

Now if a malicious user sends the input as: “ onmouseover=alert(1)" style="width: 100%; height: 100%; position: absolute; top: 0; left: 0;

It will be rendered as:

<div title="“ onmouseover=alert(1)" style="width: 100%; height: 100%; position: absolute; top: 0; left: 0;">Hello</div>

A mouse movement on the screen will trigger the alert box.

Why RASP is the Best Solution for Rails Security

Agile developers using Ruby on Rails and other dynamic platforms need effective web app security solutions that block common threats without slowing down release cycles. As of 2016, a total of 78 CVEs have been identified and fixed across all versions of Rails (since the first version of Rails appeared in 2005). Seventy percent of these CVEs fall into three categories—cross-site scripting (XSS), remote code execution, and SQL injection (for common functions at risk see: http://rails-sqli.org/). And these are only the ones officially reported by MITRE, the organization that tracks CVEs.

Up until recently, the preferred solution for addressing vulns like the one we discuss here has been to upgrade the framework in your applications every time there is a new security release. But for many organizations, it’s just not practical to spend weeks or months upgrading web applications every time there is a security upgrade. The next generation of protection—Runtime Application Self-Protection (RASP)—plugs the holes those security procedures leave in your web applications.

RASP shifts the focus from finding all vulnerabilities, and remediating fast, to reducing the risk of a breach by blocking the exploitation.

The value of RASP is that this new class of technology is preventative. It does not just identify vulnerabilities in the application; it knows how the application works when it is dealing with acceptable traffic patterns. So it can easily identify attacks and unacceptable traffic without having to understand the exact nature of the threat.

We explain exactly how the IMMUNIO RASP solution blocks CVE-2016-6316 in real time in our video. Also, to learn how our solution would address another nasty Rails vulnerability, a directory traversal vulnerability, CVE-2014-0130, take a look at our earlier blog post.