(Is the explanation under "Attacker uses the app" your own understanding or something you found on the Internet? If the latter, the author didn't actually fully understand the attack or failed to explain it correctly.)
The vulnerability is actually very simple: the server/app uses sessions to store the authentication state, and which session is used can be controlled by a third party (e.g. via URL).
The attacker doesn't have to log in/out or even have an account. All s/he needs is the ability to obtain a session id.
Example attack:
- Hacker opens the vulnerable website and gets a fresh session id (123 in this example)
- Hacker tricks the victim to log in with a URL containing the session id, e.g.
poor-site.com/password-protected-page-the-victim-wants-too-see?session=123
- Hacker can now access any other contents as the victim using
poor-site.com/another-page?session=123
This attack is popular because many frameworks with backwards-compatibility baggage allow session info to be carried via URL as some (old) browsers don't handle cookies (or have them turned off).
If session ids can only be supplied via cookies, then this vulnerability becomes much harder to exploit (CSRF required).
If you still don't get it, think of this analogy:
There's a row of high-tech lockers [=sessions] in a public venue. The attacker walks up to one and the locker prints a ticket with the unlock barcode [=session id]. The attacker takes a photo of the code and leaves the door open. The victim then approaches, not knowing the technical details of the system [session id in URL], simply takes the pre-existing ticket, put his things in and closed the door [=logging in using a pre-planted session]. The attacker then opens the locker with the photo of the code.
One mitigation is to print the unlock ticket after the door is closed [= generate new session ID during log in].