XSS in fallback link if url is controllable by attacker

[maple3142]

Here:

PDFObject/pdfobject.js

Lines 324 to 329 in 2c0bbd9

	if(fallbackLink){
	fallbackHTML = (typeof fallbackLink === "string") ? fallbackLink : fallbackHTML_default;
	targetNode.innerHTML = fallbackHTML.replace(/\[url\]/g, url);
	}

It only works on devices without pdf support like mobile devices.

[pipwerks]

Thanks, but JS utilities like PDFObject can't validate URLs for safety. This is the responsibility of the developer using PDFObject.

[maple3142]

But the problem is that it is dangerous by default as the XSS is on the default fallbackHTML_default, and there is no way to wrap a html sanitizer (e.g. DOMPurify) around that currently as it just insert the HTML to the target element. I don't think this can be easily fixed without changing the API though.

[pipwerks]

I see, you're referring to an attacker rewriting the fallback URL in PDFObject. I initially thought you were referring to the destination site being malicious/compromised.

In the scenario you describe, PDFObject is not a point of entry into the DOM. The only way an attacker can modify the PDFObject fallback URL (or HTML) is if they already have the ability to control JS on the page. If this is the case, they can already do whatever they want, regardless of PDFObject.

If you disagree and can provide a demonstration/POC I'd be happy to review.

Thanks

[maple3142]

Try this on a mobile device (or use devtools to enable mobile mode):

https://gh.maple3142.workers.dev/maple3142/c6e29fd852c0774fb622493710beda4a/raw/ea3c64992d6b18a8f8acbaf2416e4c7df114a1c6/test.html?url=%27%3E%3Cimg%20src=x:%20onerror=alert(document.domain)%3E

HTML code:

<script src="https://cdnjs.cloudflare.com/ajax/libs/pdfobject/2.2.12/pdfobject.min.js" integrity="sha512-lDL6DD6x4foKuSTkRUKIMQJAoisDeojVPXknggl4fZWMr2/M/hMiKLs6sqUvxP/T2zXdrDMbLJ0/ru8QSZrnoQ==" crossorigin="anonymous" referrerpolicy="no-referrer"></script>
<div id="pdf-display"></div>
<script>
const url = new URL(location.href).searchParams.get('url')
PDFObject.embed(url, "#pdf-display");
</script>

I think it is reasonable to not have XSS in a simple, obvious PDF viewer usecase. Even pdf.js have a similar pdf viewer here.

[pipwerks]

Your example creates the vulnerability by utilizing a querystring parameter to populate PDFObject's options. This is not a XSS vulnerability on the part of PDFObject.