From: Advanced front-end advanced

Mp.weixin.qq.com/s/UxySd528X…

preface

A few weeks ago, I encountered some problems related to cookies at work. Before that, I wanted to say: Cookies are just like that, even if some properties are not familiar, just look up information online. What are the problems related to cookies?

I was proved wrong. I actually ran into a Cookie problem that kept me going for a long time.

I believe that seeing this side, many people should be eager to try, then I will first test you:

Under what circumstances does a Cookie not write in?

Not to mention obvious ones like syntax errors, but other than that you might reply: write cookies for completely different domains. For example, if your web page is at http://a.com but you insist on writing the Cookie of http://b.com, this situation will not go in.

Or, you might reply: not HTTPS but want to add Secureflag’s Cookie. Yeah, you wouldn’t be able to write in a situation like this.

Can you think of anything else besides that?

If not, just listen to me.

The beginning of tragedy

I wrote an article about CSRF a month ago (let’s talk about CSRF), and just because I need to implement CSRF defense at work, I took the opportunity to research it. Simply put, set a CSRFToken on the Cookie.

But that day I found that I couldn’t get it in.

The url of my test site is: test.huli.com, and the script used to write cookies is:

document . cookie  =  " csrftoken=11111111; expires=Wed, 29 Mar 2020 10:03:33 GMT; domain=.huli.com; path=/ "
Copy the code

I just want to write a Cookie with the name CSRFToken for.huli.com. The problem I had was I couldn’t get it in.

There is nothing wrong with this grammar, I have checked it several times, but I just don’t know why I can’t write it in. We didn’t encounter any of the cases we talked about at the beginning. This is just a simple HTTP website, and is to write their own domain Cookie, how can not write into?

When I first encountered this situation, I also wanted to say that it might be the paranormal phenomenon of my computer, and it would be fine on other people’s computers, so I left it alone for the time being, until PM said to me one day, “Gee, why is this page broken?” After careful check, I found that the server failed to receive cSRFToken because he could not write in the Cookie.

Well, I guess it’s confirmed that it’s not my computer, it’s everyone else. However, there are others who are normal. Everyone else can, but just me and PM can’t.

Fortunately, I’ve seen it before, but when it comes to this kind of weird problem, you should start in traceless mode first, at least to know that your browser won’t be disturbed by other factors. And when I go to traceless mode, I say, okay, I can set cookies. This is not possible under normal circumstances, but it can be set in traceless browsing mode.

That’s really weird. Why not? And if I call my Cookie csrFtoken2, I can write it! Csrftoken is not the only name, but cookies can not have such a thing! Even if there were, cSRFToken would definitely not be a reserved word.

It’s all so weird. What’s wrong with the name CSRFToken? Why isn’t it in there anyway?

So I went to worship Google god, using the keywords cookie can not write, cookie can not set, unable set cookie and so on to search, but nothing, find the answer is completely different from my situation.

I use Chrome devtool to see, obviously http://test.huli.com does not have any Cookie, how can not write in?

After a while of searching for information, I also searched the COOKIE RFC: HTTP State Management Mechanism a little, but still could not find relevant information.

Finally, I didn’t know where the inspiration came from, so I went to Chrome Settings and looked through all the huli.com cookies and deleted them one by one. After deleting, you can write cookies normally.

If you think about it carefully, it is reasonable. After all, the traceless mode can be used, which means that something you did before will affect the writing of cookies. By deleting cookies, you can confirm that the problem must be caused by other related domains. http://test.huli.com cannot write cookies.

Later I thought back to the cookies I just deleted and found a Cookie of the same name also called CSRFToken.

A dark day seem bright

Rare let me find a clue, of course, to follow this clue to continue to investigate.

The Cookie name is cSRFToken. The Cookie name is csrFToken. The Cookie name is csrFToken.

The Cookie is set to Secure and the Domain is.admin.huli.com. It doesn’t look out of the ordinary.

However, after visiting this website, I tried to go to http://test.huli.com, and found that I could not write cookies again, and even the original cookies mysteriously disappeared.

That’s great! Looks like I’m getting closer to the truth!

After deleting the Cookie of the same name from.admin.huli.com, I went to visit my own http://test.huli.com and found that everything was fine. Cookies can be written normally.

The answer seems obvious:

http://test.huli.com cannot write a Cookie with the same name to.huli.com as long as the Cookie with the same name for.admin.huli.com exists.Copy the code

The solution is pretty obvious over here, the first one is to change a Cookie name, the second one is to change a Domain.

For the second solution, remember we wrote the Cookie to the.huli.com Domain at http://test.huli.com? Test.huli.com Domain will work just as well.

So if you go into a little bit more detail, the problem of not putting cookies in there happens when:

http://test.huli.com cannot write cookies with the same name to.huli.com when a Cookie with Domain.admin.huli.com set to Secure already exists.Copy the code

After roughly identifying the problem, I began to adjust each variation to see if I could find out which link was wrong. Finally, I found two key points:

In fact, only Chrome can’t write, Safari, Firefox can

If the Secure flag is not set, you can write

Investigate further

Now that we have a strong clue that this only happens with Chrome, we can follow this line, but how?

Yes, is the most simple and direct way: to find the source code of Chromium!

I have read a lot of articles about the problem and finally found the Source code. Finally, it is my turn to have this day. But the original code of Chromium such a big package, how to find it?

So I decided to Google: Chromium Cookie and found something very helpful in the first search result: CookieMonster. This article explains in detail how Chromium’s Cookie mechanism works and explains that the core is something called CookieMonster.

Then you can go directly to Source code and find cookie_monster.cc at /net/cookies.

Remember just found out that the problems of one of the key theory is related to Secure the flag, so use Secure directly when the keyword search, can be found in the middle part of a DeleteAnyEquivalentCookie function, an excerpt some source code, Lines 1146 to 1173:

// If the cookie is being set from an insecure scheme, then if a cookie 
// already exists with the same name and it is Secure, then the cookie 
// should *not* be updated if they domain-match and ignoring the path 
// attribute. 
// 
// See: https://tools.ietf.org/html/draft-ietf-httpbis-cookie-alone 
if(cc-> IsSecure () && ! source_url.SchemeIsCryptographic() && ecc.IsEquivalentForSecureCookieMatching(*cc)) { skipped_secure_cookie =true ;
  histogram_cookie_delete_equivalent_-> Add (
      COOKIE_DELETE_EQUIVALENT_SKIPPING_SECURE);
  // If the cookie is equivalent to the new cookie and wouldn't have been // skipped for being HTTP-only, record that it is a skipped secure cookie // that would have been deleted otherwise. if (ecc. IsEquivalent (* cc)) { found_equivalent_cookie = true ; if (! skip_httponly || ! cc-> IsHttpOnly ()) { histogram_cookie_delete_equivalent_-> Add ( COOKIE_DELETE_EQUIVALENT_WOULD_HAVE_DELETED); }}}Copy the code

It’s nice of you to add a note here saying:

If there’s a cookie from an insecure scheme, and there’s already a cookie with the same name set to Secure and domain-match, it shouldn’t be set

I’m not sure exactly what domain-match means, but it seems that this is where the Cookie problem occurred. But also close attach resources: tools.ietf.org/html/draft-… The headline reads: “Deprecate modification of ‘secure’ cookies from Non-secure origins.”

It’s not long and you can read it quickly. Here’s a short excerpt:

Section 8.5 and Section 8.6 of [RFC6265] spell out some of the
drawbacks of cookies' implementation: due to historical accident, non-secure origins can set cookies which will be delivered to secure origins in a manner indistinguishable from cookies set by that origin itself. This enables a number of attacks, which have been recently spelled out in some detail in [COOKIE-INTEGRITY].Copy the code

“Cookies Lack Integrity: Real World Implications” and there is a 20-minute film attached, so you can take a look at it and see why it didn’t work.

If you haven’t seen it yet, here’s a summary for you. To understand why cookies couldn’t be written to that case in the first place, think about what would happen if they could.

If http://test.huli.com successfully writes the cSRFtoken cookie of. Huli.com, it seems to have no effect on http://test.huli.com, so it seems reasonable to bring an extra cookie.

However, it has some effect on https://admin.huli.com.

The Cookie that used to be.admin.huli.com and set to Secure will still be there, but now there’s a.huli.com Cookie with the same name. When https://admin.huli.com sends a request, it takes both cookies with it. So the Server might receive something like this:

csrftoken=cookie_from_test_huli_com; csrftoken=cookie_from_admin_huli_com
Copy the code

But when it comes to cookies with the same name, many people will just take the first one, so the cSRFtoken received by Server side will be cookie_from_test_huli_com.

This means that even though you wrote a Secure Cookie at https://admin.huli.com, it was overwritten by another insecure source (test.huli.com)!

So what do you do by blocking the Cookie? Gmail Windows is divided into two parts, one is the mailbox and the other is Hangouts. An attacker can use this trick to replace the user’s session cookie with its own session cookie. However, since Hangouts are different from Gmail’s own domain, Gmail is still the user’s account. Hangouts has become the attacker’s account.

The victim could be unknowingly using the attacker’s account to send messages that the attacker could see.

The second example is a bank website. If the user changes the session cookie to the attacker’s when he wants to add a new credit card, the credit card will be added to the attacker’s account!

This is basically how server Side uses the new cookie attack by masking the original cookie.

conclusion

When I first encountered this problem, I was really upset, because I couldn’t think why a command with perfect syntax couldn’t write cookies. Besides, I seldom used https://admin.huli.com, so I never thought it was the problem.

But this time after solving the problem to look back, in fact, there are some clues to follow in the process, for example, can be said through “clear the Cookie is fine” that should be interference with other cookies, can also be written from other browsers that should be some mechanism of Chrome.

Every clue along the way will lead you to a new path, and if you keep walking, you will be able to successfully navigate the maze.