0

I am creating a small login system. It looks like the standard username/pwd and user can either log or register.

If they pass (authenticate), I create a session cookie that will be sent with the header every time, so that the user is not logging in every-time.

But I am pondering this scenario. The cookie is sent in the header, so it is visible for eaves droppers.

  • Would they be able to send a request to the site setting a header.session.id cookie ?

In this silly case any hacker could hijack someone else's session by sniffing request headers in a net.

You can not do this in the browser URL-bar but on the console using fetch, or NodeJS request or lwp-request, python requests etc.

Improve this question

1 Answer 1

Reset to default
2

The cookie is sent in the header, so it is visible for eaves droppers.

It is not visible for eavesdroppers on the network if the connection is encrypted, i.e. HTTPS is used. With HTTPS not only the request body is encrypted but also the request header.

... but on the console using fetch ...

Access to the browser console requires access to the computer, i.e. the attacker already needs to have compromised the system.

... , or NodeJS request or lwp-request, python requests etc. ...

Using a HTTP client written in such languages does not provide access to the existing session cookie the user has inside the browser. Assuming properly designed session cookies, it is possible to programmatically login using the correct credentials and getting a new session cookie, specific for this newly logged in session. Of course knowing the correct credentials requires that the attacker already has compromised the account.

Improve this answer
8
  • thank you, i always forget what is not encrypted in https. I know that IPs source and dest are not, and some other details...sorry that i can not upvote score less than 15. will likely accept if no better answer is given.
    – Mah Neh
    Commented May 8, 2022 at 9:54
  • Wouldn't it be easy though, to try a couple of millions session ids (with the software I mentioned) and get information from users? Seems extremely possible to me given the long expiration dates + number of users of some apps...
    – Mah Neh
    Commented May 8, 2022 at 10:03
  • @MahNeh: Assuming proper session cookies which contain sufficient randomness such a brute force is not feasible. Even when assuming that one could try 100.000 session ids in a second (probably unrealistic) it would take many years to brute force even 6 bytes (48 bit - not the same as 8 alphanumeric characters!) of randomness.
    – Steffen Ullrich
    Commented May 8, 2022 at 10:16
  • 1
    @MahNeh if an attacker can do that, your session tokens are waaaaaaaaay too weak. Suppose you're using a 128-bit (entropy, not necessarily length) token, a common strength. Further suppose that not just one person, but every user, is attacking it (birthday attack). "A couple millions" is 2^21. You'd need roughly 2^53 users - about 8 quadrillion, or roughly a million times as many people as exist on the planet - all attacking each other millions of times - before, statistically, one would ever find another's session. But if that's too risky, you can use 256 bits of entropy instead.
    – CBHacking
    Commented May 8, 2022 at 10:18
  • Ok once it is done i would be glad to see if either of you can crack it. It's an extremely small app to chat with friends (i am not a programmer). @CBHacking
    – Mah Neh
    Commented May 8, 2022 at 10:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .