Cross-Site Request Forgery

Cross-site request forgery (XSRF) involves using credentials stored in the browser to make authenticated requests to web services. Often combined with an XSS attack, these types of attacks allow malicious JavaScript to impersonate you, performing actions without your knowledge or consent.

This attack requires a web service to store authentication tokens in the browser, either in browser cookies or in the application layer. How these tokens are accessed depends on how they’re stored. Cookie-based tokens are simply added to any matching outgoing request, so all an attacker has to do is make a valid request, and the authentication information will be added by the browser. Attacks against application-layer tokens require that the attacker either know where the tokens are stored or know how to use JavaScript to make a request that will include those tokens.

XSRF Without Javascript

While JavaScript seems to be an obvious choice for an XSRF attack, sometimes it’s possible to do without it. Although they don’t conform with the conventions of HTTP, some web services provide APIs that allow you to perform requests that have side effects using HTTP GET requests. In these cases, injecting an <img> or other resource tag onto the page is enough to make the request.

It’s also possible to create an HTTP POST request without JavaScript. By injecting a hidden HTML form onto the page, you can trick the browser into sending a POST request containing that form data. This requires that the service accept form-encoded data in the POST body.

In our application, any malicious code injected into our app could easily perform an XSRF attack by interacting with the AWS JavaScript SDK, our application, or both. Thankfully, the AWS APIs we use in our app use proper HTTP semantics and require a POST to perform any operation that changes data. You should take care to follow these conventions when building custom web services as well. Creating a service that changes data in response to an HTTP GET can open your application up to XSRF attacks.

Cross-Origin Requests and the Same-Origin Policy

One thing that can prevent basic XSRF attacks is the same-origin policy, enforced by all modern browsers. This policy restricts access to resources that come from a different origin on the web. The origin is a combination of the URI^[84] scheme, the hostname, and the port number. For example, all of these URLs refer to different origins, even though they might actually all connect to the same server:

1. http://example.com

2. http://www.example.com

3. https://www.example.com

4. http://www.example.com:8080

Not only do browsers use the same-origin policy to segregate cookies from different sites, but by default they also prevent HTTP requests with side effects (POST, PUT, and DELETE) from being sent to sites with different origins than the one of the page currently loaded. That means that if you load an app using the URL http://learnjs.benrady.com and you try to make a POST request to http://www.google.com, the browser will block that request.

Back in Chapter 4, ​Identity as a Service with Amazon Cognito​, when we created an application in the Google Developers Console, we had to specify the origins that were allowed to access the Google API on behalf of our application. By requiring that we specify these origins, Google helps prevent XSRF attacks in our application.

Now that we’ve seen how our application can fall victim to some protocol and application-level attacks, let’s drop down a couple of layers and look at how the security of the network transport affects our application. While you might not deal with this layer of technology often, understanding how to send data securely and privately over the Internet is an essential part of building secure web applications.