0

Basically, I have two questions

A. Is session hijacking possible with the same system but two new instances of the browsers (eg. 1.New Window and 2.Incognito)?

If Yes, then how could I prevent session hijacking in this scenario?

What I have tried is to log in with User X and took post-login ASP.NET_SessionId cookie value. Now in Incognito, log in with User Y and after successfully logged in modify the cookie value of User Y's ASP.NET_SessionId with User X's ASP.NET_SessionId and refreshed. Then I have received the entire session of User X.

B. How could I prevent session hijacking with two different systems?

I am using ASP.NET MVC5, Form Authentication,.NET 4.5.2, and InProc session state.

Thanks in advance.

Vaibhav Deshmukh
  • 183
  • 1
  • 11
  • 2
    If you can get hold of the session information used to authenticate/identify you with the remote system, you can clone the session, doesn't matter if you clone it into a new window, another browser, or even a browser on a completely different system. There is no way to prevent this from happening. The security is in preventing unauthorized access to this type of information, but you can't prevent **the user themselves** from doing this "hijacking". – Lasse V. Karlsen May 18 '21 at 14:32
  • So instead of trying to prevent cloning of the session if you know this information, figure out how you obtained the information in the first place and then figure out if you really need to do anything at all. – Lasse V. Karlsen May 18 '21 at 14:34
  • 1
    If the attacker can read the cookies/local storage of the user browser, the server can do nothing to prevent that. The only reasonable response is to allow access as that user. At some point, some protection of secrets rely on the final user not exposing his cookies himself. – Alejandro May 18 '21 at 14:36
  • @Alejandro To maintain and validate the session I am using cookies and how could this possible is to use cookies and not to store them on local storage? This anyhow exposed those cookies. Though I am applying HttpOnly and Secure attributes on cookies still hijacking could be possible. As this issue raised by our Info Security team. – Vaibhav Deshmukh May 18 '21 at 14:45
  • 2
    @VaibhavDeshmukh Exactly, you **must** store them in the browser in some way, and if they're stolen, that user account will be breached. No matter what you do at the server side, you **can't** completely prevent this. What's the issue raised, exactly? – Alejandro May 18 '21 at 14:57
  • At most, you can time-limit sessions so an eventual cookie steal has a small window of vulnerability. But even then, it's up to the user (not the website) to ensure that their session identifiers are keep secret. – Alejandro May 18 '21 at 14:58
  • 1
    @Alejandro This issue has raised: If the session ID is not validated on the server-side then the attacker having physical access to the victim's machine can again use the previous session ID and can gain access to the victim's session. – Vaibhav Deshmukh May 19 '21 at 05:04
  • 1
    @VaibhavDeshmukh Physical attacks on the workstations can't be prevented by server-side logic, nor any validation can detect a *stolen* cookie. At most, you can time-limit lifetime of session cookies or invalidate them after logout or some other condition, so you reject those. But for still valid cookies copied from other valid sessions in progress, you can't do anything about those. It's up to your users to protect their own secrets. – Alejandro May 19 '21 at 13:39
  • @LasseV.Karlsen Thank you! I have discussed this with the information security team and the point you mentioned: "If the attacker can read the cookies/local storage......" is totally valid. – Vaibhav Deshmukh May 26 '21 at 05:55
  • @Alejandro Thank you! I have discussed this with the information security team and the point you mentioned: "Physical attacks on the workstations can't be prevented by server-side logic......" is totally valid. – Vaibhav Deshmukh May 26 '21 at 05:56

0 Answers0