Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An XSS on Facebook via PNGs and Wonky Content Types

fin1te.net

Post reply on HN
Print view View original

21–30 of 48 posts

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

#21

Post by deathanatos »

viraptor wrote: post #18
PeCaN wrote: post #15

That is incredibly clever, particularly exploiting DEFLATE to generate text. I would've never thought of that.

They didn't use DEFLATE to generate the text. They used a known text and prepended garbage to it until it DEFLATEd correctly (to any result). Small difference, but still.

The author seems aware that it is possible, however:

> Rather than trying to create this by hand, I used a brute-force solution (I’m sure there are much better ways, but I wanted to whip up a script and leave it running):

He just didn't want to learn DEFLATE right then, right there. He got the same result.

FWIW, I don't think this is actually hard. DEFLATE has a small header that tells you want type of compressed data follows; one of the types is "literally, this data" which is up to 64KiB long. (i.e., a plenty long enough string to get the job done.)

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

#22

Post by nh2 »

Doesn't this XSS constitute a complete compromise of all Facebook user data, globally?

(Assuming it had been found by a "bad guy", instead of a white-hat researcher.)

Because:

* He could execute arbitrary code in the browser of any user that views his picture

* Including uploading all private photos and chats of that user to somewhere else

* Or changing their password (assuming 2FA is not used)

* He could have propagated this exploit to all Facebook users by simply uploading his XSS picture into his victim's profile, and from there into second-degree victims, and so on? According to the "6 degrees of separation" theory, this would have been very fast

Or am I missing something?

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

#23

Post by update »

richdougherty wrote: post #5

Main points for me: 1. Don't serve user supplied content from a subdomain of your main site. Facebook fixed this by removing the redirect from photo.facebook.com to their CDN, so now user content comes from *.akamaihd.net. 2. If a user uploads a PNG (or whatever), and you've validated it for that content type, don't serve it from your servers with a different content type. Clever users can make files that browsers wi…

> Facebook's CDN still seems to allow serving files with the wrong (unvalidated) content type just by changing the file suffix in the URL.

Is this common practice amongst websites? seems like a weird config to have enabled.

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

#24

Post by grrowl »

update wrote: post #23
richdougherty wrote: post #5

Main points for me: 1. Don't serve user supplied content from a subdomain of your main site. Facebook fixed this by removing the redirect from photo.facebook.com to their CDN, so now user content comes from *.akamaihd.net. 2. If a user uploads a PNG (or whatever), and you've validated it for that content type, don't serve it from your servers with a different content type. Clever users can make files that browsers wi…

> Facebook's CDN still seems to allow serving files with the wrong (unvalidated) content type just by changing the file suffix in the URL. Is this common practice amongst websites? seems like a weird config to have enabled.

It is weird. I suppose as a result of storing file content by hash only (without extension), then determining the Content-Type header based on the user-supplied extension. Unless they're storing the original filename, they'll have to run through the binary data to determine file type.

Crucially though, is they removed the DNS forward to the CDN. Which means they're actually storing .html files on those CDN servers. For ads, presumably, but it seems terribly silly to be storing .html files there at all.

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

#25

Post by grrowl »

nh2 wrote: post #22

Doesn't this XSS constitute a complete compromise of all Facebook user data, globally? (Assuming it had been found by a "bad guy", instead of a white-hat researcher.) Because: * He could execute arbitrary code in the browser of any user that views his picture * Including uploading all private photos and chats of that user to somewhere else * Or changing their password (assuming 2FA is not used) * He could have propag…

He couldn't have just "uploaded" images to a page, since facebook would output the original path (B1GL0N6H45H.png), where this relies on the .html extension. Easy enough to link people through Messenger or another site to that page, though. The core vector is the fact it's served off the photos.facebook.com domain.

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

#26

Post by krapp »

richdougherty wrote: post #5

Main points for me: 1. Don't serve user supplied content from a subdomain of your main site. Facebook fixed this by removing the redirect from photo.facebook.com to their CDN, so now user content comes from *.akamaihd.net. 2. If a user uploads a PNG (or whatever), and you've validated it for that content type, don't serve it from your servers with a different content type. Clever users can make files that browsers wi…

> If a user uploads a PNG (or whatever), and you've validated it for that content type, don't serve it from your servers with a different content type.

I can see changing the suffix for image types and converting the image on the fly - I don't know why that would be useful, but I can imagine someone doing that. But at the very least don't allow sending something you know to be an image with non-image headers.

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

#27

Post by baby »

richdougherty wrote: post #5

Main points for me: 1. Don't serve user supplied content from a subdomain of your main site. Facebook fixed this by removing the redirect from photo.facebook.com to their CDN, so now user content comes from *.akamaihd.net. 2. If a user uploads a PNG (or whatever), and you've validated it for that content type, don't serve it from your servers with a different content type. Clever users can make files that browsers wi…

> 1. Don't serve user supplied content from a subdomain of your main site. Facebook fixed this by removing the redirect from photo.facebook.com to their CDN, so now user content comes from *.akamaihd.net.

I don't see that as an issue. As long as you don't allow for wildcard extensions on your server it won't return a wrong content-type in this kind of situation. I wonder why it's even possible that you can change the .jpg to .html :| I'm pretty sure this is disabled by default in apache.

> don't serve it from your servers with a different content type.

so yeah, the problem of the content-type comes from the fact that you can manipulate the extension as you wish once uploaded.

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

#28

Post by danielhlockard »

superswordfish wrote: post #7
ottertown wrote: post #2

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.

It's interesting that you think working for a big tech company makes you especially qualified (or else you would not have mentioned it here). By working for a smaller company, you'd have to know these things or else face a world of pwnage. > I feel like I have some homework to do. Start with X-Frame-Options and HttpOnly cookies.

And Secure, if you're using HTTPS (which you should be)

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

#29

Post by comex »

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 webpages on its origin, as well as navigation there. But it doesn't affect requests to that origin from other origins, like the typical from facebook.com, so it won't be able to do much.

It seems that you click "download" on Facebook images, you'll get redirected to a CDN URL. So there's that. You could see what images the user is trying to download and edit them in flight... not a big deal, but it's something.

Post reply on HN