Demo - Session Fixation leading to Session Hijacking

[mips171]

What version of OpenCart are you reporting this for?
3.0.3.8 and 4.0.2.3 - I presume it is present in other versions as well.

Describe the bug
Unfortunately this has not been handled too well by the maintainer, so I'm making this post with demos to refute the claims by @danielkerr that 1) this is not a real issue 2) is a waste of time, and 3) that no one reporting this knows what they're talking about.

This issue is about the session fixation security vulnerability. In plain English, this means an attacker can set the OCSESSID cookie to a known value, then use social engineering or other means to get the user_token (stored in plain text in the URL bar) and with those two pieces, is able to log in to the account - no username or password required. Not to blow this out of proportion, in practice you will either need to be a malicious on-site user, or the victim will need to be targeted by a sophisticated threat. But considering that this vulnerability is public knowledge, there is a large number of OpenCart installations in production, and there are known recommendations for how to make this no longer possible, it should be handled.

To Reproduce
Steps to reproduce the behavior:
Follow along with my videos

Expected behavior
Because this is an e-commerce application, where compromised accounts lead to real financial losses, I would expect this to be taken seriously as a security concern and either

1. genuine effort made to patch it, instead of dismissal
2. @danielkerr to not shut down legitimate collaboration and discussion from other engineers who are working on patching his software

Screenshots / Screen recordings

1. Demo https://www.youtube.com/watch?v=jUQ9ugINXQc
2. Demo (set OCSESSID with JavaScript!) https://www.youtube.com/watch?v=K9XbwxAXnQs

Server / Test environment (please complete the following information):

• Deployed to web server (bitnami opencart docker)
• Operating system - debian 11
• PHP version 8.0.30
• Browser(s) tested with Chrome

Additional context
Add any other context about the problem here.
The problem has been known by @danielkerr since at least 2020.

1. OCSESSID can be controlled by attacker #12913
2. OCSESSID - Session Cookie Value can be modified and hacker can logged to anyone account  #11532
3. opencart 3.0.3.8 - Sessjion Injection #10280
4. Session handeling bugs v.3.0.3.1 #7857

Mentions
@digitalhuman
@ADDCreative
@nexadomain
@hubwoj12345
@mehov

How to fix

1. Make OCSESSID cookie header only
2. Change the session ID upon login or every request
3. Don't store user_token in the URL

[hubwoj12345]

I can mąkę resting pon., 13 lis 2023, 10:11 użytkownik Nick ***@***.***> napisał:

…

*What version of OpenCart are you reporting this for?* 3.0.3.8 and 4.0.2.3 - I presume it is present in other versions as well. *Describe the bug* Unfortunately this has not been handled too well by the maintainer, so I'm making this post with demos to refute the claims by @danielkerr <https://github.com/danielkerr> that 1) this is not a real issue 2) is a waste of time, and 3) that no one reporting this knows what they're talking about. This issue is about the session fixation security vulnerability. In plain English, this means an attacker can set the OCSESSID cookie to a known value, then use social engineering or other means to get the user_token (stored in plain text in the URL bar) and with those two pieces, is able to log in to the account - no username or password required. Not to blow this out of proportion, in practice you will either need to be a malicious on-site user, or the victim will need to be targeted by a sophisticated threat. But considering that this vulnerability is public knowledge, there is a large number of OpenCart installations in production, and there are known recommendations for how to make this no longer possible, it should be handled. *To Reproduce* Steps to reproduce the behavior: Follow along with my videos *Expected behavior* Because this is an e-commerce application, where compromised accounts lead to real financial losses, I would expect this to be taken seriously as a security concern and either 1. genuine effort made to patch it, instead of dismissal 2. @danielkerr <https://github.com/danielkerr> to not shut down legitimate collaboration and discussion from other engineers who are working on patching his software *Screenshots / Screen recordings* 1. Demo https://www.youtube.com/watch?v=jUQ9ugINXQc 2. Demo (set OCSESSID with JavaScript!) https://www.youtube.com/watch?v=K9XbwxAXnQs *Server / Test environment (please complete the following information):* - Deployed to web server (bitnami opencart docker) - Operating system - debian 11 - PHP version 8.0.30 - Browser(s) tested with Chrome *Additional context* Add any other context about the problem here. The problem has been known by @danielkerr <https://github.com/danielkerr> since at least 2020. 1. #12913 <#12913> 2. #11532 <#11532> 3. #10280 <#10280> 4. #7857 <#7857> *Mentions* @digitalhuman <https://github.com/digitalhuman> @ADDCreative <https://github.com/ADDCreative> @nexadomain <https://github.com/nexadomain> @hubwoj12345 <https://github.com/hubwoj12345> @mehov <https://github.com/mehov> — Reply to this email directly, view it on GitHub <#12939>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AWWX2TVWOS4FRUJA7YSMGILYEHP3FAVCNFSM6AAAAAA7I2C3SSVHI2DSMVQWIX3LMV43ASLTON2WKOZRHE4TAMRQGQYTANA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[danielkerr]

what a great hacker! this man should be put on a pedestal for as the worlds greatest hacker for using inspect element and copy and pasting his user_token var from the browser. now if he can only get it to work on a 3rd party who's cookie and user_token he wont know! lets not forget SSL.

fucking dickhead banned!