0x00 Preface
Earlier in gayhub, I turned to the paper of security conference and some papers of kcon.
https://github.com/knownsec/KCon
In the past, the paper of our generation has learned a lot and also has many questions.
This article is a summary and reflection of the cookie dilemma (https://github.com/knownsec/kcon/blob/master/2015/cookie% 20% E4% B9% 8b% E5% 9b% B0. PDF) by kcon, a senior in the network security laboratory of Tsinghua University in 2015.
Master zouma gave a lot of examples from the perspective of man in the middle attack. He studied the characteristics of cookies and scene application thoroughly.
Pay homage to the predecessors!!
0x02 purpose of cookie
Because the HTTP protocol is stateless, that is, the server does not know what the user did last time, which seriously hinders the implementation of interactive web applications. In a typical online shopping scene, users browse several pages and buy a box of biscuits and two bottles of drinks. At the end of checkout, due to the statelessness of HTTP, without additional means, the server does not know what the user bought. So cookies are one of the "extras" to circumvent HTTP's statelessness. The server can set or read the information contained in the cookies to maintain the state of the user's session with the server. In the shopping scenario just now, when the user selects the first item, the server sends a cookie to record the information of that item while sending the web page to the user. When the user visits another page, the browser will send the cookie to the server, so the server knows what he bought before. Users continue to buy drinks, and the server adds new product information to the original cookie. At checkout, the server reads the cookies sent. Another typical application of cookie is that when you log in to a website, the website often asks the user to enter a user name and password, and the user can check "log in automatically next time". If checked, the next time you visit the same website, you will find that you have logged in without entering your user name and password. This is because the server sent a cookie containing the login credentials (some encrypted form of user name plus password) to the user's hard disk at the previous login. The second time you log in (if the cookie has not expired) the browser sends the cookie and the server validates the credentials, so you don't have to enter a user name and password to log the user in.
(from wiki)
0x03 cookie classification
According to the classification of time effect, cookies are generally divided into temporary cookies and permanent cookies.
1. A temporary cookie is stored in memory. If the browser is closed, the cookie will fail. No time limit is set. The default is temporary cookie.
2. The persistent cookie is stored in the hard disk according to the expiration time set by expires / max age. It will expire when it expires.
0x04 properties of cookie
According to RFC 6265, cookies have the following attributes.
1，name=value
Name = value, which is the cookie key value pair we usually set. When the browser transmits it to the server, it also transmits this key value pair.
2. Expires: absolute expiration time
If the value of this property cannot be converted to a date, the client ignores the property. When the expires of two requests of the same cookie are different, the new one may replace the old one.
3. Max age: relative expiration time, in seconds.
If the value of this property is not a number, the client will not process it.
4. Path: Specifies the web page associated with the cookie.
By default, a cookie is associated with the page on which it was created, with the page in the same directory and with a page in a subdirectory of that directory, and cannot be used to determine security
5. Domain: if the domain value of the cookie is not set, the default value of this property is the host name of the server where the web page creating the cookie is located
6, secure: it specifies how cookie values are transmitted over the network.
By default, cookies are not secure, that is, they are transmitted over a normal, insecure HTTP link. But if a cookie is marked as secure, it will only be transmitted if the browser and server are linked via HTTPS or other secure protocol. This property only guarantees that cookies are confidential.
7, httponly
When it is set to true, it can only be accessed through HTTP, and the key value set to httponly cannot be obtained through document.cookie to prevent XSS from reading the cookie.
Since cookies are stored in the client (browser), they have the characteristics of write with attributes and read without attributes.
Here's a chestnut:
Server: set Cookie: user = r00tuser; domain =. Cnblogs. Com; path = /;
Transmission: Cookie: user = r00tuser;
0x05 how to set cookies
There are two ways.
1. Server
For example, use PHP to set cookies, and set a cookie that expires after 1 hour on taobao.com. The key value pair is test = test.
2. JS sets a cookie that expires in 1 day.
The uniqueness of a cookie is determined by [name, doamin, path]. If all three attributes are the same, they are the same cookie.
0x06 some basic "features" of cookies
Quote some pictures of elder zouma:
Some problems of 0x07 cookie
1, the same name
When the cookie encounters the same name!
Why do you meet the same name? This is related to the mechanism of cookies (write with attributes, read without attributes).
If you encounter the following situation, you will have the same name,
The server code is as follows:
There will be two cookies with the same name, but they are different. Because the uniqueness of cookies is determined by [name, domain, path]. Although the names are consistent, others are different.
When meeting the same name, what should the backend do?
RFC is as follows:
That is to say, there is no standard. In fact, there is also a problem here. When a browser transmits a cookie with the same name, what is the order of its occurrence? (to be discussed later)
So it depends on how we achieve it.
This priority has caused many problems. Like the example of God P
Technical analysis of XSS + super detailed vulnerability (https://www.leavesongs.com/html/zhihu-xss-worm.html)
P God uses the priority of the server server for cookie processing.
Because Python is used here, the latter is used. If PHP is used in the backend, the former is used.
If the backend uses php, what should we do at this time? Is there any way to change the priority of our cookies?
0x08 priority of cookies
According to RFC documents
1. Modify the path.
For example, a page like this: http://a.com/sites/index.php? Id = 1
The cookie returned by server looks like this: set Cookie: user = r00tuser; domain =. A.com; path = /;
Then we can set such cookies as: set Cookie: user = attacker; domain =. A.com; path = / sites /;
Local test, back-end PHP code:
Transmission sequence:
2. In the case of the same path, modify the priority by creating the time.
There should be no way to do this, because the backend creation will certainly be faster than the creation with JS.
It's only effective in the middle man attack scenario.
But in fact, path is enough.
0x09 cookie attack and utilization
In the paper of "cookie dilemma", the master of walking horse cited many scenes and examples.
For example, how to use and bypass under HTTPS and HSTs.
Under HTTPS, you can overwrite cookies through secure.
The problems are as follows:
1. XSS caused by injection.
Because of the blind belief in cookies, I believe that all cookies are passed from the back end.
For example, I also found a problem of blindly believing in cookies in an Src. It is precisely because of this that I will lead to the later research on cookies.
2. Inject the replacement session. The HTTPS page is not a single page, but a combination of multiple pages.
Mr. zouma said a lot in PDF, and gave many examples.
For example, Jingdong's
Like Gmail's
And some bank..
3. In the face of 407 injection attack of HSTs (not very clear)
Found article (http://blog.csdn.net/yanghuan313/article/details/53001332)
There's also a picture of Taoist, but the picture of Taoist hangs up (http://blog.chinaunix.net/uid-27070210-id-3254743. HTML)
4. General attack, etc
When a day comes out, we can use domain and path to precisely control the attack points and conduct batch attacks.
5. Time bomb
Set a permanent cookie, control the domain and path, and you can achieve the effect of crossing time. When the thunder is buried, it depends on what is stepped on.
Please also check the paper of elder zouma.
The above is based on the summary of the elder zouma.
0x10 cookie attacks the remote planting of malicious cookies.
The attack scenario of the elder is based on the middleman, so do we have any way to attack remotely?
For example, to achieve the effect of malicious cookies when users browse malicious websites.
According to RFC 6265
1. Set the cookie of target.com directly through attacker.com?
The third article of RFC documents teaches you to be a human being, and the experimental results show that it is really not possible. (it is not possible to set it through JS or server.)
2. Penetrate the sub domain site under target.com
Feasible but expensive
3. Find XSS (flash) of sub domain or target domain
Feasible, relatively low cost
The attack chain should look like this: (take reflection XSS as an example)
Local practice:
a. COM is attacker
b. COM: 88 is target.com
a. The files in the com directory are
Evil.php code
Evil.js
b. The files in the com directory are:
Xss.php code
Visit a.com/evil.php to plant cookies successfully.
Burp recorded the whole process
In fact, XSS can play cookies... This is just from the perspective of cookie injection to think!
.
There should be many ways to attack. I hope the big guys can give more opinions.
0X11 summary
I salute you! Follow the scripts of the big guys and read more RFC documents~