If a hacker is able to exfiltrate log files, what's to prevent them from exfiltrating other things? If they get into a server, they could as well dump sensitive data form the database or do something to gain persistence, like installing a shell or adding their SSH key. If they get into a client device, they could steal more, more valuable data than just some logs — browser cookies, email credentials, app tokens, owner's personal information, all that stuff.
Have to disagree. Lots of times it is only opportunity to get logs from some misconfigured instance of elastic or some other log aggregation system or read only somewhere on web server. Without possibility to own the whole system.
In what kind of situation would logs be the only thing a malicious actor could access? If they exploited the application that writes them, then they have as much access as the application has — and if its job includes creating access tokens, it definitely has access to the database that stores user accounts.
Any one of a million web apps/frameworks have had file traversal bugs where you could read /var/log/rails.log but not /var/db/secrets.db. In many cases you also get app.env or whatever, and it's game over anyway, but it's not automatic. Or the logs land in an unsecured S3 bucket.
Happens all the time, where access is through a low privilege user, or the nature of the infiltration isn't just a user but through some specific tool that only itself has access to specific things. Maybe the hack gets you into Splunk and that's it, and only for a few hours because the session you hijacked expires...
Nobody exposes access tokens on purpose, there is no "its job includes creating access tokens". No system's job results in this happening as part of normal operation.
Also 100% wrong re: "it definitely has access to the database that stores user accounts". That statement makes me think you have no clue what you're talking about; you don't need access to users at all to validate a session token. In a JWT, the token is signed and you validate the signature with a cert, and that cert is public knowledge.
I've written auth services that have zero access to password data, which validate session tokens.
> In a JWT, the token is signed and you validate the signature with a cert, and that cert is public knowledge.
JWT is a particular type of token. Not everyone uses JWTs because they have drawbacks — in particular, a self-contained signed token can't be revoked without maintaining some sort of blacklist of invalidated tokens. So you have to resort to expiration to make up for that I guess?
In my own backend projects I use session IDs that are simply long random strings that are stored in the database. I delete the row when the user logs out of their session.
A hacker would start salivating if they heard someone who built a product storing PII said what you just did about session tokens for your personal projects.
By the way, social media services like Facebook do store PII and have non-expiring sessions. And somehow, if someone's account is hacked, it's that person's problem, not Facebook's.
