Session Management

Session Management 
(Brute Force)
Brute Forcing involves performing an exhaustive key search of a web application authentication token's key space in order to find a legitimate token that can be used to gain access.


According to rfc-2617, the Basic Access Authentication scheme of HTTP is not considered to be a secure method of user authentication (unless used in conjunction with some external secure system such as SSL), as the user name and password are passed over the network as cleartext. To receive authorization, the client sends the userid and password, separated by a single colon (":") character, within a base64 encoded string in the credentials.


user-pass
=
userid ":" password


userid
=
*


password
=
*TEXT


For instance, if the user agent wishes to send the userid "Winnie" and password "the pooh", it would use the following header field:
Authorization: Basic bjplc2vcGZQQWxRpVuIHhZGNFt==
Therefore, it is relatively easy to brute force a protected page if an attacker uses decent dictionary lists.
For the page [victim.com/private/index.html] an Hacker can generate base 64 encoded strings with commonly used usernames and a password, generate HTTP requests, and look for a non-404 response:




(Session Replay)
If a user's authentication tokens are captured or intercepted by an attacker, the session can be replayed by the attacker, making the concerned web application vulnerable to a replay attack. In a replay attack, an attacker openly uses the captured or intercepted authentication tokens such as a cookie to create or obtain service from the victim's account; thereby bypassing normal user authentication methods. A simple example is sniffing a URL with a session ID string and pasting it back into the attacker's web browser. The legitimate user may not necessarily need to be logged into the application at the time of the replay attack. While it is generally that username/password pairs are indeed authentication data and therefore sensitive, it is not generally understood that these generated authentication tokens are also just as sensitive. Many users who may have extremely hard-to-guess passwords are careless with the protection of cookies and session information that can be just as easily used to access their accounts in a replay attack. This is often considered forging "entity authentication" since most applications check the tokens stored in the browser or HTTP stream, and do not require user authentication after each web request.
By simply sniffing the HTTP request of an active session or capturing a desktop user's cookie files, a replay attack can be very easily performed. Exploitation can take the following general forms: Visiting a pre-existing dynamically created URL that is assigned to a specific user's account which has been sniffed or captured from a proxy server log. Visiting a specific URL with a preloaded authentication token (cookie, HTTP header value) captured from a legitimate user.
Combination of both
Session tokens that do not expire on the HTTP server can allow an attacker unlimited time to guess or brute force a valid authenticated session token. An example is the "Remember Me" option on many retail websites. If a user's cookie file is captured or brute-forced, then an attacker can use these static-session tokens to gain access to that user's web accounts. Additionally, session tokens can be potentially logged and cached in proxy servers that, if broken into by an attacker, may contain similar sorts of information in logs that can be exploited if the particular session has not been expired on the HTTP server. To prevent Session Hijacking and Brute Force attacks from occurring to an active session, the HTTP server can seamlessly expire and regenerate tokens to give an attacker a smaller window of time for replay exploitation of each legitimate token. Token expiration can be performed based on number of requests or time.
Session Forging/Brute-Forcing Detection and/or Lockout
Many websites have prohibitions against unrestrained password guessing, it can temporarily lock the account or stop listening to the IP address. With regard to session token brute-force attacks, an attacker can probably try hundreds or thousands of session tokens embedded in a legitimate URL or cookie for example without a single complaint from the HTTP server. Many intrusion-detection systems do look for this type of attack; penetration tests also often overlook this weakness in web e-commerce systems. Designers can use "booby trapped" session tokens that never actually get assigned but will detect if an attacker is trying to brute force a range of tokens. Misuse detection hooks can also be built in to detect if an authenticated user tries to manipulate their token to gain elevated privileges.


Session Re-Authentication
Critical user actions such as money transfer or significant purchase decisions should require the user to re-authenticate or be reissued another session token immediately prior to significant actions. Developers can also somewhat segment data and user actions to the extent where reauthentication is required upon crossing certain "boundaries" to prevent some types of cross-site scripting attacks that exploit user accounts.


Session Token Transmission
If a session token is captured in transit through network interception, a web application account is then prone to a replay or hijacking attack. Typical web encryption technologies include but are not limited to Secure Sockets Layer (SSLv2/v3) and Transport Layer Security (TLS v1) protocols in order to safeguard the state mechanism token.


Session Tokens on Logout
With the popularity of Internet Kiosks and shared computing environments on the rise, session tokens take on a new risk. A browser only destroys session cookies when the browser thread is torn down. Most Internet kiosks maintain the same browser thread. It is recommended to overwrite session cookies when the user logs out of the application.