2

A site I work on has a link that downloads and opens a PDF containing sensitive user data. The user's authentication cookie is checked serverside to ensure they have access to the data before generating and serving the PDF. However, I worried about the prospect of data being leaked by a CSRF attack. Because the PDF is opened by the user clicking an ordinary <a> link, most CSRF defences are not viable or incur security or UX tradeoffs. For example:

  • Adding a custom header with a CSRF token or double-submitting the authentication token via a header would require using an XHR via JavaScript to make the request for the PDF, and would break the user's ability to open the link in a new tab
  • Adding any kind of token to the link URL would make the URL less readable and user-friendly

Am I right to be worried about CSRF in this scenario, or is the same origin policy sufficient to let me just rely on cookie authentication for this endpoint without fear of leaking user data? The kind of attack I'm envisaging is one like the famous Gmail CSRF flaw that leaked your contacts list - I'm concerned that by provoking the download in a way that triggers some side effect in the browser, an attack site could make inferences about the content of the PDF, although I have no idea what the precise mechanism of such an attack would be.

Improve this question
2
  • While currently I'm inclined to think there is no threat-vector, if you are concerned it is also reasonable to ask: is there any reason why you can't just make it a POST request that requires CSRF validation? In the context of a normal web system, making those changes easy usually quite easy, and could probably be done in the time it took you to write this question. Security is always a cost/benefit analysis, and I suspect that the cost of implementing this security measure is small enough that the answer is "just do it"
    – Conor Mancone
    Oct 24, 2017 at 14:52
  • @ConorMancone see "Because the PDF is opened by the user clicking an ordinary <a> link most CSRF defences ... incur ... UX tradeoffs". If I make it a POST, the user can't bookmark the PDF itself to view or redownload again later in a single click. That's not the end of the world, but it's a tradeoff I'd prefer not to make if there's truly no security benefit to doing so.
    – Mark Amery
    Oct 24, 2017 at 14:55

1 Answer 1

Reset to default
1

A CSRF is a write-only operation from the perspective of the attacker. This means the attacker could initiate the download or view of the PDF inside the client browser, but he can not access the PDF just downloaded. The attacker might get some meta information though, like do some timing together with heuristics to defer if the download was successful or how long the PDF might be.

... famous Gmail CSRF flaw that leaked your contacts list

In this attack Gmail provided the contact list as Javascript which could be included in the attacker page and would be executed in the context of the attackers page. This is specific to script and can usually not be done with a PDF.

The attacker could of course try to include the PDF as script. One could actually construct a PDF which is both a valid PDF and valid Javascript and thus if the attacker has enough control over the generation of the PDF he might be able to use this technique to get access to the unknown part of the PDF.

Improve this answer
6
  • 1
    I'm aware that CSRF is usually write-only, but I cited the Gmail contacts attack precisely because it's an example of a CSRF attack that isn't write-only from the attacker's perspective. If the result of the request is such that you can cause it to trigger a side effect in the browser that you can observe (such as by pointing a <script> tag at the URL, in the Gmail case) then you can use CSRF as a way to read data. I know browsers have taken care to avoid any holes that would allow this for JSON (after the Gmail attack) and HTML responses, but I don't know about PDF.
    – Mark Amery
    Oct 24, 2017 at 14:09
  • (And note that it's easy to imagine unsafely-designed sites that would be seriously vulnerable to a read-based CSRF attack, like ones that template sensitive user data into JS scripts based upon the user authenticated by a cookie. What holes exist fundamentally depends upon the content type of the response, and I know very little about PDFs, which leaves me unable to evaluate whether there's a threat in my case.)
    – Mark Amery
    Oct 24, 2017 at 14:11
  • @MarkAmery: see edit
    – Steffen Ullrich
    Oct 24, 2017 at 14:20
  • "Gmail provided the contact list as Javascript" - well, that's a bit misleading - they provided it as a JSON array, which meant it was also valid JavaScript, and the "execution" of the JSON response as JavaScript could (in the browsers of the era) be made to reveal its content to the attacker by overriding the Array constructor prior to loading the contacts list.
    – Mark Amery
    Oct 24, 2017 at 14:24
  • "One could actually construct a PDF which is both a valid PDF and valid Javascript" - this sort of thing (or equivalent attacks using something other than a <script> tag, if they exist) is precisely what I'm asking about - but this answer, so far, doesn't go beyond speculating that such a thing could be possible, which is basically the depth of understanding I was already at when I asked the question.
    – Mark Amery
    Oct 24, 2017 at 14:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.