Improper Session Management

Attack scenario

I have not tried this scenario and do not confirm if it’s realizable. However it seems to work in theory.

1. An attacker provides fake wi-fi access point and a machine that hosts fake web server.
2. The wi-fi AP DHCP server is configured as the “default gateway” to the fake web server machine. Thus all packets go to the computer. This machine works as proxy.
3. Configure route table of this machine as to reroute request packets for the target site port 80 to the local fake web server.
4. The attacker provides trap page that contains image tag whose src value is http://target-site/beacon.gif.
5. When a victim opens the trap page, an HTTP request for the beacon.gif is made to http://target-site but it will be handled by the fake web server.
6. The fake web server makes a request to the real target site and fetch session ID, then respond to the victim’s request with the fetched session ID.
7. Finally the session ID for the target site that went through the attacker’ fake web server is set on the victime’s web client.
8. Then the victim makes the request to the target site over HTTPS, the web client will send the session ID that is set by the attacker. Since the session ID was generated by the real site, the target site accepts it.
9. The victim login to the target site. Since the attacker knows the session ID, attacker also can browse the site under the victim’s access privilege.

Provision

• Generate another session ID after login and use it for managing anthentication
• Use SSL/TLS connection and gives “secure” option to the session ID cookie.

Discussion

This issue occurs because the unsafe session ID is tied to the authenticated user session. To prevent this, generate another session ID after login is established and use it for evaluating user authentication. Since the attacker does not know the newly generated session ID, the attack will not take effect.

Of course the newly generated session ID must be sent to the user’s web client under SSL/TLS connection, and also set the secure flag to prevent from sniffing.

// after a user is autheticated
$sessionId_t:=Generate UUID
WEB SET HTTP HEADER("Set-Cookie: CookieName="+$sessionId_t+"; Secure; HttpOnly; SameSite=Lax")

$auth_o:=New object
$auth_o.sessionId:=$sessionId_t
$auth_o.user:=$userEntity_o // authenticated user entity
Use(Session.storage.auth) // assumes Session.storage.auth shared object exists
    Session.storage.auth:=OB Copy($auth_o; ck shared; Session.storage.auth)
End use

when the next request comes, extract the cookie value whose name is CookieName, then compare it with the value of Session.storage.auth.sessionId using exact match.

$authenticated_b:=(Compare strings(Session.storage.auth.sessionId; $cookieValue_t; sk char codes)=0)

References

• Cookie Manipulation Is Possible Even On SSL by TOKUMARU Hiroshi

Return to index