Live data from Hacker News

An XSS on Facebook via PNGs and Wonky Content Types

fin1te.net

41–48 of 48 posts

Re: An XSS on Facebook via PNGs and Wonky Content Types

#41

Earlier quoted context omitted.

> Anyway, CSP clearly isn't useless... but try deploying it on your average Wordpress blog sometime. What issues have you found with this?

Not OP, but my guess is random plugins stop working with strict (i.e. secure) policies, if they weren't written with CSP in mind.

Its not really plugins. The vast majority of wordpress themes out there come with inline css, inline javascript, and prebaked dependencies on things like jquery and google fonts hosted on 3rd party CDNs.

Re: An XSS on Facebook via PNGs and Wonky Content Types

#42
Pretty clever, but I'm wondering how this would be exploited. To insert an XSS attack on facebook.com, he would have to be able to change the extension in url in the facebook page of an uploaded image to .html, right? Don't see a way of doing that.

Am I missing something, or the attack assumes you can convince a victim to go to the given URL through other means? Like spreading through IM, E-mail...

Re: An XSS on Facebook via PNGs and Wonky Content Types

#43

Pretty clever, but I'm wondering how this would be exploited. To insert an XSS attack on facebook.com, he would have to be able to change the extension in url in the facebook page of an uploaded image to .html, right? Don't see a way of doing that. Am I missing something, or the attack assumes you can convince a victim to go to the given URL through other means? Like spreading through IM, E-mail...

After reading the comments here, it seems like the attack would indeed assume you spread the alternative URL with the .html extension through other means like IM, ...

Re: An XSS on Facebook via PNGs and Wonky Content Types

#44
post #35
post #29

Hmm, I wonder if there is anything interesting you could do by creating a Service Worker for the CDN domain. It seems that the CDN will serve arbitrary files with a text/javascript Content-Type, which is the requirement to set one up. Once created, AFAIK, such a worker remains attached to the domain until an occasional attempt by the browser to refresh it fails, and it can intercept and modify any requests from webpa…

ServiceWorkers are scoped to the basename of the path they are served from, so you could only intercept a small subset of all possible CDN URLs. In the example, this would be resources under `/hads-ak-xat1/t45.1600-2/`. But you probably can't create a ServiceWorker here anyways as you need a route that returns valid Javascript of your choosing with a Content-Type `text/javascript`. Usually when I've seen an opportuni…

The default scope is the basename, but you can customize it, can't you?

As I said, the text/javascript Content-Type is another one the CDN is willing to serve if you change the extension. I'm silly and didn't think of the fact that unlike HTML, a JS file can't be random binary garbage with a payload embedded somewhere in the middle. However, I am not sure that some allowed image format doesn't allow putting, say, // close enough to the beginning of the file that it will work. It seems like it might be possible with the JPEG header, but of course it depends on the post processing done. (Or maybe there is some way to upload non-images?)

Re: An XSS on Facebook via PNGs and Wonky Content Types

#45

Pretty clever, but I'm wondering how this would be exploited. To insert an XSS attack on facebook.com, he would have to be able to change the extension in url in the facebook page of an uploaded image to .html, right? Don't see a way of doing that. Am I missing something, or the attack assumes you can convince a victim to go to the given URL through other means? Like spreading through IM, E-mail...

There's multiple way to spread it, you put that url inside an iframe and then you could upload it on some ad network, you could build some viral content somewhere and let it spread that way. It's pretty easy to spread an XSS.

Re: An XSS on Facebook via PNGs and Wonky Content Types

#46
post #44
post #35

Earlier quoted context omitted.

ServiceWorkers are scoped to the basename of the path they are served from, so you could only intercept a small subset of all possible CDN URLs. In the example, this would be resources under `/hads-ak-xat1/t45.1600-2/`. But you probably can't create a ServiceWorker here anyways as you need a route that returns valid Javascript of your choosing with a Content-Type `text/javascript`. Usually when I've seen an opportuni…

The default scope is the basename, but you can customize it, can't you? As I said, the text/javascript Content-Type is another one the CDN is willing to serve if you change the extension. I'm silly and didn't think of the fact that unlike HTML, a JS file can't be random binary garbage with a payload embedded somewhere in the middle. However, I am not sure that some allowed image format doesn't allow putting, say, //…

I seem to remember trying this (passing {scope:'/'} in the register call), and it doesn't work. Some googling seems to agree:

"Service Workers are restricted by the path of the Service Worker script unless the Service-Worker-Scope: header is set" [1]

I do wish the spec required a 'Content-type: text/service-worker', as that would effectively eliminate accidental ServiceWorkers as a threat.

[1] https://infrequently.org/2014/12/psa-service-workers-are-com...

Re: An XSS on Facebook via PNGs and Wonky Content Types

#47
post #46
post #44

Earlier quoted context omitted.

The default scope is the basename, but you can customize it, can't you? As I said, the text/javascript Content-Type is another one the CDN is willing to serve if you change the extension. I'm silly and didn't think of the fact that unlike HTML, a JS file can't be random binary garbage with a payload embedded somewhere in the middle. However, I am not sure that some allowed image format doesn't allow putting, say, //…

I seem to remember trying this (passing {scope:'/'} in the register call), and it doesn't work. Some googling seems to agree: "Service Workers are restricted by the path of the Service Worker script unless the Service-Worker-Scope: header is set" [1] I do wish the spec required a 'Content-type: text/service-worker', as that would effectively eliminate accidental ServiceWorkers as a threat. [1] https://infrequently.or…

Hmm; I don't see that in the current spec [1], and that link is pretty old. I should test it.

https://slightlyoff.github.io/ServiceWorker/spec/service_wor...

Re: An XSS on Facebook via PNGs and Wonky Content Types

#48

Man, I work as a frontend engineer at one of the big tech companies and I understood like 25% of this post. And that's not meant to be a criticism, I'm just reflecting on my total ignorance of most security vulnerabilities. I know about and having implemented some measures against XSS / CSRF, but it's clear there are dozens of attack approaches I'm not even aware of. I feel like I have some homework to do.

OWASP can be a good guide https://www.owasp.org/index.php/Top_10_2013-Top_10
Post reply on HN