XSS Defense in Depth (with Rack/Rails demo)

Quick introduction to the XSS problem

XSS problem

XSS is not only about scripts. Overall it happens when attacker can break the expected DOM structure with new attributes/nodes.

For example is a script-less XSS (in Rails jquery_ujs will turn the click into DELETE request).

<a data-remote=true data-method=delete href=/delete_account>CLICK</a> 

It can happen either on page load (normal XSS) or in run time (DOM XSS). When payload was successfully injected there is no safe place from it on the whole origin. Any CSRF token is readable, any page content is accessible on site.com/*.

XSS is often found on static pages, in *.swf files, *.pdf Adobe bugs and so on. It happens, and there is no guaranty you won't have it ever.

You can reduce the damage
Assuming there is GET+POST /update_password endpoint, wouldn't it look like a good idea to deny all requests to POST /update_password from pages different from GET /update_password ?

Ruby on Rails

XSS defense in depth | Egor Homakov

Ruby update fixes SSL man-in-the-middle vulnerability

The OpenSSL implementation bundled with Ruby has been found to be vulnerable to having its hostname check bypassed. 

Ruby update fixes SSL vulnerability

The flaw, rooted in the lack of proper handling of alternate X509 names with null bytes in them, could allow an attacker to present a certificate for "www.ruby-lang.org\0example.com" which when read by the Ruby client library, would be interpreted as "www.ruby-lang.org". That result would be handed over to the certificate verfication routines which would cause the certificate would be identified as coming from "www.ruby-lang.org". If an attacker could get a certificate where thesubjectAltName included such a null byte, they could use that certificate to interpose themselves between a victim and the site.

Ruby update fixes SSL man-in-the-middle vulnerability | The H Security

Coinbase – Owning a Bitcoin Exchange Bug Bounty Program

When I first started analyzing the Coinbase website I had a quick look over the site layout and the functionality/attack surface available for potential exploitation. I quickly determined it was running Ruby on Rails based on the encoding of the “_coinbase_session” cookie. This was supported by the fact Coinbase’s founder Brian Armstrong had a lot of Ruby snippets on his Github Gist and some more Ruby questions on his Stack Overflow account.

Reflected XSS vulnerability on Coinbase

I had a lot of fun in the few hours I spent looking at Coinbase while procrastinating from exam study. They have done a lot of things right in regards to CSP, HttpOnly session cookies and two-step authentication but are let down with the integration of third party components such as Doorkeeper and ZeroClipboard. It is difficult to get any reasonably complex site completely secure and even sites doing more than $15 million USD per month in Bitcoin transaction volume can have a number of critical issues which a blackbox attacker could discover. I would recommend for all web developers to check out the guides on the OWASP website which cover all the key areas where security problems can occur in web apps.

The article will cover following vulnerabilities: 

• Reflected XSS
• Persistent XSS on Merchant Checkout Pages
• Insecure OAuth Application Approval
• Insecure OAuth Redirect URI in the Coinbase Mobile App

Full article | Donncha O'Cearbhaill

Critical Ruby on Rails bug exploited in wild, hacked servers join botnet

Attackers are exploiting an extremely critical vulnerability in the Ruby on Rails framework to commandeer servers and make them part of a malicious network of hacked machines, a security researcher said.

Source