3) Visit My XSRF Page

4) Go Back to BlackJack

You’ll notice that you have lots more cards than before. This is because we use a GET parameter to determine if the user is going to hit or stand, and this makes it vulnerable to XSRF attacks. If you’ll look at the HTML source from the page you visited above, you’ll see a lot of this:

When the browser sees this <img> element, it sends an HTTP request for that resource, with no assurance it really is an image! As you can see above though, the URL is in fact a request to "Hit" in our Black Jack game.

The technical way of expressing this problem is that our server does not ensure that GET requests are safe and idempotent.

Using POST Requests

This problem can be solved by using POST requests instead of GET requests to modify the server state.

A POST request has a request body where information – such as a query string or an uploaded file – can be included. A POST request is also not required to be idempotent according to HTTP specification.

POST Requests in HTML

The bad news is that in HTML, you can’t use a hyperlink to send a POST request. You have to use a form.

The good news is that all you need to do to send a POST request using an HTML form is change the "method" attribute to "POST".

Other environment variables we haven’t looked at yet include ‘CONTENT_TYPE’ and ‘CONTENT_LENGTH’ which tell us the formatting and the length of the request body, repectively. These are used in conjunction with the STDIN filehandle to read the request body:

In Summary

Never, ever, ever modify server state with a GET request! Client applications (like browsers, or web crawlers like the ‘GoogleBot’) will assume that it is safe to send a GET request any time for any reason to any URL on your server. Again, an XSRF is perhaps the second most common attack made against web sites, and – like the Cross Site Scripting Attack – it is fairly easy to prevent.

Where XSS vulnerabilities are a sign of negligence or incompetence on the part of the developer, XSRF vulnerabilities are the mark of a lazy, naive web developer.