Article directory
1 Reading thesis topic
Read about the attack and defense of session hijacking, including two Chinese academic papers and one English academic paper. They are: Internet-based TCP session hijacking deception attacks and defense strategies; Research on real-time session hijacking attack technology based on Javascript worms; Prevention of session hijacking using token and session id reset approach (Using token and session ID reset method to prevent session hijacking) ).
2 TCP-based session hijacking
3 TCP session hijacking process
To complete a session hijacking attack, an attacker generally needs the following 5 steps.
1) Discover the attack target. For session hijacking attackers, there are two key issues that need to be solved first to find a suitable attack target. First, attackers generally hope that the attack target is a server that allows TCP session connections, and it is best for the server to conduct TCP connection sessions with many client hosts at the same time, so this means more attack opportunities for attackers; second, Whether the attacker can detect the data flow is also an important issue, because when implementing a specific attack, the attacker needs to guess the sequence number, which requires sniffing the data packets of his previous communication. For a switched network environment , it may also be necessary to use ARP spoofing.
2) Confirm the dynamic session. After identifying a suitable attack target, if the attacker wants to take over a session, he must find a legitimate connection that can be taken over. Unlike most other hacking methods, session hijacking attacks are suitable for occurring when network traffic reaches peak levels. This choice has two reasons. First, when the network traffic is large, it means that there are many active sessions, and there will be many sessions for attackers to choose from. Second, the greater the network traffic, the smaller the probability of the attacker being discovered. When the network traffic is not large or the number of user connections is small, if a user disconnects several times, it is likely to arouse the user's suspicion and be easily exposed; however, if the network traffic is large and there are many users connecting , then users are likely to ignore the hidden problems behind the disconnection, and may just think that it is caused by heavy network traffic.
3) Guess the serial number. The three important parameters related to a TCP session are IP address, port number and sequence. Among them, the discovery of IP address and port number is relatively simple and remains unchanged throughout the session project. TCP uses to distinguish correct data packets and error data packets through the SEQ/ACK sequence number of the data packet, and SEQ/ACK Serial numbers are dynamic and change over time. Therefore, if a hacker wants to obtain the serial number, he can intercept it through sniffing or ARP spoofing. First, the hacker first finds the serial number being used by the attack object (target machine). Secondly, after obtaining the serial number, the hacker guesses the next pair of SEQ/ACK serial numbers based on the principle of the serial number mechanism. At the same time, if the hacker uses a certain A specific method to disrupt the SEQ/ACK of the legitimate user host will give the server a false impression and no longer trust the correct data packets sent by the client host. In this way, the hacker can pretend to be the client host of the legitimate user and use the intercepted correct SEQ/ACK sequence number of the legitimate user. At this point, the hacker's attack host can make a legitimate connection with the server and successfully rob a session connection.
4) Take the client host offline. After the hacker obtains the SEQ/ACK serial number of the legitimate user, he must take the client host offline to completely take over the legitimate session. To make the legitimate client host offline, the simplest way generally is to conduct a denial of service attack on the legitimate user or A distributed denial-of-service attack whereby the client no longer responds. At this time, the server will still continue to send responses to the legitimate client's host. However, since the hacker has controlled the client's host at this time, the client's machine will no longer respond. 5) Take over the session. When the hacker has obtained all the information and data needed, he can continuously send data packets to the server and take over the entire session. During the entire session hijacking attack, hackers will generally continue to send information packets, then establish a legitimate account on the victim server, and even leave some "backdoors" for easy entry in the future. You can easily enter the system at any time. Based on this TCP session hijacking attack, it is a kind of blind hijacking, because the entire session always uses the IP address and port information of the original communicating parties. Although the attacker can pretend to be a legitimate client and send attack data to the server, the server's The destination address of the response packet is still the address of the legitimate client. Therefore, if an attacker wants to obtain information, he needs to use special means such as ARP spoofing to put himself in the middleman's position, otherwise he will not receive any response data from the server.
Figure 1 Session hijacking algorithm implementation process Session hijacking algorithm implementation process
4 Attack defense against TCP session hijacking
1) Encrypt the session. Encryption is one of the few ways to protect against session hijacking attacks. When hackers cannot intercept legitimate data transmission, it is not easy to conduct a session hijacking attack at this time. Therefore, any critical connections used to transmit sensitive data must be encrypted. In an ideal world, all traffic on the Internet should be encrypted. Although many users want a solution that meets their security needs, tools containing this protection technology have not been available due to cost and cumbersome reasons. It has been around for a long time, but it has not been promoted yet. 2) Use security protocols. Whenever a legitimate user wants to connect to a remote server, especially a user or administrator engaged in sensitive work, they should use a secure protocol for connection communication. Generally speaking, protocols like SSH (Secure Shell) or secure Telnet can protect the system from session hijacking attacks. In addition, VPN from client to server is also a good choice.
3) Limit protective measures. In order to avoid session hijacking attacks, when the user or administrator's unit allows less data information to be transmitted from the external network to the unit's internal network, the probability of being subject to session hijacking attacks will be less, and the user will be safer. This is a way to minimize session hijacking attacks. The harder it is for hackers to enter the system, the less vulnerable the system is to session hijacking attacks. Ideally, as many external connections and connections to the firewall should be blocked as possible. Although most users can do this and limit incoming connections, internal users are usually allowed to use any protocol to connect to hosts on the external network, which can reduce the possibility of sensitive sessions being hijacked by attackers.
3．Summarize
TCP session hijacking and spoofing is an advanced application of IP spoofing. Because it does not rely on the operating system and can silently steal confidential information, it is extremely harmful and is increasingly favored by hackers. This article starts from the principle of session hijacking and explains its attack process and defense strategies. Although there is currently no effective way to fundamentally prevent or eliminate it, corresponding prevention can reduce the occurrence of this attack to a certain extent.
3. Session hijacking based on JS worm
5 Principles of attack techniques
Real-time session hijacking attacks based on Javascript worms are also triggered by XSS vulnerabilities. The attack script (Javascrpt worm code) will be injected into the interpretation process of the client browser, and the client browser will execute the attack script to complete the theft of key user data. . In other words, the attacker hijacked the session process and directly simulated user operations to access the user's key data in the client browser environment. Since the attack did not return the user session for replay, it completely bypassed Section 2. Limitations of the two HTTP session protection mechanisms.
Simulate user operations using AJAX. AJAX is not a technology, but a collection of several technical methods. Its core is asynchronous operation. Javascript performs asynchronous calls, constructs XML-Http-Request requests, and interacts with the server in the background. Since the script is injected into the user session environment and executed according to the cookie access control rules and origin policy, when the XML-Http-Request request occurs, the browser automatically adds all cached identity information or cookies, and the server receives these requests. It cannot be determined whether it is operated by the user or automatically sent by the Javascrpt worm.
Figure 2 Real-time session hijacking attack flow chart
As shown in the figure above, a complete attack includes the following five steps:
Step 1. The XSS vulnerability is triggered when the user's web browser accesses the web service, causing the browser's remote access to be stored on a server controlled by the attacker. worm code.
Step 2. The worm code is loaded into the client browser and executed in its environment.
Step 3. According to the set request logic, the worm code constructs an XML-Http-Request and asynchronously submits an access request to the user's key data to the Web application server.
Step 4. The Web server responds to the request and returns user data to the client browser.
Step 5. The worm code transmits user data back to an attacker-controlled server.
To implement this technology, attackers must first complete two tasks: first, discover XSS vulnerabilities on Web services, which is not the focus of this article and will not be discussed in detail; second, write Javascript worm code. Before writing code, you need to conduct source code analysis of the Web service. Through analysis, you can collect all access request links to the user's key data. The collection elements include URL, request type (GET/POST), and submitted parameter set. These elements are used to construct XML-Http -Request variables that need to be passed. Through source code analysis, the request logic of the web service is also obtained, and the program running logic of the attack script is formulated according to the request logic sequence. For example, taking the mail system as an example, a list of user mail IDs must first be obtained before the body content of a single mail can be obtained based on the mail ID. and email attachments.
2. Key technologies
(1) Conditions for the request to occur.
Since the XML-Http-Request request is automatically sent by the Javascript worm, the URL requested and all submitted parameters can be accessed through the javascript script or obtained through other XML-Http-Request requests. If the worm encounters factors that require manual interaction, such as entering a verification code, the request will not be completed.
(2) Attack life cycle
The attack life cycle is a measurement of the worm code execution time. The longer the time, the more user information can be obtained or greater damage can be done. Javascript is an interpreted rather than compiled language and is executed sequentially when the page is loaded. From the perspective of the page survival timeline, the attack life cycle of the Javascript worm is the period from the loading and execution of the worm code to the end of the execution of the worm code, or the period of the page being closed and exited or the page being redirected before the worm code has been executed.
(3) Data return:
The data returned by the server in response to the XML-Http-Request request is received by the client's javascript variables, so the response data needs to be sent back to the attacker. Since the web server and the server controlled by the attacker are not the same server and belong to different domain names, data submission to the server controlled by the attacker is a cross-domain access. The cross-domain access security mechanism is strictly limited in the HTTP security mechanism, such as XML through AJAX. Cross-domain access requests sent by the -Http-Request method will be prohibited. Other cross-domain methods also have various restrictions and can only be implemented through the traditional HTTP request technology of Javascript.
3. Prevention
- Abnormal client behavior monitoring mechanism
From the perspective of individual HTTP requests, the web server cannot determine whether these requests are issued by legitimate user operations or are automatically sent by worms. However, if you monitor the frequency of HTTP requests, you can still find problems. Human operation is different from machine behavior. In order to make as many requests as possible during the attack life cycle, the worm code's HTTP request frequency is much higher than normal human operation. Therefore, the web server should introduce a client abnormal behavior monitoring mechanism, register each HTTP request, detect abnormal HTTP requests through frequency judgment, and immediately introduce a human-computer interaction verification mechanism to block abnormal HTTP requests. Or notify users of abnormal situations so that users can take timely measures to reduce losses, such as closing the page, logging out, etc. 2. Account information security classification mechanism.
During the loading and execution of the Javascript worm, the code is automatically executed, and all request operations do not rely on manual interaction. Therefore, if a verification mechanism is added to the HTTP request, such as CAPTCHA (Completely Automated Public Turing test to tell Com uters and HumansA part, a fully automatic Turing test that distinguishes computers and humans), allowing users to perform some operations that only humans can complete, and the Javascript worm will be unable to continue executing. But if every HTTP request requires entering something like a verification code, the user experience will be greatly reduced. Therefore, it is necessary to establish a scientific account information security classification mechanism. For ordinary user data, verification is not required, but it should be combined with the client abnormal behavior monitoring mechanism mentioned in the first point; for sensitive data, one verification is required; if it is key private data, in addition to web page verification, Interact with users offline, such as mobile phone verification, etc.
4. Summary
Today, when XSS attacks are rampant, research on the prevention of XSS vulnerability attacks, especially malicious code detection technology, is relatively in-depth. Common detection technologies include client-side detection technology and server-side detection technology. In the process of website development and design, the input data should be strengthened. Verification, filtering and encoding, etc., reduce the chance of XSS vulnerabilities. It can be said that minimizing the probability of Web service XSS vulnerabilities through malicious code detection is the basis for avoiding cross-site attacks. However, with the vigorous development of Web 3.0, XSS vulnerabilities cannot be completely eliminated. Preventing such attacks cannot rely on a single prevention technology. In addition to strengthening the security design and development of Web services and applications from the source and reducing XSS vulnerabilities, , a comprehensive prevention mechanism should also be established.
4. Prevent session hijacking based on token and session ID reset method
1. Steps of How Token and Session ID Reset Method Works
- The user wants to access the services of the web server, then he needs to log in, for this a request with username and password is sent from the client to the server. The server login container verifies the user's credentials. If the credentials match, the user will be directed to the second step, otherwise the user will be redirected to the login page, which is step 10.
- When the user logs in successfully, the login container (servlet) extracts the user's IP address and user agent from the user's request, as shown in Figure 2.
Figure 3 The process of successful user login
The server will generate a 32-character long unique token and session ID. The server encrypts the 32-character long token using a triple DES key (168-bit key), resulting in a 40-character long ciphertext. The key is generated only once for token encryption (each token encryption/decryption is done by the same key in the same session). The session ID, 32-character long tag, IP address and user agent, and 168-bit encryption/decryption keys are stored in the server's database for further use. - The server responds to the user with only the session ID and encrypted token. On the user side, the encrypted token is stored in the user's local storage via the "session storage" or "local storage" method (a feature of HTML5), and the session ID is stored in a cookie (by default). Thetoken and session ID reside here until the browser is closed, which is automatically deleted when the user closes the browser.
- When the user makes another request to the server, the request contains the session ID and a 40-character long token. Some users do not request the server for too long, so it may be vulnerable to session hijacking attacks. So the proposed technique has a JavaScript code that sends an AJAX request (with session ID and token) to the server after every 30 seconds.
- The server retrieves the stored data from the database and also retrieves the relevant key to decrypt the token. The server container (servlet) authenticates the user's request (contains session ID, token, IP address and user agent).
- The server generates a new 32 character long token and session ID, and both are updated in the server's database.
- The server encrypts the new token and responds to the user with these IDs and the new encrypted token. Therefore, steps 4 through 7 are repeated for each request.
- When the user clicks the logout button, the java script function sends a logout request to the server,
- The server container invalidates the session on the server side and deletes the data from the database.
- After invalidating the session ID, the user will be redirected to the login page. Before redirecting the user, the java script removes the token from local storage.
Among the proposed techniques, there are some advantages. Even if the adversary is located within the same LAN network and has the same IP address and also successfully steals the token, session ID, user agent contained in the local storage through a data theft attack. For example, if an attacker sits near the victim's computer and copies the local storage value and cookies from the victim's computer and uses it to impersonate the victim's account. An attacker cannot abuse the token and session IDOR to impersonate a valid user or the user to refresh the page after a certain period of time. However, the attacker can successfully impersonate before the token and session ID expire. To handle this issue, you can set a shorter renewal interval to renew the token and session ID.
2. Comparison with existing technology OTC
Figure shows some differences between the proposed technology and OTC technology, wrt performance as well as structural aspects. The suggested technique adds one more layer, i.e. checking posts against OTC. Therefore, the proposed technology is safer and more sophisticated than OTC.
Figure 4 Token and session ID reset method compared to OTC technology (existing technology) The
following figure shows that the token and session ID reset method is beneficial for most attacks. (x = affected by attack, √ = not affected by attack, -√ = means token does not exist, but session ID exists, session I is unpredictable)
Figure 5 Token and session ID reset method is good for most attacks
3. Summary
Attacks that can be prevented are as follows:
- Man-in-the-Middle (MITM) Attacks
First, token and session ID reset methods are not susceptible to MITM attacks because an adversary cannot modify or forge the token during transmission (because the token is in encrypted form). Secondly, if an attacker were to try to perform a replay attack using the captured session ID and token and try to authenticate themselves to the server as a legitimate user, then this would be impossible because if the server receives a message from the client after 30 seconds request, the server will invalidate the session. - Cross-Site Scripting (XSS) Attacks
XSS cannot attack the token and session ID reset methods because the token is stored in the client's local storage and not in a cookie. - Session Fixation Attack
This attack is also not possible with the token and session ID reset methods. Because in this technique, the server generates a new session ID and token after receiving the request from the client. - Cookie Stealing Malware Attacks
The token and session ID reset methods are not possible with this attack because a successful attack attempt requires both a token ID and a session ID. Specifically:
If someone is able to steal the cookie (used for the session ID), the attacker cannot use the cookie to steal the script to access the token ID because the token ID is stored in local storage.
If an attacker is somehow able to steal (session ID and token ID) then we have added a mechanism to update the token ID every 30 seconds so an attacker will not be able to steal (cookie and token ID) and in 30 Send the request to the server within seconds. If the attacker sends a request after 30 seconds and the IP address and the browser's fingerprint (the actual user's fingerprint) do not match on the server side, the server will invalidate the session and redirect to the login page. It's very difficult to spoof all these parameters (session ID, token ID, IP address and browser's fingerprint) within 30 seconds. Therefore, a cookie-stealing malware attack is technically impossible as suggested - Malware controlling the browser
If the browser is controlled by malware, the token and session ID reset method is affected because the token and session ID are managed by the browser. Therefore, the attacker can collect the session ID (from cookie) and token (from local storage) to impersonate the victim's session. - Predictable Tokens and Session IDs
An attacker can neither guess the cookie pattern nor the token. The session ID is randomly generated, each byte is encoded with two hexadecimal characters, and the token is encrypted using triple DES encryption using a 168-bit key. Therefore, an attacker cannot predict valid session IDs and tokens (without knowing the encryption key). - Physical data theft
This means copying cookies directly from the browser. The token and session ID reset method cannot carry out this attack because the session ID is updated in the cookie and the token is updated frequently (within 30 seconds) in local storage. If the attacker successfully steals the token and session ID, he is bound to use that data within 30 seconds, which is very difficult to enforce. - Cookie cloning
This means making a copy of the cookie, which is not possible because only the session ID is stored in the cookie and the token is stored in local storage. So if any attacker clones the cookie, it will not be authenticated by the server as the server will only provide access to the user who has both the token and the session ID.
The token and session ID reset method has shorter token and session ID expiration times. Other technologies have longer expiration times. Therefore, in these techniques, the attacker has more time to crack the session ID of the legitimate user.