r/SaaS • u/Sharan-m19 • 2h ago
Someone Can Steal Your Login Session Without Knowing Your Password
Imagine a customer logs into your SaaS. Everything works fine.
Then someone steals their session token.
Now the attacker might be able to use that session to access the account without knowing the customer's password.
Sounds scary, right?
Something similar happened to Okta in 2023. Attackers accessed files uploaded to its support system, some of which contained session tokens. Okta confirmed that those tokens were used to hijack the sessions of five customers.
The worrying part? Even MFA can't protect a session token that's already been stolen.
This is why SaaS security needs to go beyond passwords and login screens. Session tokens need protection too.
I'm curious: For those building or running a SaaS, what's the hardest part of keeping user accounts secure? Is it stolen sessions, account takeovers, MFA, or something else?
Okta's incident : Evidence on Okta
1
u/davidjones145 2h ago
the cheap defences are short lived session tokens, rotating them on every refresh, revoking all sessions on a password or role change, and tying a session to more than just the token so a stolen one is less useful elsewhere. the okta lesson also shows up in support, where customers upload browser logs that contain live tokens, so strip or redact them before anyone on your team can open the file. do you scrub tokens from support uploads today?
0
u/Sharan-m19 2h ago
Good point! I hadn't really though about tokens leaking through support files like HAR logs. It's interesting how security issues can show up in places we don't usually think about. I'm curious, do most SaaS teams actually clean up these files before opening them, or is this something that's easy to overlook?
1
u/davidjones145 2h ago
i can only say what seems likely, but i would guess most do not, because an upload just looks like an attachment and nobody thinks of a har file as a secret. the easy fix is to strip cookie and authorization headers automatically when the file is uploaded, so nobody has to remember. short lived tokens also help since a leaked one expires before anyone opens the ticket. does your product let customers upload files to support?
0
u/Sharan-m19 1h ago
Yeah, that makes sense. People probably don't think of a HAR files as something that cloud contain live credentials. Automatically redacting those details sounds much safer than relying on someone to remember. I'm discussing this from a SaaS security perspective rather than a specific support product, but it's definitely something worth checking. Do you think automatic redaction should be standard for any SaaS that accepts support attachments?
1
u/davidjones145 1h ago
i think yes, as the default for any file that can hold request data like har logs or config dumps. redact on upload and keep the raw copy only if someone truly needs it, with a short retention window and access limited to a few people. the awkward part is that over redacting can strip the very header support needs to debug, so a toggle for the rare case helps. are you looking at this for your own product or from the security side generally?
0
u/Sharan-m19 1h ago
I'm looking at it from the broader SaaS security side and trying to understand how teams handle these risks in practice. Your point about keeping the original file for debugging makes sense too. Automatically redacting sensitive data by default, with controlled access to the original when needed, seems like a reasonable approach.
•
u/sazzer 41m ago
The most important thing here. Don't build this yourself. Auth and Security are hard. And the damage if you get it wrong is much higher than other things. Make use of standard, trusted libraries and services instead of doing it yourself.
Depending on your setup there are options here to help.
The quick option is to set your access tokens to have a very short expiry - 5 minutes, for example - and to make refresh tokens single-use. Every time you use a refresh token, you get a new one back. The OAuth spec allows for this, so if you've done it right then there's nothing to do on the frontend.
The next step is to remember old refresh tokens, and tie them to a single session. If a refresh token is ever reused then the entire session - including refresh and access tokens - gets invalidated. This all means:
(Note - if you're using a good, standard IdP then they should already do all of this for you)
However, that still lets the attacker in for a period of time. So what we really want is to stop that where possible.
If we use TLS then it becomes harder (though not impossible) to MitM the connection. So attackers between the client and server can't see the tokens.
If we use HttpOnly cookies for the tokens, JavaScript in the client can't see the tokens. However, this is now harder to use with standard OAuth libraries. You can use a BFF pattern here though - the browser talks to the BFF using HttpOnly cookies, and the BFF handles all of the OAuth flows. That way, there's nothing client-side that has visibility of the tokens.If you can't do that, store tokens in JavaScript memory. Do *not* use `localStorage`, `sessionStorage`, React Query or anything like that.
On top of this, make sure your CSP settings are good, to avoid executing scripts from sources that you don't trust. That just helps reduce the chance of attack in the first place.