Hacker News new | past | comments | ask | show | jobs | submit login

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.




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


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


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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: