5 ms·

Widgetjacking: Why more social widgets mean less secure Wi-Fi

17 points by byoogle 14y ago

ajanuary 14y ago
Off topic, but why would you put "html { -webkit-text-size-adjust: none }" in your CSS? Not everyone has great eyesight, and I happen to like being able to zoom in and actually read.
- byoogle 14y ago
  IIRC, the default font sizing on iOS was weird without that rule. But I didn't realize we broke zooming. I did accessibility work in my last job, so I feel pretty dumb now. Will fix.
  - ajanuary 14y ago
    Glad to hear it wasn't intentional :D
patio11 14y ago
"Widgets are a security problem for the embedding site" is old news (tptacek has mentioned it more than a few times) but "Widgets mean that certain high-value targets like gmail can get compromised on virtually any Internet session" is an obvious-in-retrospect-but-otherwise-new insight to me. That's significant enough that I would be thinking of some way to separate cookie/authentication architectures for high-value sites for on-site and off-site content. (e.g. You would give the cookie asserting identity as X associated with Facebook comment boxes on 3rd party sites sufficient authorization to post comments but not sufficient authorization to view the Facebook site proper, and otherwise track it in semi-parallel to the main FB cookies, expiring them at the same time, etc etc.) Edit to add: While the "Only allow embedding over HTTPS" is attractive from a security perspective, this is one of those occasions where the business has needs which are distinct from and difficult to subordinate to maximizing security. There's very little difference between that remediation and "Turn off Facebook Likes web-wide, please." and that proposal (presumably) is an auto-fail at FB.
- byoogle 14y ago
  I think for almost all cases, there are simpler solutions: * Use secure cookies (set the secure bit so these cookies are only sent over HTTPS) for authenticating on your HTTPS site * Use a separate domain for embeds ("youtube-widgets.com" instead of "youtube.com" on third-party sites)
  - mcherm 14y ago
    The simplest solution of all is probably to use HTTPS for _ALL_ connections, whether to widgets or to your site. The cost (in encryption overhead) is trivial* and the value is never having to worry about things like this. * - unless it prevents you from using a CDN to distribute images and other static-but-large content. Which it shouldn't, if you do it right.
  - patio11 14y ago
    youtube-widgets.com still may, depending on product requirements, need to have some notion of your Youtube account credentials. This would, in turn, potentially make youtube-widgets.com into a back door into your Gmail if somebody wasn't careful. (grumble grumble The decision to merge the Youtube and all-powerful-Google* logins was about my least favorite login decision since OpenID $INSERT_HYPERBOLIC_SOUNDING_REFERENCES_TO_BAD_MYTHICAL_EVENTS_ WHICH_WHILE_BAD_ARE_STILL_NOT_AS_BAD_AS_OPENID.
charlieirish 14y ago
This appears to be similar to Ghostery[1] except that Ghostery just blocks all these beacons/tracking scripts/social media scripts and has much more coverage. [1] https://chrome.google.com/webstore/detail/ghostery/mlomiejdfkolichcflejclcbmpeaniij https://chrome.google.com/webstore/detail/ghostery/mlomiejdf...
- byoogle 14y ago
  Disconnect blocks stuff, too. But if you unblock something (e.g., to see comments on TechCrunch), you shouldn't have to be exposed to session hijacking. That's why we added this feature.

17 points by byoogle 14y ago

Off topic, but why would you put "html { -webkit-text-size-adjust: none }" in your CSS? Not everyone has great eyesight, and I happen to like being able to zoom in and actually read.

byoogle 14y ago
IIRC, the default font sizing on iOS was weird without that rule. But I didn't realize we broke zooming. I did accessibility work in my last job, so I feel pretty dumb now. Will fix.
- ajanuary 14y ago
  Glad to hear it wasn't intentional :D

patio11 14y ago

"Widgets are a security problem for the embedding site" is old news (tptacek has mentioned it more than a few times) but "Widgets mean that certain high-value targets like gmail can get compromised on virtually any Internet session" is an obvious-in-retrospect-but-otherwise-new insight to me. That's significant enough that I would be thinking of some way to separate cookie/authentication architectures for high-value sites for on-site and off-site content. (e.g. You would give the cookie asserting identity as X associated with Facebook comment boxes on 3rd party sites sufficient authorization to post comments but not sufficient authorization to view the Facebook site proper, and otherwise track it in semi-parallel to the main FB cookies, expiring them at the same time, etc etc.) Edit to add: While the "Only allow embedding over HTTPS" is attractive from a security perspective, this is one of those occasions where the business has needs which are distinct from and difficult to subordinate to maximizing security. There's very little difference between that remediation and "Turn off Facebook Likes web-wide, please." and that proposal (presumably) is an auto-fail at FB.

byoogle 14y ago
I think for almost all cases, there are simpler solutions: * Use secure cookies (set the secure bit so these cookies are only sent over HTTPS) for authenticating on your HTTPS site * Use a separate domain for embeds ("youtube-widgets.com" instead of "youtube.com" on third-party sites)
- mcherm 14y ago
  The simplest solution of all is probably to use HTTPS for _ALL_ connections, whether to widgets or to your site. The cost (in encryption overhead) is trivial* and the value is never having to worry about things like this. * - unless it prevents you from using a CDN to distribute images and other static-but-large content. Which it shouldn't, if you do it right.
- patio11 14y ago
  youtube-widgets.com still may, depending on product requirements, need to have some notion of your Youtube account credentials. This would, in turn, potentially make youtube-widgets.com into a back door into your Gmail if somebody wasn't careful. (grumble grumble The decision to merge the Youtube and all-powerful-Google* logins was about my least favorite login decision since OpenID $INSERT_HYPERBOLIC_SOUNDING_REFERENCES_TO_BAD_MYTHICAL_EVENTS_ WHICH_WHILE_BAD_ARE_STILL_NOT_AS_BAD_AS_OPENID.

charlieirish 14y ago

This appears to be similar to Ghostery[1] except that Ghostery just blocks all these beacons/tracking scripts/social media scripts and has much more coverage. [1] https://chrome.google.com/webstore/detail/ghostery/mlomiejdfkolichcflejclcbmpeaniij https://chrome.google.com/webstore/detail/ghostery/mlomiejdf...

byoogle 14y ago
Disconnect blocks stuff, too. But if you unblock something (e.g., to see comments on TechCrunch), you shouldn't have to be exposed to session hijacking. That's why we added this feature.