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?
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.
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.
