One Line of Code That Compromises Your Server • Hacker News Board

Re: One Line of Code That Compromises Your Server

#11

Post by hansjorg » Sat, Apr 01, 2017, 9:14 PM UTC

robertlagrant wrote: post #6

ameliaquining wrote: post #3

Earlier quoted context omitted.

No; Django does that, and the result is that people check that random secret into source control. The correct solution is to not have the secret in code at all, but to read it at initialization time out of some kind of secrets management system (traditionally via environment variables). Unfortunately, frameworks generally can't do this in a hosting-setup-agnostic way; you have to understand the specific facilities th…

I THOUGHT Django generated a random secret! What's MF on about?

I think the purpose of that sidebar is to list the names of relevant configuration keys for some frameworks. Pretty confusing though.

Re: One Line of Code That Compromises Your Server

#12

Post by stestagg » Sat, Apr 01, 2017, 9:20 PM UTC

robertlagrant wrote: post #6

ameliaquining wrote: post #3

Earlier quoted context omitted.

No; Django does that, and the result is that people check that random secret into source control. The correct solution is to not have the secret in code at all, but to read it at initialization time out of some kind of secrets management system (traditionally via environment variables). Unfortunately, frameworks generally can't do this in a hosting-setup-agnostic way; you have to understand the specific facilities th…

I THOUGHT Django generated a random secret! What's MF on about?

I guess his point is that you /could/ set this to a weak key if you want, but I can't think why you ever would

Re: One Line of Code That Compromises Your Server

#13

Post by jacksingleton » Sat, Apr 01, 2017, 9:26 PM UTC

AgentME wrote: post #10

franciscop wrote: post #9

Earlier quoted context omitted.

But then it also means the malicious user cannot eavesdrop on other users, so other users will be secure, right?

The attack in the article isn't about a malicious user eavesdropping and obtaining someone else's cookie directly. It's about a user who gets a cookie from the server, brute-forces to determine the key used to sign the cookie, and then uses that key to generate cookies that authenticate them as other users (or that execute code during deserialization, etc).

@AgentME -- correct

@franciscop -- keep an eye out for the rest of the article (it's already written and will be released soon). I go over the impacts of an attacker knowing the secret in much more detail. I also have sections on prevention for both application developers and library/framework authors that I think you'll find interesting!

Re: One Line of Code That Compromises Your Server

#14

Post by parent5446 » Sat, Apr 01, 2017, 9:34 PM UTC

This is why I prefer not to pass session information to the client in the first place. Have the session key be just an opaque, cryptographically random token that is then associated with data on the server (via a keystore of some sort). Then the cookie becomes nothing more than a bearer token.

There are some use cases this does not cover, such as authentication across multiple systems, where one or more may not have access to the authentication source, but even in that case it'd be preferable to have a separate, internal, private microservice that exchanges tokens for session information.

None of this will stop an attacker that has network access, but that's not what the article is considering, and if somebody is inside your network you might have bigger problems than session hijacking.

Re: One Line of Code That Compromises Your Server

#15

Post by jacksingleton » Sat, Apr 01, 2017, 9:35 PM UTC

robertlagrant wrote: post #6

ameliaquining wrote: post #3

Earlier quoted context omitted.

No; Django does that, and the result is that people check that random secret into source control. The correct solution is to not have the secret in code at all, but to read it at initialization time out of some kind of secrets management system (traditionally via environment variables). Unfortunately, frameworks generally can't do this in a hosting-setup-agnostic way; you have to understand the specific facilities th…

I THOUGHT Django generated a random secret! What's MF on about?

ah I can see how that sidebar is confusing now. the point was just to highlight the configuration names across different frameworks. as @ameliaquining points out, a randomly generated secret that's been leaked to github has much the same effect as one that is easily guessed.

I'll think about ways to make it more clear! Thanks

Re: One Line of Code That Compromises Your Server

#16

Post by franciscop » Sat, Apr 01, 2017, 9:38 PM UTC

jacksingleton wrote: post #13

AgentME wrote: post #10

Earlier quoted context omitted.

The attack in the article isn't about a malicious user eavesdropping and obtaining someone else's cookie directly. It's about a user who gets a cookie from the server, brute-forces to determine the key used to sign the cookie, and then uses that key to generate cookies that authenticate them as other users (or that execute code during deserialization, etc).

@AgentME -- correct @franciscop -- keep an eye out for the rest of the article (it's already written and will be released soon). I go over the impacts of an attacker knowing the secret in much more detail. I also have sections on prevention for both application developers and library/framework authors that I think you'll find interesting!

I'll wait for it, because I don't fully understand @AgentME's comment "to generate cookies that authenticate them as other users". Those auth cookies would have a hashed token per user that must be created and validated in the back-end (besides the encryption). So just storing 'user-ID' should not be enough, you'd have to be able to decrypt a real user's cookie to know this token hash (and for this reason just guessing numbers/users ID would not be enough as well).

Re: One Line of Code That Compromises Your Server

#17

Post by bshimmin » Sat, Apr 01, 2017, 9:44 PM UTC

Jack Singleton is a developer and security specialist at ThoughtWorks.

What a splendid example of an aptronym! [0]

[0] https://en.wikipedia.org/wiki/Aptronym

Re: One Line of Code That Compromises Your Server

#18

Post by bitexploder » Sat, Apr 01, 2017, 9:55 PM UTC

While we are at it here is another individual line that will "compromise your server".

https://github.com/rack/rack/blob/master/lib/rack/session/co...

https://rdist.root.org/2009/05/28/timing-attack-in-google-ke...

Of course folks are much more likely to misuse their cookie secret than purposefully break a library function. That said you can look at the history of most projects that use HMAC to authenticate data and they did it wrong.

(e.g. https://github.com/rack/rack/commit/0cd7e9aa397f8ebb3b8481d6...)

Re: One Line of Code That Compromises Your Server

#19

Post by slrz » Sat, Apr 01, 2017, 10:05 PM UTC

kuon wrote: post #2

I think any sane framework should generate a random secret each time an app is generated.

Or, for simple cases where a single server handles all clients (i.e. no load-balanced cloud setup), just generate it on startup. A server restart will invalidate sessions, but oh well.

Re: One Line of Code That Compromises Your Server

#20

Post by cyberferret » Sat, Apr 01, 2017, 10:30 PM UTC

I write most of my web apps using Sinatra (as per the article example), but do it using the Padrino [1] framework. Padrino by default sets the Sinatra session secrets to a long hash, which negates the developer from having to remember to do all this housekeeping later to tighten security on the app.

[1] - https://www.padrinorb.com