Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I was searching around about CSRF attacks and I am thinking about the "random form token" prevention concept.

Let's say every form has a "hidden token" inside and the server checks the token before anything else. Now let's say there is a form http://myWebsite.e.x/acccount/edit and it's supposed to be submitted.

The attacker can create an iFrame of this form to his website (token generated), hide it and then submit it using JavaScript (and victim's cookies).

What am I missing here?

share|improve this question
    
I would suggest reading this for better understanding on the issue owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29 –  NorthPole Feb 21 at 15:02

2 Answers 2

up vote 5 down vote accepted

You're missing the same-origin policy. In order for your scenario to work, the attackers needs JavaScript code from his page to be able to access the iFrame. That's not possible.

Remember this rule: A window/frame can not talk to another window/frame without the target window/frame allowing it (by the use of messaging, for example).

In your case, the target frame won't allow it. So the attacker won't be able be able to access the iFrame's DOM to grab the token. He can't programmatically submit forms or send requests through the iFrame either.

share|improve this answer
    
Good answer but are you saying that the IFrame can access the DOM of the parent cross domain? I'm pretty sure that is not possible (apart from the location object). –  SilverlightFox Feb 22 at 14:31
    
@SilverlightFox You're indeed correct, that slipped my mind. I've fixed the answer. Thanks a lot for bringing this to my attention. –  Adnan Feb 22 at 15:32
    
Great. I feel picky now, as you cannot do it with Access-Control-Allow-Origin either :). –  SilverlightFox Feb 22 at 15:38

When the user visits the legitimate site, the server generates a random token and embeds it in the form. For the server to accept a form submission, the valid token must be submitted along with the rest of the data.

When the attacker builds the fake form on the malicious site, they have no knowledge of this token and can't insert it. This results in the target server rejecting the form submission.

The attacker would not use an iframe to load up the genuine form. They create and submit their own form which inherits the identity of the user. The token allows the target server to know the submission is not from a legitimate form.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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