Generate strong tokens

Objective:

It should be extremely unlikely that an attacker with large amounts of bandwidth and processing resources should be able to guess a single valid token within the lifetime of its validity.

  • Tokens should use a large set of possible values
  • Should contain a strong source of pseudo-randomness
  • Should only be an identifier used by the server to locate the relevant user object.
  • Should contain no meaning or structure.
  • Must use a cryptographically-secure source of randomness.
  • For additional entropy, use:
    • Source IP and port number
    • User-agent from the request
    • Time of the request

Good formula for token generation:

  • Concatenate (place the most variable towards the start):
    • Pseudorandom number
    • Request-specific data (e.g. IP)
    • Secret string from server that is generated each time the server is booted.
  • SHA256 concatenated string.

Protect tokens throughout their lifecycle

  • Only transmit over HTTPS (use the secure flag on any cookies).
  • Never transmit in the URL. Always use POST requests.
  • Implement logout and ensure it invalidates all tokens.
  • Minimise session expiration time.
  • Ensure that concurrent logons for the same user cannot occur. If an old session identifier is used, the user should be informed.
  • If an admin function requires sessions to be viewed, the session token should not be displayed.
  • The cookie path and domain should be as restrictive as possible.

To defend the session management mechanims against attack:

  • Audit the application's codebase to remove any XSS vulnerabilities.
  • If an arbitrary token is submitted, the in-session token should be cancelled and the user returned to the application's start page.
  • To protect against CSRF, require a two-step confirmation or reauthentication before a high-risk transaction is carried out.
  • CSRF can also be protected against by transmitting the token in a HTML hidden field rather than via a cookie.
  • To mitigate against session fixation attacks, always create a fresh session after each authentication.

Per-page tokens

  • A new token is created whenever a user requests an application page.
  • Issues - stops backwards and forwards buttons from working.
  • Can be used to monitor pages used by the customer and can be used to detect attempts to access functions out of order.

Log, monitor and alert

  • Application should monitor requests that contain invalid tokens.
  • Where an attacker attempts to generate lots of tokens as part of a guesssing attack, this will leave an obvious mark on the application log.
  • To help mitigate against brute-force attacks, you can temporarily block IPs when a certain number of incorrect attempts have been made.
  • Users should be alerted to anomalous events (e.g. concurrent logons).

Reactive session termination

  • Where an anomoly is detected, the session can be easily terminated by revoking the token:
    • Modified hidden HTML field or URL parameter.
    • Anything that looks like an SQL injection or XSS attack.
    • Any input that would have been stopped by client-side validation.