Session Hijacking
Session hijacking attacks from the Web Session control mechanism, usually the deprivation of session token management.
Because HTTP communication uses many different TCP connections, the web server needs a way to identify each user's connection. The most useful method is when a client successfully authenticates, the web server sends a token to the client's browser. The Session token usually consists of a variable-length string, and it can be stored in different ways, such as in the URL, in the HTTP request's cookie header (request header), or in its header in the HTTP request, or in the in the body of the HTTP request.
Session hijacking attacks gain unauthorized web server access by stealing or predicting a valid session token.
Example
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", which he then uses to gain unauthorized access to the web server.
Example 2 Cross-site scripting attack
An attacker can obtain a session token by running malicious code on the client. This example shows how an attacker can use an XSS attack to steal the Session token. If an attacker sends malicious JavaScript code to the victim's website or when the victim clicks a link, the JavaScript will run the attacker's injected script. As shown in the figure, it can display the value of the current Sessioncookie; using the same technique it is possible to create and send this Session to an attacker.
<SCRIPT>alert(document.cookie);</SCRIPT>
Note* To prevent cookies from being stolen, please refer to: Improve the security of NodeJS websites: Tips for preventing hacker attacks on web servers
Safe length of Session ID
Session IDs should be at least 128 bits long to prevent brute force session guessing attacks.
As described in the deployment in WebLogic, you should specify a length of at least 128 bits for the Session ID. A short session ID makes the application vulnerable to brute force session guessing attacks. If an attacker guesses an authenticated user's Session ID, he can take over the user's session.
Predictive formula for how long it will take to guess a valid Session ID:
(2^B + 1) / (2 * A * S)
in:
- B is the number of digits of the Session ID
- A is the number of attempts per second the attacker can make
- S is the number of valid Session IDs, and the number of guesses at any given time
If an attacker manipulates thousands of zombie computers, it is reasonable that they could try to guess tens of thousands of SessionIDs per second. If the site's popularity and traffic are high, this high-traffic speculation may go unnoticed for a while.
The lower bound on a valid Session ID is the number of users available to be guessed that are active on the site at any given moment. However, dropping your own Session without logging any users will increase this number. (This is one of many good reasons to have a short active Session timeout.)
有64位的Session ID。对于一个大型网站，假设攻击者可以每秒尝试10000次的猜测，并且当前存在10000个有效的Session ID。基于这些假设，攻击者成功地猜测到有效Session ID的时间将小于4分钟。
现在假设一个128位Session ID。同样是一个访问量非常大的网站，攻击者可能会尝试每秒10000次的猜测与可供猜到10000个有效的Session ID。根据这些假设，攻击者在预期的时间内成功地猜出一个合法的Session ID将大于292年。
整理自：