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

Content Security Policy halts XSS in its tracks

Cross-site scripting (XSS) is one of the biggest problems faced by webmasters. Even banks and payment service providers like PayPal appear unable to prevent XSS from being used to inject external code. The new Content Security Policy standard should finally relieve the problem.

Content Security Policy halts XSS in its tracks

Modern web applications accept all sorts of user input. An obvious example is a search function for searching through goods available in an online store. Servers frequently return the input value as part of the search results: "Your search for search termreturned 7 hits". If a web developer has failed to exercise sufficient care, cyber-criminals can exploit this to inject code into a web page, with a search term such as<script>alert("Pwned!")</script> being interpreted by the browser as JavaScript and executed in the context of the web site on which it is displayed. It therefore follows that unforeseen user input needs to be filtered.

Content Security Policy halts XSS in its tracks | 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

Multiple XSS in Apache modules

Apache HTTP Server

Cross-site scripting (XSS) flaws were found in the mod_proxy_balancer module's manager web interface. If a remote attacker could trick a user, who was logged into the manager web interface, into visiting a specially-crafted URL, it would lead to arbitrary web script execution in the context of the user's manager interface session. (CVE-2012-4558)

Continue to the article »