Session hijacking and Session-ID security Length

Session hijacking and Session-ID security Length
Session hijacking attacks are initiated from the Web Session control mechanism, which is usually the deprivation of Session token management.
Because HTTP Communication uses many different TCP connections, the Web server needs a method to identify the connection of each user. The most useful method is that after a client passes authentication, the Web server sends a token to the browser of the client. Session tokens are generally composed of variable-length strings and can be stored in different ways. For example, in a URL, in the cookie header of an HTTP request (request header ), or its header in the HTTP request, or in the body of the HTTP request.
Session hijacking attacks steal or predict Valid Session tokens to gain unauthorized Web server access permissions.
Example 1 Session proxy hijacking
In this example, we can see that the first attacker uses a proxy to capture a valid Session token called "SessionID ", then he uses the Valid Session token to obtain the unauthorized access permission to the Web server.

Example 2 Cross-Site Scripting
Attackers can run malicious code on the client to obtain the Session token. This example illustrates how attackers can use XSS to steal Session tokens. If attackers send malicious JavaScript code to the victim's website or when the victim clicks a link, JavaScript will run the attacker's injection script. As shown in, it can display the current Sessioncookie value. using the same technology, you may create a Session to send it to the attacker.

<SCRIPT>alert(document.cookie);</SCRIPT>

Note * to prevent Cookie Theft, see: Improving NodeJS Website Security: Web Server anti-hacker attack techniques
The Session ID must be at least 128 characters long to prevent brute-force Session guessing attacks.
In WebLogic deployment, the length of at least 128 bits should be specified for the Session ID. A short Session ID makes the application vulnerable to brute-force Session guessing attacks. If an attacker guesses the ID of an authenticated user Session, the attacker can take over the user Session.
Prediction Formula for the time required to guess the Valid Session ID:

(2^B + 1) / (2 * A * S)

Where:
B is the number of bits of Session IDs. A is the number of BITs that attackers can try per second. S is the number of valid Session IDs and the number of guessed bits at any given time.

If attackers manipulate thousands of zombie computers, they can try to guess tens of thousands of sessionids per second. This is reasonable. If the website has a high popularity and a high access volume, such high-traffic speculation may be ignored for a period of time.

The valid Session ID is provided to the lower limit of the number of users to be guessed. It is the number of users of active websites at any given time point. However, discard your Session without recording that any user will add this number. (This is one of the many good reasons for Session timeout in a short-term activity .)

Has a 64-bit Session ID. For a large website, it is assumed that attackers can try 10000 guesses per second and there are currently 10000 valid Session IDs. Based on these assumptions, the attacker successfully guessed that the Valid Session ID would be less than 4 minutes.

Assume a 128-bit Session ID. The website is also a website with a large traffic volume. Attackers may try to guess 10000 million guesses and 10000 valid Session IDs per second. Based on these assumptions, the attacker successfully guessed that a valid Session ID would be later than 292.