A web site allows upload of pdf/svg files, can we say it is vulnerable to Stored XSS?

Question

It is possible to have JavaScript code in pdf or svg files. I think JavaScript inside svg runs in almost all browsers and I think JavaScript inside pdf generally always runs in chrome.

So during a pentest we have seen that the website allows upload of pdf files with Javascript content, which runs inside the browser (the PDF is opened by the browser e.g. example.com/files/example.pdf). The uploaded files served from the main domain and not a third party service or CDN. The pdf is later reviewed by an admin of website. The payload will only trigger on google chrome browser. Can we say the website is vulnerable to stored xss in the report? If the payload only runs in chrome, does this affect CVSS score?

Also, what about svg file?

Answer 1

When risk assessing such a scenario, there are a few questions to ask:

• Are the uploaded files served from the main domain? If they're served from a different domain, that's usually a mitigation. This is why googleusercontent.com exists.
• Are Content-Disposition headers used? If they're served as attachments, they execute in a different origin. Trying alert(document.domain) as a payload is helpful.
• Can other users view the uploaded files? If not, this is just self-XSS, so reportable but low risk.
• Would other users naturally navigate to these files? If not, while this is technically stored XSS, user interaction is required so the risk profile looks more like reflective XSS.

I see the question has been updated to confirm:

• Uploaded files are on the main domain
• Other users (including admin) can view files
• Other users (including admin) naturally navigate to such files

If there are no Content-Disposition headers, then this appears to be exploitable as a stored XSS which allows escalation from low-privilege user to admin, which is almost certainly high-risk and possibly critical.

I believe this is exploitable for SVG files only. While JavaScript can execute in a PDF, it is restricted and effectively operating in a separate origin.

Payload only running in Chrome doesn't affect the risk rating, because Chrome is very widely used. If the exploit only worked in an old browser like IE 6, that would change the rating.

Answer 2

Not without further details.

Why? Well, your reasoning is vulnerable (pardon the pun) to a reductio ad absurdum.

By your definition, Google Drive / OneDrive / SharePoint / virtually any filesharing service is inherently vulnerable and insecure. So is e-mail.

Even more so than "just" XSS, they allow the sharing of arbitrary content, so they pose the risk of full remote code execution on any client machine! Wanna see my collection of photos and educating movies, pretty_girls.mp4.exe? I love you!

And, well, it is indeed the case. The use of such services is inherently insecure.

And yet it would be absurd to say that "e-mail has failed pentest on grounds that it allows sending almost arbitrary files as attachments". Well OK, nowadays e-mail mostly forbids .exe files as attachments (so I'll send you a password protected ZIP instead), but filesharing services are commonly used instead of e-mail if one really has to share an executable, so we should condemn all file-sharing services even more firmly than e-mail.

Problem is, they exist specially to provide that functionality. Demanding that a file-sharing service must stop providing file-sharing capabilites (or else security audit fails and consequences follow) kind of misses the point.