1

I have tried to look this up online a lot but have found no concrete explanation that answers my question hence hoping someone can help me answer my question—- My question revolves around cookies and what cookies are sent to the server everytime I make a HTTP request. Lets suppose that I have logged into www.facebook.com and have received a cookie from the above domain for session management etc. Now lets assume an attacker sends me an email to my gmail account and I navigate to the attackers website maybe at www.malicious-website.com and fill out some information in a form and hit the submit button. The minute I hit the submit button the attacker makes a call to the facebook server to delete my facebook profile. My question is if the cookie that www.facebook.com sent to me is sent back to the server to delete my account eventhough I make a call from www.malicious-website.com and not www.facebook.com? Does this mean that all the cookies available in my browser will be sent during every HTTP request I make? I read somewhere that cookies only specific to the domain will be sent to the server, if this is true how can one do the CSRF attack? I understand that if I set the “domain” option for my cookies the cookie would only be sent to the particular domain and subdomain set but how does it work when I have to send a cookie during every HTTP request? What cookies are sent?

2
  • 1
    Cookies specific to the destination domain are sent with each request. You can do a CSRF attack using HTML Elements such as a Form to send the request and tricking the user into clicking to submit the form, for example. See owasp.org/www-community/attacks/csrf for details. There are a lot of details such as when CORS applies. But the basic story is as above.
    – joshp
    Jun 3, 2021 at 6:08
  • In a CSRF attack, the attacker never gets direct hold of the cookie. Instead the attacker tricks you into sending a malicious request to the target site (e.g. Facebook). Since it is you sending the request directly to the target site, the request will carry your cookie.
    – JacquesB
    Jun 3, 2021 at 12:09

3 Answers 3

2

You are correct that a cookie is only send back to the originating domain. In a CSRF-attack, the attacker never gets direct access to the cookie, but tricks the victim into send a malicious request to the legitimate domain.

For example, lets assume I want to trick you into adding me as a friend on Facebook. I send a mail to you with an innocent looking link. But the link is actually http://facebook.com/?addFriend=JacquesB&confirm=true (or something to that effect). You click on the link, and since it goes to the facebook domain, your facebook authentication cookie is sent along with the request, so the request is authenticated and executed by Facebook.

If the malicious request has to be a POST-request, the attacker could create a form which posts the appropriate values to Facebook and trick you to submit it. Various HTML tricks could be used to hide for the victim that anything was posted to Facebook - e.g posting inside a tiny IFrame.

2

I think the key here is to understand how HTTP, the protocol of the web, works. As a user, it's easy to think in terms of "navigating a site", and "being sent from one site to another", etc; but at the very lowest level, every interaction comes down to a single process:

  • Your browser sends a request to a particular server.
  • The server decides on a response, which it sends back to your browser.

Every other detail of the web - forms, cookies, etc - happens within that simple request-response framework.

So let's look at your scenario with that in mind:

I have logged into www.facebook.com and have received a cookie from the above domain for session management etc.

Your browser sent a request to the server at facebook.com with your login details. The server response included some text to store as a "cookie". Your browser recorded that that cookie should be sent whenever a request is made to facebook.com.

Now lets assume an attacker sends me an email to my gmail account and I navigate to the attackers website maybe at www.malicious-website.com

Now your browser is sending a request to the server at www.malicious-website.com. That request won't include the cookie set by facebook.com, because it's a different host.

and fill out some information in a form and hit the submit button.

Your browser now makes a new request, with that form data. The key question is where that request is sent to.

If the request is sent to www.malicious-website.com, nothing particularly happens. Like the previous request, no cookie is transmitted, so they learn nothing.

the attacker makes a call to the facebook server to delete my facebook profile

The attacker could have some software on the server (a "browser" of sorts) that sent a request to facebook.com; but without knowing what's in your cookie, that software can't pretend to be you.

even though I make a call from www.malicious-website.com and not www.facebook.com?

Any call that you make is from your browser, not from another server. And that's the key to a CSRF attack:

  • the attacker doesn't send a request to facebook.com, they trick you into sending one, from your browser
  • the attacker never sees your cookies, they just trick you into using them

So what happens is that you submit the form, and the form says to send the request with the form's contents to facebook.com. While your browser is sending that request, it finds the cookie facebook.com set when you logged in, and includes it in the request.

When the server at facebook.com sees that cookie, it knows it's you who made the request. If the form you submitted has the same details as the "delete my account" form, it goes ahead and deletes your account, because you just asked it to!

In order to protect against the attack, the server has to know whether you intended to send the request. For instance, if the real "delete my account" form has a random number in it that changes every time you load the page, the attacker can't create a form that looks like the real one. When you submit the fake form, the request sent to facebook.com won't look quite the same as the real form, so even though it receives the right cookie, the server can refuse to delete your account, knowing that you've probably been tricked.

0

Lets suppose that I have logged into www.facebook.com and have received a cookie from the above domain for session management etc. Now lets assume an attacker sends me an email to my gmail account and I navigate to the attackers website maybe at www.malicious-website.com and fill out some information in a form and hit the submit button.

So far, so good

The minute I hit the submit button the attacker makes a call to the facebook server to delete my facebook profile. My question is if the cookie that www.facebook.com sent to me is sent back to the server to delete my account eventhough I make a call from www.malicious-website.com and not www.facebook.com?

If that submit button tells your browser to submit the form to www.facebook.com, then your browser will happily do that (even if the page itself was received from somewhere else) and include all cookies related to the www.facebook.com domain in the request.

Note that the server of www.malicious-website.com will never see the request nor the cookies of facebook.

4
  • Okay the above makes sense but normally when I submit the form I would not be making a call to www.facebook.com right? I would be calling an endpoint defined with some other URL to delete my account? Then in this case how does the browser know to send my cookies to this particular endpoint? Jun 3, 2021 at 13:37
  • Cookies are associated with a domain name and the endpoint is also associated with a domain name. That is how the browser matches up which cookies to send in each request it makes. Jun 3, 2021 at 14:31
  • Thanks for your response. What if the domain of the applocation and its endpoints are different?Then in this case does the browser use the application domain or endpoint domain to send cookies? Jun 3, 2021 at 20:56
  • The browser uses the endpoint (request) domain to determine which cookies to send. Jun 4, 2021 at 6:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.