SSRF Protection in Rails

One of the more subtle bugs that a lot of companies miss is Server Side Request Forgery (SSRF). Like it’s cousin CSRF (cross-site request forgery), SSRF involves carefully crafting a request that runs in a way that the original developers didn’t expect to do things that shouldn’t be done. In the case of CSRF, one site is making a request on behalf of another in a user’s browser (cross-site), but in SSRF, a request is being made by a server on behalf of a client, but you can trick it into making a request that wasn’t intended.

For a perhaps more obvious example, consider a website with a service that will render webpages as preview images–consider sharing links on a social network. A user makes a request such as /render?url= This goes to the server, which will then fetch, render the page to a screenshot, and then return that as a thumbnail.

This seems like rather useful functionality, but what if instead, the user gives the url: /render?url= Normally, would be an internal only domain that cannot be viewed by users, but in this case–the server is within the corporate network. Off the server goes, helpfully taking and returning a screenshot. Another option–if you’re hosted on AWS–is the AWS metadata endpoint: All sorts of interesting private things there. Or even more insidious, /render?url=file:///etc/password. That shouldn’t work in most cases, since most libraries know better than to rener file:// protocol URLs, but… not always!


Rack::Cors Configuration Tricks

cyu’s Rack::Cors middleware is rather handy if want to control your CORS (Cross-Origin Resource Sharing) settings in a Ruby-on-Rails project. Previously, there was a fairly major issue where :credentials => true was the default (which you generally do not want), but there were also some more complicated tweaks that I wanted to make.

One problem I recently had to deal with was wanting to:

  • Allow CORS connections from arbitrary domains (this site functions as an API)
  • Do not allow CORS from http domains at all
  • Only allow cookies (Access-Control-Allow-Credentials) to be sent for sibling subdomains
  • Prevent cookies from being sent from specific sibling subdomains (that are actually run by a third party)
  • On development (non-production) versions of the site, allow credentials from localhost


Prevent JavaScript links by parsing URLs

If you have a website that allows users to submit URLs, one of the (many many) things people will try to do to break your site is to submit URLs that use the javascript: protocol (rather than the more expected http: or https:). This is almost never something that you want, since it allows users to submit essentially arbitrary code that other users will run on click in the context of your domain (same origin policy).

So how do you fix it?

First thought would be to try to check the protocol:

> safe_url = (url) => !url.match(/^javascript:/)
[Function: safe_url]

> safe_url('')

> safe_url('javascript:alert(1)')


Forcing Secure Cookies Behind an ELB in Ruby/Rails

As part of general security good practices, you should always (whenever possible):

  • use HTTPS to serve all requests
  • serve redirects to upgrade HTTP requests to HTTPS
  • set session cookies to secure and http_only
  • enable HTTP Strict Transport Security (HSTS)


A Quick Look at RC4

In cryptography work, RC4 (Rivest Cipher 4) is well known as both one of the easiest to implement and fastest to run symmetric encryption algorithms. Unfortunately, over time there have been a number of attacks on RC4, both in poorly written protocols (such as in the case of WEP) or statistical attacks against the protocol itself.

Still, for how well it formed, it’s an amazingly simple algorithm, so I decided to try my hand at implementing it.