security considerations: email & pw auth about gae-init

[joernhees]

• might in general be a good idea to go through the OWASP Cheat Sheets

[mdxs]

Mark all handlers in app.yaml with secure: always to ensure that the users can only access the application over HTTPS. When developers turn that off... they are on their own. See https://cloud.google.com/appengine/docs/python/config/appconfig#Python_app_yaml_Secure_URLs

[mdxs]

Thatta way: no need for a https-only, HSTS or flask-sslify approach in my opinion (and experience); and we could enforce it in the default configuration, perhaps putting a warning in Docs for those developers that turn it off (though all web developers should know that HTTP based account/pw logins are evil ;-)

[joernhees]

the secure: always might be an option... in the section they even mention how to deal with versions... but it needs some considerations:

• thinking about this option made me realize that in order to do it right even static stuff (especially js) should be https (otherwise it can be used to inject js that for example makes a post go to http first). But then as we use scheme based URIs it shouldn't matter as soon as all HTML is served via HTTPS, as everything else is loaded from it (so while in theory one could directly load the static js via http the clients will never do, so the attack vector should be gone)
• external links to http://version.appname.appspot.com won't auto redirect to https://version-dot-appname.appspot.com it seems, so we would loose the ability to take care of that
• the http_headers directive doesn't seem to allow setting the HSTS headers for traffic that goes to a script. Effectively this means that if we want HSTS we would need decorators / flask-sslify anyhow.

The more i think about this, the more i like the flask-sslify approach, maybe a bit tweaked for the version https links and dev-server http only... that way everything would be served as https by default, making the whole thing pretty secure by default and we wouldn't need to modify / prefix anything with ssl_required decorators or anything...

So question: do we want https for everything or not?

[lipis]

While I understand all these issues the cleanest solution would be just update the app.yaml as @mdxs already mentioned when the app is ready and all the custom domains are SSL enabled.. so I'm not sure if I want to overcomplicate and add after all this logic for hybrid solutions..

P.S. Not discarded but dealing with other issues at the moment and don't want to rush with this one.. where were you when the email auth branch was still under dev :P I think the PhD is taking too much of your time :D

[joernhees]

well, two things that adding secure: always to all handlers in app.yaml can't do are:

• HSTS
• properly redirecting http://version.app.appspot.com to https://version-dot-app.appspot.com (this is probably not a big deal for new apps but e.g. for all the linked gae-init.appspot.com tests and docs it might get problematic)

still it's a rather small change and it would be pretty secure already...

[joernhees]

well, i invested quite some time in this already while there seems to be little agreement.

The current state is so damn insecure by default that it hurts.

So just add secure: always to all handlers in app.yaml and make it fast! Then it should be pretty secure by default.

HSTS would be nice, but can (and still should) be added later.

[lipis]

2df0f83 :D 👯 💃

for the docs and other gae-init examples I will not use the https for now and most likely disable the custom login at least :) These custom versions are a bit outdated.. but will come back to them..!!

[joernhees]

👍 thanks

[lipis]

🔒 👯 🔐