

How to hack a Rails app using its secret_token - thibaut_barrere
http://robertheaton.com/2013/07/22/how-to-hack-a-rails-app-using-its-secret-token/

======
sehrope
This is in _almost_ the same category as checking in your SSH private keys. I
say _almost_ because at least this one is somewhat understandable. From the
perspective of of an app developer having everything in one place that you can
deploy makes things easy. Hence it's included by default. Otherwise people
would complain of losing the secret keys in between deploys (causing existing
sessions to invalidate)[1].

Course none of that makes it acceptable ( _it 's atrocious!_). This is a
perfect example of why code and config need to be kept separate[2]. If you
have that as a mantra from the beginning then you don't have issues like this.

[1]: In reality you _should_ change your secret token regularly. The best
approach is to accept a rolling window of old ones so you can age them out.
Then you can pick how far back you want to support (eg. how stale a client's
cookie can be).

[2]: [http://12factor.net/config](http://12factor.net/config)

------
gtani
discussed §2.5, and widely known

[http://guides.rubyonrails.org/security.html](http://guides.rubyonrails.org/security.html)

[edit] should be widely known. I would say it took me a couple hours to read
the majority of the security doc at a shallow level) and I wouldn't have known
about this unless i had just started upgrading a 2.3 app.

(tho i can't find a .gitignore for it

[https://github.com/fortuity/rails3-gitignore](https://github.com/fortuity/rails3-gitignore)

[https://github.com/github/gitignore/blob/master/Rails.gitign...](https://github.com/github/gitignore/blob/master/Rails.gitignore)

~~~
thibaut_barrere
As a freelance doing fireman maintenance on Rails apps from time to time, I
can tell that the word is not out enough, yet (far from it).

The guides do not underline that you can do RCE, either!

There is a metasploit module available now.

[https://twitter.com/unixmonkey/status/360859127620182017](https://twitter.com/unixmonkey/status/360859127620182017)

[https://github.com/joernchen/metasploit-
framework/blob/7f3ec...](https://github.com/joernchen/metasploit-
framework/blob/7f3eccd64453c3708ad4cb7ed7a6ea18354bac3d/modules/exploits/multi/http/rails_secret_deserialization.rb)

~~~
gtani
are you talking about RCE more current than

[http://blog.codeclimate.com/blog/2013/01/10/rails-remote-
cod...](http://blog.codeclimate.com/blog/2013/01/10/rails-remote-code-
execution-vulnerability-explained/)

[https://groups.google.com/forum/?fromgroups=#!topic/rubyonra...](https://groups.google.com/forum/?fromgroups=#!topic/rubyonrails-
security/61bkgvnSGTQ)

(patched in 3.2.11)

~~~
thibaut_barrere
see the commit message, it seems to work for Rails 3 and 4:

[https://github.com/joernchen/metasploit-
framework/commit/7f3...](https://github.com/joernchen/metasploit-
framework/commit/7f3eccd64453c3708ad4cb7ed7a6ea18354bac3d)

------
tucif
Taking a quick look on github, it seems most people are aware of this and have
implemented some mechanism to avoid it, being .gitignore or using an env
variable, and a SecureRandom or otherwise generated string for development.

[https://github.com/search?p=7&q=secret_token+extension%3Arb+...](https://github.com/search?p=7&q=secret_token+extension%3Arb+path%3A%2Fconfig%2Finitializers%2F&ref=searchresults&type=Code)

------
everettForth
Thank you for writing this post. I would love to see more "hacker" news of
this style.

------
kevinburke
I feel like this is knowledge that should be limited to people who can figure
out to do it. I'm not sure it's valuable to widely and easily disseminate this
information to the world.

~~~
thibaut_barrere
Anyone able to run metasploit (eg: any script kiddie) can figure out how to do
it right now.

------
Bootvis
Why is this information stored in a cookie the client has access to? Why
doesn't ROR have a shared secret so the information can be stored on the
server like, for example, PHP does?

~~~
sehrope
For stateless load balancing without a central server. By having the data in a
client cookie so that any web server can access it. Without it you need sticky
sessions on your load balancer or a central data store requiring additional
round trips for each request. A lot of frame works use the same principle (ex:
Django uses it too).

The data stored in the cookie is cryptographically signed with the secret
token so the server can verify if its been tampered with. It's a very solid
approach but like anything involving crypto it's important to keep the secrets
secret!

To clarify, the secret token should only be known to the server. The client
doesn't have it. The client only has their own signed cookie data.

~~~
stephenr
So you're telling me the official rails policy is: we think you (developers)
are smart enough to build an app that works on a distributed cluster but
aren't smart enough to work out how to use a central/replicated system for
session storage.

At the very least cookie storage should be an opt-in for apps that need it,
not a default with apparently not enough warnings about the security aspects

