Live data from Hacker News

How to harvest Facebook profiles from emails without logging in

petewarden.typepad.com

1–10 of 15 posts

Re: How to harvest Facebook profiles from emails without logging in

#3

Facebook's approach to images seems broken security-wise all around. You can also get to non-public images if you know the URL of the jpg--- linking to the image page won't work, but a direct link to the JPG will happily serve itself up.

This is notoriously hard problem to solve if you still want a traditional web server serving out static assets (which is the fastest way to do so). The only way I've seen to serve static content in an authenticated fashion is to serve it out of the application itself using the appropriate headers. I'm curious how others have solved this though...

Re: How to harvest Facebook profiles from emails without logging in

#4
post #3

Facebook's approach to images seems broken security-wise all around. You can also get to non-public images if you know the URL of the jpg--- linking to the image page won't work, but a direct link to the JPG will happily serve itself up.

This is notoriously hard problem to solve if you still want a traditional web server serving out static assets (which is the fastest way to do so). The only way I've seen to serve static content in an authenticated fashion is to serve it out of the application itself using the appropriate headers. I'm curious how others have solved this though...

It's not foolproof, but I think one common way is for the static-content server to check for an appropriate authentication cookie. In Facebook's case, an additional complication is that they serve lots of the static content off Akamai, so any authentication would have to be coordinated.

Re: How to harvest Facebook profiles from emails without logging in

#5
post #3

Earlier quoted context omitted.

This is notoriously hard problem to solve if you still want a traditional web server serving out static assets (which is the fastest way to do so). The only way I've seen to serve static content in an authenticated fashion is to serve it out of the application itself using the appropriate headers. I'm curious how others have solved this though...

It's not foolproof, but I think one common way is for the static-content server to check for an appropriate authentication cookie. In Facebook's case, an additional complication is that they serve lots of the static content off Akamai, so any authentication would have to be coordinated.

The cookie slows down the things a bit. I've never had such problem but what about complete randomization of static URLs, so they are not easily findable?

If the leaks are the issue, one might want to change the names, or just filesystem symlinks, periodically.

Re: How to harvest Facebook profiles from emails without logging in

#6
post #5

Earlier quoted context omitted.

It's not foolproof, but I think one common way is for the static-content server to check for an appropriate authentication cookie. In Facebook's case, an additional complication is that they serve lots of the static content off Akamai, so any authentication would have to be coordinated.

The cookie slows down the things a bit. I've never had such problem but what about complete randomization of static URLs, so they are not easily findable? If the leaks are the issue, one might want to change the names, or just filesystem symlinks, periodically.

couldn't they just solve it by serving up an image with a hash of the facebook uid as the filename?

Re: How to harvest Facebook profiles from emails without logging in

#7
post #3

Earlier quoted context omitted.

This is notoriously hard problem to solve if you still want a traditional web server serving out static assets (which is the fastest way to do so). The only way I've seen to serve static content in an authenticated fashion is to serve it out of the application itself using the appropriate headers. I'm curious how others have solved this though...

It's not foolproof, but I think one common way is for the static-content server to check for an appropriate authentication cookie. In Facebook's case, an additional complication is that they serve lots of the static content off Akamai, so any authentication would have to be coordinated.

Plus the domain name is completely different: all static content is served from subdomains of .fbcdn.net (and frequently of .ak.fbcdn.net).

Re: How to harvest Facebook profiles from emails without logging in

#8
post #3

Facebook's approach to images seems broken security-wise all around. You can also get to non-public images if you know the URL of the jpg--- linking to the image page won't work, but a direct link to the JPG will happily serve itself up.

This is notoriously hard problem to solve if you still want a traditional web server serving out static assets (which is the fastest way to do so). The only way I've seen to serve static content in an authenticated fashion is to serve it out of the application itself using the appropriate headers. I'm curious how others have solved this though...

nginx has a feature that's perfect for this kind of thing: x-accel-redirect (also available in other web servers):

http://kovyrin.net/2006/11/01/nginx-x-accel-redirect-php-rai...

The nginx team added another feature that's even more efficient for this recently (doesn't require a dynamic piece of code execution for each hit) - a module that creates "secure links" for protecting static resources:

http://wiki.nginx.org/NginxHttpSecureLinkModule

(I think this feature would be a lot more useful if you could create links that expire after a certain amount of time).

Amazon S3 has a similar feature, which they call "query string authentication": http://docs.amazonwebservices.com/AmazonS3/latest/dev/index.... - again, you can generate a link to a static resource which is signed with your secret key and will only work for a specific amount of time. Last I saw, that's how Basecamp deals with download links for private files.

Re: How to harvest Facebook profiles from emails without logging in

#10
post #8
post #3

Earlier quoted context omitted.

This is notoriously hard problem to solve if you still want a traditional web server serving out static assets (which is the fastest way to do so). The only way I've seen to serve static content in an authenticated fashion is to serve it out of the application itself using the appropriate headers. I'm curious how others have solved this though...

nginx has a feature that's perfect for this kind of thing: x-accel-redirect (also available in other web servers): http://kovyrin.net/2006/11/01/nginx-x-accel-redirect-php-rai... The nginx team added another feature that's even more efficient for this recently (doesn't require a dynamic piece of code execution for each hit) - a module that creates "secure links" for protecting static resources: http://wiki.nginx.org/…

lighty and apache has x-sendfiles
Post reply on HN