I am hesitant to post this, because from experience, smart people frequently misread or misunderstand it, but:
The easiest first-step solution is just to check the HTTP Referer field, and check it matches your domain.
Yes, this is easily faked by someone crafting their own HTTP requests. This is /not/ easily faked by someone causing your browser to make requests, though. And it provides very good coverage against the attack here.
If you do that, you then have to make sure your app doesn't have any redirector anywhere or anything that writes Location. Almost all apps do. This is because you can get the site to insert the right referrer.
for eg. if the URL of the attack request is (both of these are close to real life examples that work(ed))
usually the site will have a redirector on the login action, which takes the user back to the page that they were on after login, so you just use the attack URL as the redir URL
amazing how many login scripts still do the redirect even if the user is already logged in, or still do the redirect even if there is no real login
even if you do a javascript in-place login, there is usually a mobile version that has this pattern. I rarely meet a site that doesn't have a way to bounce between URLs and fake the referrer.
I guess the real conclusion is that these types of attacks are complicated and better understood fully than implying a single short solution - because the next response is always "but, if you do that, then" and so forth, like a matryoshka doll
Standard caveat with checking the Referer header: there is software out there which strips out the header in the name of privacy. If you use the Referer as a source of validation, you have to be prepared to deal with users of Norton Internet Security and other such products who will be unable to use your site. And you can't "fail open" by accepting any request without a referer, since there are plenty of techniques an attacker can use to remove the referer as well.
The easiest first-step solution is just to check the HTTP Referer field, and check it matches your domain.
Yes, this is easily faked by someone crafting their own HTTP requests. This is /not/ easily faked by someone causing your browser to make requests, though. And it provides very good coverage against the attack here.