A quick ruby DSL for creating L-Systems

L-Systems are pretty awesome. With only a bare few rules, you can turn something like this:

LSystem.new("Barnsley Fern") do
    start "+++X"

    rule "X", "F+[[X]-X]-F[-FX]+X" 
    rule "F", "FF"

    terminal "F" do forward end
    terminal "[" do push end
    terminal "]" do pop end
    terminal "-" do rotate -25 end
    terminal "+" do rotate +25 end
end

Into this:

read more...


A DSL for rendering magic circles and runes

Let’s make magic circles/runes!

Turn this:

rune do
    scale 0.9 do 
        circle
        polygon 7
        star 14, 3
        star 7, 2
        children 7, scale: 1/8r, offset: 1 do |i|
            circle
            invert do
                text (0x2641 + i).chr Encoding::UTF_8
            end
        end
    end
    scale 0.15 do
        translate x: -2 do circle; moon 0.45 end
        circle
        translate x: 2 do circle; moon 0.55 end
    end
end

Into this:

read more...


Directly monitoring Sidekiq in Redis

Another thing that came up recently: we have many (many) sidekiq queues. Each has their own admin interface, but sometimes you just want all of the information in one place. Of course, you could bookmark all of the pages. Or make a single page with a lot of frames (remember HTML frames?). Or use their API. But where’s the fun in that? Instead, let’s dig straight into the redis backend and see what we can see!

read more...


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=https://www.google.com. This goes to the server, which will then fetch https://www.google.com, 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=https://secret-internal-site.company.com. Normally, company.com 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: http://169.254.169.254/latest/meta-data/. 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!

read more...


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

read more...


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('http://www.example.com')
true

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

read more...


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)

read more...