Secure Session Tokens

Idea created by russell.pope on Nov 26, 2014
    Not planned

    We delivery a number of service desk services to many customers, some of which will periodically request that we get 3rd party security companies to come and perform an IT Health Check on the environments. One issue that consistently pops up in these health checks is to do with the security of the current application session tokens as follows:


    The application was found to include session tokens as GET parameters. This is considered not to be in line with security best practice because tokens travelling in this way can end up cached in intermediate proxies and log files.

    The SID & FID parameters passed within the URL stream were used as session tokens, and are detailed in the following example request: KEEP.IsPopUp=1+KEEP.POPUP_NAME=USD1409585986958+popupType=1

    In addition, the SID token was analysed for predictability.

    While the token appeared to be generated following a random algorithm, the length of the token oscillated from between an eight and 10 length integer.


    This is normally logged as low risk due to the fact that all activity is SSL encrypted and that the SID also needs a BOPSID in order to perform updates to the data, however it is still a theoretical risk that either a session might get hijacked by guessing it or by another form of attack at the client such as XSS.


    It would be very helpful and alot more secure if the design around Service Desk access could be changed to use more secure mechanisms. The recommendation from the security audit was as follows:


    It is recommended that session management is controlled through the transmission of complex secure tokens

    stored within a cookie. This information should be passed using an encrypted protocol such as HTTPS to limit

    the ability of an attacker to retrieve sensitive session information.

    Ideally, session tokens should be of a more complex nature, but relying on alphanumeric characters as well.