2

In our application the user is allowed to download a file by pressing a context menu button. At the moment we achieve this functionality by creating and appending an iframe to the dom with a src attribute that points to the file's location on the server.

We recently added CSRF protection to the application and as you can guess issues arose with the file download issue. This is easily solvable by providing the csrf token as a query param but ultimately defeats the purpose of the protection method and exposes the token to listeners.

Is there a way to trigger a file download (i.e. after pressing the "Download File" button trigger the native Save as... dialog) using a request with configurable Http Headers ?

Note that even though the data itself will not be exposed to the attacker's site we also want to avoid having multiple such heavy requests be sent to the server by a malicious page, thus needing the CSRF protection.

Finally please keep in mind that we must remain compatible with up to Internet Explorer 10 which might restrict our options (for example download attribute in anchor elements does not work there).

PentaKon
  • 4,139
  • 5
  • 43
  • 80

1 Answers1

1

Addressing your question requirements individually...

1) "Is there a way to trigger a file download using a request with configurable Http Headers?"

  • First, add protection to prevent malicious external source vulnerabilities by implementing the Origin HTTP Header. This restricts access to only internal requests & other trusted sources, leaving you in control. See OWASP's recommendation here:

  • Second, issue an HTTPOnly cookie from your website. As long as the file is being served from the same host as the page that hosts the iframe then the iframe will automatically pass the cookie back to the server. The value inside the cookie should be the same as CSRF token. This is in addition to the CSRF token being passed currently. Also it makes no difference if the current token token is passed via URL or HTTP headers.

  • Lastly, on the server side verify that both the token from the URL/Header is equal to the HTTPOnly cookie. This prevents even cases of XSS attacks within the website.

2) "want to avoid having multiple such heavy requests"

This sounds like you need a DDOS countermeasure more than a CSRF countermeasure for this requirement. The CSRF countermeasure in the previous point ensures that the download request is valid but CSRF is not concerned with repeating multiple valid requests. For example, you would have this same issue if an attacker implemented an AutoIt script that repeatedly clicked the download button.

There are multiple layers to implement countermeasures:

3) "must remain compatible with up to Internet Explorer 10"

The recommendations above are limited in some versions of IE:

NOTE: The implementation details are left off because it is dependent on your server side stack.