Did you know that you can navigate the posts by swiping left and right?

Prevent information leaking in Rails

28 Oct 2015 . category: rails . Comments
#rails #information leaking #ruby on rails #caching

By default Rails sets the `Cache-Control` HTTP Header to `max-age=0, private, must-revalidate`, which means the browser needs to revalidate the page on each request, BUT the browser still stores the cached version of the page. The problem with this, if a user clicks the back button of the browser, it won't revalidate the page, it will just simply load the page from it's cache. This can lead to serious information leaking, if you a user logs out from an application and someone else sits to that computer and navigates back in history. A more advanced attacker can even decrypt the browser's cache files and access sensitive information.

To address this issue, you can explicitly set the `Cache-Control` header in your app with a before filter:

  before_filter :set_as_private

  protected

  def set_as_private
    response.headers['Cache-Control'] = 'no-cache, no-store'
  end

You can call this filter in each controller where you display sensitive information(usually every controller behind authentication). Alternatively, you can ask you users at sign in, whether they are on a public or private computer and set the cache header based on their choice.

Do you want to shape up your Rails security skills?

Although Rails is quite secure by default, you can still easily shoot yourself in the leg, make silly mistakes and get hacked. I am working on a course, in which I will show you how an attacker would try to hack a Rails application and the best techniques to prevent it.