Hacker News Reader

Comment by junto | Hacker News Reader

> On May 2nd, 2023, we identified that the Flask session secret for the points.com global administration website used to manage all airline tenant and customer accounts was the word "secret". After discovering this vulnerability, we were able to resign our session cookies with full super administrator permissions.

Seriously?

View on HN

This is way more common than you'd like, here's a scenario where it can happen even without outright incompetence:

Someone (or some AI) copies an example auth implementation from stackoverflow. Being sensible they realise they shouldn't put key material in source code either, so they leave "secret" in place, and pop a ticket in JIRA to update with the key material from the vault before it goes live.

Employee falls ill, everything gets re-assigned. Leaves before it gets actioned and that ticket slips through the cracks, with the person taking over their duties not realising how serious "J10243: Populate secret from key vault" actually is, perhaps assuming it's currently coming from a different configuration location.

There's little chance that the regular testing are discovering the flaw as the key gen based on "secret" goes live.

Then imagine how often this happens without the "sensible employee" and "pop a ticket in JIRA" parts.

Tragedy of the Commons often happens where there are too many developers and unclear functional or concerns ownership. Each concern needs a home, a checklist, a runbook, documentation, a support escalation path, and responsible tech or business owners.

You are redefining "tragedy of the commons" there... TOTC is about overusing shared resources (e.g. too many people helping themselves to a shared plate of food), not about confusing who should do what.

Responsibility is the "resource" that becomes diminished. What would you rather call it then? The bystander effect at organizational scale?

You should actually read Garrett Hardin's influential essay you are referencing before referencing it again. It's freely available from his estate at https://www.garretthardinsociety.org/articles/art_tragedy_of...

Because it doesn't say what you seem to think it does.

When I was in my greyhat days I gained admin access[0] to a very big IIS web hosting provider. After spending a day trawling through their file system I found the actual admin password for their servers in a file. I tested it via their open RDP port. It worked.

Their password? "internet"

I sent them an email showing them their vulns. I never followed up to see if they did anything about it.

[0] they had a forum that allowed profile pic uploads but it didn't check they were images, so I crafted an ASP page which emulated a file explorer and uploaded that, then browsed to it.

Also why would anyone store and read data like { 'groups': [...] } on the client-side? Session cookies are supposed to be identifiers only, with the data stored server-side.

By default sessions in Flask are stored in plaintext:

> This is implemented on top of cookies for you and signs the cookies cryptographically. What this means is that the user could look at the contents of your cookie but not modify it, unless they know the secret key used for signing.

That's precisely why the cookie should just be an identifier, that you look up group info from the database. Because you can guarantee the cookie contents will be modified by someone at some point. Make it useful to you, useless to them.

By default flask doesnt have a db. There is flask-sessions extensiom that does this for you.

Or you can just link to a DB directly. A Flask app is just a WSGI app. You can mount and extend it with any kind of Python, no extension necessary.

That's what the extension does for you.

Can't session data be stored on disk? that's the default PHP behavior.

Because you might have multiple webservers.

There are solutions for that: Shared NAS, sticky sessions etc.

Good luck with maintaining that NAS. Your sticky sessions will logout all users on a server that goes down. It's better to have a db.

Please stop.

Of course it's better to have a db doh... I'm replying to your

> By default flask doesnt have a db.

People don't have NAS laying around. And don't use a filesystem as a db, especially a remote filesystem.

The cookie contents can be changed only if you know the secret config.

Or if you can bruteforce the secret, or if there's a vulnerability in the secret, or if... You're relying on the fact that the cryptography will be impregnable, rather than adopting an actual security posture.

Do not trust the data you send to a user, to remain secure.

And you're relying on security through obscurity.

No. It's relying on both cryptography, and the inaccessiblity of information. Which is a tried, practiced, and often federally mandated, method of security. Controlling who has access to information is sorta security 101. Don't dump your database to the Internet.

Security through obscurity is allowing REST commands to the /totallysecretaddress/neverleaked/ URI.

Makes you wonder if there a colleague who wanted to use Django with the biggest "I told you so" grin right now

For anyone unfamiliar with Django:

> django-admin startproject automatically adds a randomly-generated SECRET_KEY to each new project

https://docs.djangoproject.com/en/dev/ref/settings/#secret-k...

And stores session data in the DB by default

Reply on news.ycombinator.com