Live data from Hacker News

An XSS on Facebook via PNGs and Wonky Content Types

fin1te.net

1–10 of 48 posts

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

#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.

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

#3

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.

Well, he's a security specialist. And I feel he's figuring out new ways to attack. If you're not an attacker yourself, then I think you'll always lag behind.

I'm currently taking a security class and what I'm noticing is that I mistake the complicatedness for complexity but in essence most vulnerabilities and attacks have the same high level overview.

What I'm trying to say is: don't feel so bad, if you understood 25%, then you know more than you think. Perhaps you too are captured by the complicatedness of his post ;)

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

#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 will handle in different ways for different content types. Facebook's CDN still seems to allow serving files with the wrong (unvalidated) content type just by changing the file suffix in the URL.

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

#7

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.

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

#8

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.

[deleted]

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

#10

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.

The root problem is that something which shouldn't be HTML was sent back with the HTML mime type.

Usually this happens with content type sniffing (IE no MIME type is specified) but it leaves the door open to attacks like these. It changes the handler of the input from code designed to care about security (IE your upload handler code) to code designed to care about usability (MIME sniffing heuristics, or in this case the decompression/rendering library).

When this happens you usually get bad/unexpected results, but it makes it easy to figure out where you can stop caring about implementation details- when the user input leaves the area of the code designed to secure it!

Post reply on HN