-1

I have been trying to learn about CSRF attacks. I know that it is uses the credentials from a session of a valid site and use that session information from another site to make requests to the valid site.

I want to know how anyone can access the session information (cookies of one domain are inaccessible from another domain). I want to know how the attacker is able to fool the server. I hope to see answers with some real life scenarios.

pramesh
  • 1,914
  • 1
  • 19
  • 30
  • To be clear: not everything you describe about CSRF is actually completely true, or at least you imply certain things (access to session information) that do not precisely happen. – Nanne Jul 14 '18 at 07:59
  • Without session info, how would another site make requests for such attacks? – pramesh Jul 14 '18 at 08:06
  • See my answer ;P (but basically: it tricks _you_ into doing the request, and you obviously have that session info) – Nanne Jul 14 '18 at 08:12
  • Thank you for answering a broad question like this. Really appreciate that. Actually I'm not quite satisfied with my level of understanding. I know what happens but don't know how does it happen. Like you said "but basically: it tricks you into doing the request, and you obviously have that session info", but how? – pramesh Jul 14 '18 at 08:16
  • Basically the same way you would do a request to your own api. E.G. with javascript. It is easy for me to make a page that literally does a post to the stackoverflow page in the background. Read up on ajax calls and javascript if you want to know more. That's why you do it on your own page (cross site) as I can inject as much javascript as I want there. This does seem to go into a quite long q/a session in the comments, i'm not really convinced that's a good way to attack this problem, and the fear of people voting to close. please take care not to go into that too much – Nanne Jul 14 '18 at 08:31
  • The only thing I am asking is how would a valid user's session be mimicked? – pramesh Jul 14 '18 at 09:08
  • @prms this is how browsers work. if you click on a link that leads to `www.facebook.com/some-page` it doesn't prompt you for user/password each time, right? the browser determines that the target domain has already a previously created cookie (from logging-in sometime previously) and sends that cookie along with the request. If it wouldn't work that way - you'd end up entering user+pass on each page refresh or any link to facebook you tried to open. Does that make sense now? – Arseny Levin Jul 14 '18 at 10:22
  • so if an attacker embeds an `iframe` or does AJAX request, the browser will already add your cookie. But if that request or `iframe` point to `www.facebook.com/delete-my-account.php` (fake example) then anyone could easily make you visit their website, which embeds a request to the `www.facebook.com/delete-my-account.php` page and effectively delete your facebook account. – Arseny Levin Jul 14 '18 at 10:23
  • "The only thing I am asking is how would a valid user's session be mimicked?" -- as i tried to explain: you _dont_ mimick. You trick the user into doing the request. Lets say I want to open your front door: it's hard to copy your key, but if i can have you turn the key yourself, i don't need the key. With requests i can have you open the door, walk in, get the tv and give it to me, without you noticing. So there is no mimick, copy, access, anything. I just trick you to do it yourself. – Nanne Jul 14 '18 at 12:12

1 Answers1

0

The basic concept can be explained simple enough. While the complete story is somewhat complicated (and probably the reason you're getting voted to close as 'too broad'), I think a quick example might help

You have an account on stackoverflow, where you can upvote answers (e.g. this one). I could make a website that does a call to stackoverflow to upvote this answer in the background. So i'd link you to that site and then you automatically upvote me. That is bad!

So what just happened would be that the call (the request) was faked by me (forged) from another page (cross site).

Stackoverflow must take precautions to check that each call to the upvote-api is actually done by you from their own site, not sneakily by me (trough you).

The simplest way this can go wrong is if the upvote button was just an api post to https://stackoverflow.com/api/upvote/{id}. If you are logged in and I have you post to that api from javascript in the background then you'd upvote and never be any wiser to it. Any good implementation tries to avoid this by doing any of the well known anti-csrf tricks (tokens for instance), but going into that would put us quite firmly into the 'too broad' category :D

Nanne
  • 64,065
  • 16
  • 119
  • 163