Is a web app vulnerable if it only uses session token in cookie to authenticate a user

Question

I am new to bug hunting and i came across this website, so i came across this bug or atleast what i think is a bug so help me understand and tell me if i should consider it a vulnerability.

1. The website i was testing was only using session tokens to authenticate a user, so my first question is, is it vulnerablity for a website to only check session tokens. I logged in on 2 accounts in 2 different browsers, attacker in firefox, victim in chrome, now from chrome i copied user's session token and in firfox i refreshed the url intercepted the request and replaced the session token of the attacker with victim, it logged me in victim's account could make changes in victim's account, now let me make this clear when i logout the session token expires so it was only working on active sessions, so is it a vulnerability to be able to login to someome's current active session with just a token, there were other tokens in the cookie but they were not doing anything, removing them made no difference. Now ignoring my rest of the points would you consider it a vulnerability on its own?

2. there was also no rate limit on how many times i could check session tokens, i checked 1000 wrong tokens and entered a right token at this the end and the response length changed so should i consider it a vulnerability that i could brute force live active sessions on a website

3. the length of the token was same, i tried it with different sessions, length was always same

4. Is it normal for a user to manipulate session token in requests is it a vulnerability? I mean is related to idor vulnerability in anyway?

There were also xss vulnerabilities that could allow me to get session token of the victim but i wanna ignore that part for now i want to understand a web application that gives access to anyone with valid session token no matter if they are on different devices with same token

Also if it is a vulnerability what would you call it?

I would also appreciate if you recommend a source to understand it better

Answer 1

A site using session tokens is not a vunerability as long as the tokens are long enough that they can never be realistically brute-forced or guessed. This means that the entropy should be at least around 64 bits, but preferably more.

Why is this not a vunerability? It can't be exploited. You can steal the session cookie if you have access to their PC, but you can also just steal their password or login from their PC. The session cookie doens't add any vulnerability.

 

There were also xss vulnerabilities that could allow me to get session token of the victim

Now, that is a vunerabilty.

 

i want to understand a web application that gives access to anyone with valid session token no matter if they are on different devices with same token

That's also not a bug or vunerability, but a feature. What if a user updates their browser during a session? Their user-agent would change, but you wouldn't want them to have to login again. You also should't bind sessions to IP-addresses as users can change IP at random, especially when not at home.

Answer 2

You are looking at the problem backwards. The XSS vulnerability IS the problem you have to go after. XSS is one of the most important problems on a web application, and dismissing it you are tossing the diamond out of the window and keeping the peebles.

The session cookie authentication is the default authentication for almost every site. Some will employ User-Agent and IP checks too, but few do that. But the session cookie is the default method used.

Why this is not a vulnerability? Because it is working as designed. Unless you can predict the token, you cannot access anything on the victim behalf. Rate-limiting or not will change nothing: a 64-bit token would take billions of years to be bruteforced, and bandwidth issues would stop you from trying millions of tokens per second.

Now, back to XSS.

What can you do if you can inject a script on the victim session? Lots of things!

• You can steal the cookies, including the session cookie
• You can change the cookies
• You can interact with the site on every way the victim can
• You can log every keystroke, every click
• You can change any information displayed on the site
• You can intercept every request, change downloaded files' URL

XS is the thing you are after. Logging in with a stolen session cookie does not even qualify as a vulnerability.