brunofacca / zen-rails-security-checklist

Checklist of security precautions for Ruby on Rails applications.
MIT License
1.81k stars 150 forks source link

Suggest two useful rack middlewares. #5

Closed tiegz closed 6 years ago

tiegz commented 7 years ago

This suggests using Rack::CanonicalHost and Rack::Attack.

brunofacca commented 7 years ago

Welcome, it's good to have new contributors :)

Rack::Attack is already mentioned in the 3rd item of the "HTTP & TLS" section:

Consider rate-limiting incoming HTTP requests, as implemented by the rack-attack and rack-throttle gems. Mitigates web scraping, HTTP floods, and other attacks.

About Rack::CanonicalHost, could you please provide an example of an attack involving unintended exposure of a Pow .xip.io domain? They are only accessible from within the LAN, right?

Thanks for your contribution.

tiegz commented 7 years ago

@brunofacca sorry, missed the rack-attack reference! Think it's worth linking still?

For Rack::CanonicalHost, let's say you run your app locally at foo.dev. As you mention, foo.1.1.1.1.xip.io is only available within the LAN (office, coffeeshop, etc), but if you're running an older Rails version that used Marshal for session cookies, and an attacker figured out your app secret, you'd be open to RCE (recent writeup here). Difficulty of the attack is fairly high, but impact is severe. Restricting access to a specific hostname(s) is an easy guard.

brunofacca commented 7 years ago

Thanks for the explanation and the link. That's an interesting attack.

I'm sorry, I'm not sure I get your point (yet). Given that multiple applications are running in vhosts at the development environment, your recommendation is to use Rack::CanonicalHost to restrict access to one or more specific applications (vhosts)? That way, other applications remain inaccessible (as their vhosts are redirected) and thus are not unintentionally exposed?

tiegz commented 7 years ago

One example is using Pow, which creates a local DNS resolver, setting up your app hostnames like foo.dev. IMO there's a false sense of security that clients on the network can't reach foo.dev, but not everyone knows about the xip.io domains. Using Rack::CanonicalHost lets you restrict access to only foo.dev (or anything else), and deny access to externally available hostnames like foo.1.1.1.1.xip.io.

brunofacca commented 7 years ago

I agree this is relevant.

However, I think we should make the checklist item a bit more clear/detailed, so people know exactly what we are talking about (took me a while to get it).

Maybe something like "If using Pow, consider using Rack:: CanonicalHost to prevent unintended exposure of Rails applications on specific vhosts by Pow's .xip.io domain (e.g. http://myapp.10.0.1.43.xip.io). Prevents unintended access by LAN clients to Rails applications in the development environment."

What do you think?

brunofacca commented 6 years ago

Closed due to inactivity.