One Line of Code That Compromises Your Server
martinfowler.com
One Line of Code That Compromises Your Server
1–10 of 46 posts
Re: One Line of Code That Compromises Your Server
#2I think any sane framework should generate a random secret each time an app is generated.
Re: One Line of Code That Compromises Your Server
#3I think any sane framework should generate a random secret each time an app is generated.
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 that your PaaS or deployment system offers for this, and some (looking at you, Google App Engine Standard Environment) don't offer adequate ones.
Re: One Line of Code That Compromises Your Server
#4Good article and callout for those projects (and mine). I am doing an express alternative[1] with something that is not secure as a temporary session secret[2] formed with `secret: 'secret-' + parseInt(1000000 * Math.random())` so I'll modify it to use a real random key from a crypto library or display a prominent warning. Then I am also documenting it in a small production security guide [3]. Also, if the key in the documentation is used there's a warning[4] similar to how Dropbox stops you from using 'correct-horse-battery-stapler' as a password.
If you have any other tip/recommendation I'd be really thankful.
BTW, doesn't SSL/TLS mitigate this a lot? Like, if the user is using SSL then only with physical access to a decrypted device would an attacker be able to impersonate the user, limiting greatly the possible attacks. And if someone has access to your decrypted device then you have bigger problems. Though devs who don't change 'super secret' are probably probably less likely to set up https...
Edit: I almost didn't include the BTW comment because I agree that it is an important part of security, so I didn't want to make it sound less severe, but I am curious about attack possibilities with https enabled.
[2] https://github.com/franciscop/server/blob/master/src/config/...
[3] https://github.com/franciscop/server/issues/3
[4] https://github.com/franciscop/server/blob/master/src/config/...
Re: One Line of Code That Compromises Your Server
#5Good article and callout for those projects (and mine). I am doing an express alternative[1] with something that is not secure as a temporary session secret[2] formed with `secret: 'secret-' + parseInt(1000000 * Math.random())` so I'll modify it to use a real random key from a crypto library or display a prominent warning. Then I am also documenting it in a small production security guide [3]. Also, if the key in the…
SSL doesn't protect you from a malicious user who is trying to crack the key used on the cookie you gave him. It just means that no one else will eavesdrop on the malicious user's connection.
Re: One Line of Code That Compromises Your Server
#6I think any sane framework should generate a random secret each time an app is generated.
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?
Re: One Line of Code That Compromises Your Server
#7The equivalent of leaving the default password set. Coders are not immune.
Re: One Line of Code That Compromises Your Server
#8The equivalent of leaving the default password set. Coders are not immune.
Default passwords are a problem with the system being configured; not with the configuration. Insecure-by-default systems should not be deployed anywhere.
Re: One Line of Code That Compromises Your Server
#9Good article and callout for those projects (and mine). I am doing an express alternative[1] with something that is not secure as a temporary session secret[2] formed with `secret: 'secret-' + parseInt(1000000 * Math.random())` so I'll modify it to use a real random key from a crypto library or display a prominent warning. Then I am also documenting it in a small production security guide [3]. Also, if the key in the…
SSL doesn't protect you from a malicious user who is trying to crack the key used on the cookie you gave him. It just means that no one else will eavesdrop on the malicious user's connection.
But then it also means the malicious user cannot eavesdrop on other users, so other users will be secure, right?
Re: One Line of Code That Compromises Your Server
#10Earlier quoted context omitted.
SSL doesn't protect you from a malicious user who is trying to crack the key used on the cookie you gave him. It just means that no one else will eavesdrop on the malicious user's connection.
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).