Cookie, session, session hijacking simple summary

Cookie mechanism:

Cookies are small pieces of text that the server stores on the local machine and are sent to the same server with every request.

The Web server sends Cookies to the client using HTTP headers. At the client, the browser parses the cookies and saves them as a local file, and he automatically attaches any requests for the same server to these cookies.

Because HTTP is a stateless protocol, and the cookie mechanism uses a scheme that maintains state on the client, the session is the protocol that holds the state on the server. Cookies are the storage mechanism of the session state on the client side, and he needs the user to open the cookie support of the clients.

The contents of the cookie mainly include: name, value, expiration time, path and domain. The path together with the domain constitutes the scope of the cookie. If you do not set an expiration time, the cookie will be closed for the duration of the browser session. This cookie, which is the lifetime of the browser session, is referred to as a session cookie. Session cookies are generally not stored on the hard disk but are kept in memory, although this behavior is not regulated. If the expiration time is set, the browser will save the cookie to the hard disk, turn it off and open the browser again, and the cookies remain valid until the set expiration time expires. Cookies stored on the hard disk can be shared between different browser processes, such as two IE windows. For cookies stored in memory, different browsers have different ways of handling them.

The session mechanism uses a solution that maintains state on the server side. At the same time, we also see that because of the server-side hold state of the scheme in the client also need to save an identity, so the session mechanism may need to use the cookie mechanism to achieve the purpose of preserving the identity. The session provides a convenient way to manage global variables.

Session is for each user, the value of the variable is saved on the server, with a sessionid to distinguish which user session variable, this value is accessed by the user's browser when the server is returned, when the customer disables the cookie, This value may also be set to be returned to the server by get.

As far as security is concerned: when you visit a site that uses a session and create a cookie on your own machine, it is recommended that the session mechanism on the server side be more secure because it does not arbitrarily read the information stored by the customer.

session mechanismThe session mechanism is a server-side mechanism that uses a hash-like structure (or perhaps a hash table) to hold information.

When a program needs to create a session for a client's request, the server first checks to see if the client's request contains a session ID (called the session ID.), and if it is included, it has previously created a session for this client. The server will follow the session ID to retrieve the session (not retrieved, a new one), if the client request does not include session ID, then create a session for this client and generate a session ID associated with this session, The value of session ID should be a string that is neither duplicated nor easy to be found, and the session ID will be returned to the client in this response to save.

This session ID can be saved by using a cookie, so that the browser can automatically play the logo to the server during the interactive process. Generally the name of this cookie is similar to Seeesionid. However, a cookie can be artificially banned, and there must be other mechanisms that can still pass the session ID back to the server when the cookie is banned.

A technique that is often used is called URL rewriting, which attaches the session ID directly behind the URL path. There is also a technique called form-hidden fields. Is that the server automatically modifies the form, adding a hidden field so that the session ID can be passed back to the server when the form is submitted.

Both the cookie and session can be tracked, but the principle of completion is not quite the same. Under normal circumstances both can satisfy the demand, but sometimes can not use the cookie, sometimes can not use the session. The following is a comparison of the characteristics of the two and the place of application.

　　1. Different access modes

Only ASCII strings can be stored in a cookie, and if the requirement is to access Unicode characters or binary data, the requirement is first encoded. There is no direct access to Java objects in cookies. To store slightly more complex information, it is difficult to use cookies.

In the session, you can access any type of data, including not limited to string, Integer, List, map, and so on. Session can also be directly stored in Java beans and even any Java class, objects, etc., the use of very easy. The session can be considered a Java container class.

　　2. Differences in privacy policies

Cookies are stored in client-side readers and are visible to clients, and some programs on the client may snoop, copy, or modify the contents of a cookie. The session is stored on the server, is transparent to the client, and there is no risk of sensitive information disclosure.

If you choose a cookie, the best way is to try not to write sensitive information, such as your account password, to the cookie. It is best to encrypt the cookie information like Google and Baidu, submit it to the server, and then decrypt it to ensure that the information in the cookie can be read as long as I understand it. And if the choice session is more convenient, anyway, is placed on the server, the session of any privacy can be effectively protected.

　　3. The difference in validity

Anyone who has used Google knows that Google's login information is valid for a long time if they sign in to Google. Google will permanently record the user's login information without having to log back in every visit. To achieve this effect, it is a good choice to use cookies. You only need to set the cookie expiration time property to a very large number.

Since the session relies on a cookie named Jsessionid, and the cookie Jsessionid expiration time is acquiesced to –1, simply close the reader the session will be invalidated, so the session can not complete the information forever effective effect. Using URL rewrite can not be done. And if the timeout period of the set session is too long, the server accumulates more sessions, the more likely to incur memory overflow.

　　4. Differences in server pressure

Session is stored on the server side, each user will produce a session. If the number of concurrent access users is very large, it will produce a lot of sessions, consuming a lot of memory. Therefore, like Google, Baidu, Sina such a high number of concurrent visits to the site, is unlikely to use the session to track customer sessions.

While the cookie is stored on the client, it does not occupy server resources. Cookies are a good choice if you have a lot of concurrent readers. For Google, Baidu, Sina, cookies may be the only option.

　　5. browser support for different

Cookies are supported by the client browser. If the client disables cookies or does not support cookies, session tracking is invalidated. With regard to WAP applications, regular cookies are useless.

If the client browser does not support cookies, you need to use session and URL rewrite. It is important to note that all the URLs used in the session program are URL-rewritten, otherwise the session track will fail. For WAP applications, Session+url address rewriting may be its only option.

If the client supports cookies, the cookie can be both set to the browser window and the child window is valid (setting the expiration Time to –1), or it can be set to be valid in all reader windows (set the expiration time to an integer greater than 0). However, the session can only be valid within the Reader window and its subwindow. If two browser windows are irrelevant, they will use two different sessions. (IE8 under different window sessions coherent)

　　6. Differences in cross-domain support

Cookies support cross-domain access, such as setting the Domain property to ". Biaodianfu.com", and all domain names with the suffix ". biaodianfu.com" are able to access the cookie. Cross-domain cookies are now commonly used in networks such as Google, Baidu, Sina, and so on. The session does not support cross-domain access. The session is valid only within the domain where he is located.

Only using cookies or simply using the session may not achieve the desired results. At this point, you should try to use both cookies and session. The combination of cookie and session will accomplish many unexpected effects in practical projects.

Session Hijacking

from: Ourjs Links: http://ourjs.com/detail/54f3f638232227083e00003b

Session hijacking attacks from the web session control mechanism, usually a denial of session token management.

Because HTTP traffic uses many different TCP connections, the Web server requires a method 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 browser. Session tokens are usually composed of variable-length strings, and it can be stored in different ways, such as in a URL, in the cookie header of an HTTP request (request header), or in another header in an HTTP request, or in the body of an HTTP request.

Session hijacking attacks gain access to unauthorized Web servers by stealing or predicting valid session tokens.

Example

Example 1 Session Agent hijacking

In this example, we can see that the first attacker uses a proxy to catch a valid session token called "SessionID", and then he uses the valid session token to gain unauthorized access to the Web server.

Example 2 Cross-site scripting attacks

An attacker could obtain a session token by running malicious code on the client. This example shows how an attacker could exploit an XSS attack to steal a session token. If the attacker sends malicious JavaScript code to the victim's website or when the victim clicks the link, JavaScript will run the attacker's injection script. , it can display the value of the current Sessioncookie, and the same technique may be used to send the session to an attacker.

<script>alert (Document.cookie);</script>

Note * Prevent cookie theft See: Improving the security of the NODEJS website: Web server anti-hacker skills

Security length of Session ID

The session ID should be at least 128 bits long to prevent brute force session guessing attacks.

In WebLogic deployment, it is described that you should specify a length of at least 128 bits to be specified for the session ID. A shorter session ID makes the application susceptible to brute-force session guessing attacks. If an attacker guesses an authenticated user session ID, he can take over the user's session.

Predictive formula for guessing the time required for a valid session ID:

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

which

• B is the number of bits in the session ID (number of bytes)

• A is the number of attackers who can try every second

• S is the number of valid session IDs, and the number guessed at any given time

If an attacker manipulates thousands of zombie computers, they can try to guess tens of thousands of SessionID per second which is reasonable. If the site's popularity is high and the number of visits is large, this high-traffic speculation may be overlooked over time.

The valid session ID is provided to the number of users who have been guessed the lower limit is active on the website at any given moment. However, discarding your own session without logging any user will increase this number. (This is one of many good reasons to have a short-term activity session timeout.) ）

Session ID with 64 byte bits. For a large web site, it is assumed that an attacker can attempt to guess 10,000 times per second and that there are currently 10,000 valid session IDs. Based on these assumptions, the attacker successfully guesses that the time for the valid session ID will be less than 4 minutes.

Now assume the session ID of a 128 byte bit. Also a very large web site, an attacker could try to guess 10,000 guesses per second with a valid session ID of 10,000 to guess. Based on these assumptions, the attacker successfully guessed that a valid session ID would be greater than 292 years in the expected time period.

Cookie, session, session hijacking simple summary