One way that your web-site might be vulnerable to an attack is via Cross Site Request Forgery (CSRF or XSRF).
If you’ve ever been logged into a web-site - say Twitter for example - and you open a separate tab, then type in a twitter account, for example: https://www.twitter.com/paul_michaels, you’ll notice that when the site opens, it opens already logged in for you - which is very helpful. Imagine having to re-log-in every single time you wanted to view a tweet or a profile.
Okay, now imagine that, instead of typing that into the browser, you click the link above - try it! What - it didn’t take you to Twitter, but it took you to the home page of this blog? In fact, that’s exactly how a CSRF attack would work in practice. If you were already logged into that site, the link could have executed a CSRF attack.
Cross Site Request Forgery works on the premise that the victim of the attack is actually logged into a given website with valid credentials, and the attacker knows the exact format of a valid request. So, for example, I can take you to my Twitter profile, because the format of that is well known. Nobody, least of all Twitter themselves, want you to have to mess around logging in again.
But what about if you want to actually post a Tweet? Here’s the Url that gets called:
It’s a little difficult to demonstrate, because Twitter operates over HTTPS, so the traffic is encrypted, but the gist is that, even if I managed to create a site that copied this message exactly, the Tweet would not get created. Let’s have a look at replicating such an attack.
To Reproduce
Your first step is to create a really bog standard web site - the default MVC template will do. It might also help to demonstrate if you don’t use HTTPS.
Launch the web-site with F12 tools and make a given request. For example, click the “Contact” link on the default site. Make a note of the URL and the form data for the request:
Leave the app running and logged in.
Now Attack
Create a new web app with the following code:
[code language=“html”]