[Computer Network Learning Notes] What is Cookie and the basic concept of cookie hijacking?

Notes for future study reference. Content comes from the Internet.

Basic concepts of COOKIE:

A cookie is generated by the server and sent to the User-Agent (usually a browser). The browser saves the key/value of the cookie to a text file in a directory, the cookie is sent to the server when the same website is requested next time (provided that the browser is set to enable the cookie ). The cookie name and value can be defined by the server. for JSP, JSESSIONID can be directly written, so that the server can know whether the user is valid and whether to log on again, the server can set or read information contained in cookies to maintain the state of the user's session with the server.

 

What is cookies? To put it simply, the cookies server temporarily stores the information (.txt text file) in your computer so that the server can identify your computer. When you are browsing the website, the web server will first send a small piece of information to your computer, and cookies will help you record the text or some choices on the website. When you visit the same website next time, the web server will first check whether there are any cookies left by the Web server. If so, the web server will judge the user based on the cookies, send specific webpage content to you.

 

What is the role of cookies? Currently, many websites use the new user registration feature. Sometimes you have registered it. When you access the website again, it will automatically recognize you and say hello to you. Do you feel very kind? Of course, this function is only a superficial phenomenon. More importantly, websites can use cookies to track the habits of users accessing the website, such as when to visit and what pages to visit, the duration of each webpage. Using this information can provide users with personalized services, and can also be used as a tool to understand all user behaviors. It provides some reference value for the improvement of website business strategies. For example, if you view flight schedules at an airline site, the website may create cookies containing your travel plan, it may also only record the web pages you have visited on the site. During your next visit, the website will adjust the displayed content according to your situation, put the content you are interested in at the forefront. This is an advanced cookie application. Currently, cookies are the most widely used to record user login information, so that you do not need to enter your username or password during next access-of course, this convenience also causes user information leakage, this is especially common when multiple users share a single computer.

 

In addition, some people think that the use of cookies on websites may infringe on user privacy. However, most users do not know much about cookies, and most of these personal information is used as statistical data, this does not necessarily cause direct losses to users. Therefore, there are no legal restrictions on cookies and users' privacy. Many websites are still using cookies to track user behavior, some programs require users to enable cookies for normal application. You can use the privacy settings in the "privacy" option to determine whether to allow websites to use cookies to track their own information, from all restrictions to all permits, or restrict some websites, you can also manually enable or disable the use of cookies for editing specific website settings. The default setting of IE browser is "intermediate"-some websites have restrictions on using cookies. For ie browsers, you can choose tools> Internet Options> privacy to view and modify cookies on your PC. Script attacks against cookies:Although cookies are not as dangerous as viruses, they still contain some sensitive information: user names, computer names, browsers used, and websites that have been visited. Users do not want this content to be leaked, especially when there is still private information. This is not an armist. a cross site scripting attack can achieve this purpose. Generally, cross-site scripting attacks often use website vulnerabilities to implant script code or reference the third method of script code on website pages, which may cause cross-site scripting attacks, when a cross-site scripting attack occurs, the script command reads all the cookies of the current site (no cookie scope restriction exists ), then, the cookie content is submitted to the specified server (such as Ajax) in some way ). Once a cookie falls into the hands of attackers, it will reproduce its value. It is recommended that developers output sensitive content to the client cookie (for example, the content can identify the user): 1) set that the cookie cannot be read by the script, in this way, the above problems are solved to a certain extent. 2) encrypt the cookie content and embed a timestamp before encryption to ensure that the encrypted passwords are different (and prevent message replay ). 3) when the client requests, the cookie content is updated each time or at a time (I .e., based on 2nd Small entries, re-encrypted) 4) The timestamp is written to the cookie each time, the database needs to record the last timestamp (to prevent cookie tampering or replay attacks ). 5) when the client submits a cookie, it decrypts the key and then verifies the timestamp. If the timestamp is smaller than the record in the data database, it indicates an attack. Based on the above suggestions, even if the cookie is stolen, the cookie is randomly updated and the content is irregular, which cannot be exploited by attackers. In addition, the timestamp is used to prevent cookie tampering or replay. Cookie Theft: hackers collect user cookies and send them to attackers. Attackers will use cookie information to legally access user accounts. Cookie tampering: using the security mechanism, attackers can add code to rewrite cookie content for sustained attacks.

Cookie and authentication

Cookies exist because they can help developers achieve a certain purpose. Cookie acts as a persistent link between the browser and the server. Especially for applications that use a single login, the stolen cookie is the possible culprit of the attack. This is true for a click attack.

 

To use cookies, you do not need to explicitly create and read them programmatically. If you use session Status and form authentication, you use cookies implicitly. Of course, ASP. NET supports cookie-free session states, and ASP. NET 2.0 also introduces form authentication without cookies. Therefore, theoretically, you can use these functions without a cookie. I am not saying that you no longer have to do this, but in fact this is one of the worse cases of therapy than disease. A cookie-free session actually embeds the session ID in the URL so that everyone can see it.

 

What are the potential problems related to the use of cookies? Cookie may be stolen (that is, copied to the hacker's computer) and poisoned (that is, it is filled with malicious data ). These operations are usually a prelude to an attack. If the cookie is stolen, it will "authorize" external users to connect to the application in Your name (and use protected pages), which may make it easy for hackers to bypass authorization, the role and security settings allow the victim to perform any operations. Therefore, the authentication cookie is usually given a relatively short lifetime, that is, 30 minutes. (Please note that the cookie will still expire even if it takes longer to complete the browser session .) In case of theft, hackers have 30 minutes to try the attack.

 

You can extend the time limit to avoid users having to log on too frequently. However, please note that this will put yourself in danger. ASP. NET persistent cookies should be avoided in all circumstances. It will cause the cookie to have almost permanent lifetime, up to 50 years! The following code snippet demonstrates how to easily modify the cookie expiration date.

 

void OnLogin(object sender, EventArgs e) {   // Check credentials   if (ValidateUser(user, pswd)) {      // Set the cookie‘s expiration date      HttpCookie cookie;      cookie = FormsAuthentication.GetAuthCookie(user, isPersistent);      if (isPersistent)          cookie.Expires = DateTime.Now.AddDays(10);      // Add the cookie to the response      Response.Cookies.Add(cookie);      // Redirect      string targetUrl;      targetUrl = FormsAuthentication.GetRedirectUrl(user, isPersistent);   Response.Redirect(targetUrl);   }}

 

You can use this code in your login form to fine-tune the lifetime of the authentication cookie.

 

Session hijacking

 

Cookies are also used to retrieve the session Status of a specific user. The session ID is stored in the cookie, which is sent back and forth with the request and stored on the computer of the browser. Similarly, if the session cookie is stolen, it can be used to enable the hacker to access the system and access the session Status of others. Needless to say, as long as the specified session is active (usually no more than 20 minutes), this may happen. An attack initiated by impersonating the session status is calledSession hijacking. For more information about session hijacking, see theft on the Web: Prevent session hijacking.

 

How dangerous is this attack? It is hard to explain. This depends on the functions of the website. More importantly, how the pages of the website are designed. For example, assume that you can obtain the session cookie of another user and attach it to a request to a page on the site. You load the page and gradually study its normal user interface. Except that this page uses the session Status of another user, you cannot inject any code into this page or modify any content on this page. This is not too bad, but if the information in the session is sensitive and critical, it may directly lead to successful exploitation by hackers. A hacker cannot penetrate into the content stored in a session, but he can use the information stored in the session, just as he entered it legally. For example, assume that there is an e-commerce application, and its users add items to the shopping cart when browsing the site.

 

• Solution 1.The content of the shopping cart is stored in the session state. However, during checkout, you are required to confirm and enter payment details through secure SSL connections. In this case, hackers can only learn about the shopping preferences of victims by accessing the session Status of other users. Hijacking in this environment does not actually cause any damage. Only confidentiality is affected.

• Solution 2.The application processes an archive for each registered user and saves the archive in the session state. Worse, the archive may include credit card information. Why store the user file details in a session? One of the goals of an application may be to avoid repeatedly typing your credit card and bank information. Therefore, during settlement, the application locates the user to a page with a pre-filled domain. One of these domains is the credit card number obtained from the session status. Can you guess the end of the story now?

 

The application page design is the key to preventing session hijacking attacks. Of course, there are still two points that have not been clarified. First, how to prevent Cookie Theft? Second, how can ASP. NET detect and prevent hijacking?

 

ASP. NET session cookies are extremely simple and only contain session ID strings. The ASP. NET Runtime Library extracts session IDs from cookies and compares them with active sessions. If the ID is valid, ASP. NET connects to the corresponding session and continues. This behavior greatly facilitates hackers who have stolen or can guess valid session IDs.

 

XSS and man-in-the-middle attacks and strong access to the client PC are all ways to obtain valid cookies. To prevent theft, you should implement security best practices to prevent XSS and its variants from winning.

 

To prevent session ID guessing, you should avoid estimating your skills too much. Guessing session ID means that you know how to predict a valid session ID string. For the algorithm used by ASP. NET (15 random numbers mapped to URL-enabled characters), the probability of a valid ID is randomly estimated to be close to zero. I can't think of any reason to replace the default session ID generator with my session ID generator. In many cases, this will only facilitate attackers.

 

The worst consequence of session hijacking is that once a cookie is stolen or guessed, ASP. NET has no way to detect fraudulent cookie usage. Similarly, ASP. NET restricts itself to check the validity of the ID and the source of the cookie.

 

Jeff prosise, a friend of mine at wintellect, wrote a good article about session hijacking for msdn magazine. His conclusion is not comforting: it is almost impossible to establish a fortifier that can fully defend against attacks initiated by the stolen session ID cookie. However, the Code he developed provides wise suggestions for further improving security standards. Jeff created an HTTP module that monitors incoming requests and outgoing responses for session ID cookies. This module attaches a hash code to the session ID, making it more difficult for attackers to reuse cookies.

 

[Computer Network Learning Notes] What is Cookie and the basic concept of cookie hijacking?