5 ms·

what i really want is an indicator of how many 3rd party https domains have dumped active content onto the page. better yet, disallow this behavior entirely. t

what i really want is an indicator of how many 3rd party https domains have dumped active content onto the page. better yet, disallow this behavior entirely. the fact that banks and other critical portals can dump third party scripts like optimizely and stuff from https cdns is truly disturbing. it's such an obvious oversight to me that i dont understand how a green anything can be shown on mixed https domain sites. am i not understanding something?

pdkl95 11y ago
Try noscript? Douglas Crockford warned[1] us about years ago about the dangers of mixing 3rd party Javascript. Unfortunately, very few listened to that warning. [1] https://www.youtube.com/watch?v=V13wmj88Zx8 https://www.youtube.com/watch?v=V13wmj88Zx8
- leeoniya 11y ago
  my argument is that there should be no need for the average user to install noscript to prevent injection from third party "secure" domains. the default should be to deny loading them in the first place. there should be a "yesscript" for those who want to assume the risk.
  - pdkl95 11y ago
    I completely agree - Javascript is cool, but it's also a security risk that needs to be limited. For the moment, unfortunately, we're stuck running noscript (or similar).
  - Silhouette 11y ago
    But how do you know which resources from a separate domain are third party ones, and which are from (for example) a dedicated CDN run by the same people who operate the site you're visiting and fundamental to its normal operation? For now, there are still performance-related reasons you might want to do this, and many high volume sites do.
    - pdkl95 11y ago
      You don't know - which is why javascript needs to be whitelist-only, no exceptions. > performance-related reasons Security is always more important than performance. It's irresponsible to sacrifice security simply to make page loads faster. Some of these problems can be worked around in the future with authenticated hrefs (such as with a hash-check aka subresource integrity).
      - Silhouette 11y ago
        Security is always more important than performance. It's irresponsible to sacrifice security simply to make page loads faster. And where does functionality fit in, in your black and white world? It's easy to make a lot of things perfectly secure, but if in doing so you give up the essential functionality that made those things useful in the first place, what have you really achieved? If you make JS whitelist-only, no exceptions, then you will break the web for huge numbers of people on huge numbers of sites they value, because JS is useful. Those people aren't going to thank you for keeping them safe, they're going to say your browser doesn't work, and then they're going to use someone else's browser that does work instead. In reality, security is nearly always a sliding scale, and the best results are nearly always achieved by balancing security against other factors like performance and functionality to keep the user as safe as possible while still providing whatever it is they actually want.
  - CaptSpify 11y ago
    There is a yesscript! https://addons.mozilla.org/en-US/firefox/addon/yesscript/ https://addons.mozilla.org/en-US/firefox/addon/yesscript/ But your point stands. That should be done in the browser by default
    - leeoniya 11y ago
      except it's kinda pointless because it does exactly what noscript does - it selectively blacklists specific scripts. the desired behavior is: when on https, auto-blacklist everything except current and sub-domains.
icebraining 11y ago
Mixed content means HTTP+HTTPS resources, not HTTPS-only resources from multiple domains. And it's not always clear what's "third-party", as a common optimization technique is to serve static assets form a second domain, to increase the number of parallel connections.
- pdkl95 11y ago
  > what's "third-party" That's already defined by the same-origin policy. > a common optimization technique Optimization should never happen at the expense of security. (and yes, 3rd party scripts are a security risk) > increase the number of parallel connections. I believe that trick is to save bandwidth by not sending the (large) cookies that would normally be sent to the normal domain.
  - richardwhiuk 11y ago
    >> increase the number of parallel connections. > I believe that trick is to save bandwidth by not sending the (large) cookies that would normally be sent to the normal domain. No, Internet Explorer (and other browsers) used to only allow a small number of connections per domain. Long running COMET requests ate up these connections, so if you wanted to simultaneously download multiple resources from a single domain, and reduce time to page ready, then you had to use multiple domains.
    - extra88 11y ago
      The limit is per host, not per domain. Before using CDNs became commonplace, it was not unusual for a site to use multiple hostnames of their own to spread out their content and have more parallel connections for a single page load; example.com img1.example.com, img2.example.com, etc.
      - richardwhiuk 11y ago
        It's per FQDN, not per host. Host refers to either an individual machine, or an IP address, and the restriction is to neither of these.
deleted 11y ago
[deleted]
Freak_NL 11y ago
Privacy Badger can answer some of those questions: https://www.eff.org/privacybadger https://www.eff.org/privacybadger
nly 11y ago
I agree generally, although Subresource Integrity[0] and Content Security Policy[1] somewhat solve the problem. Not that any of this will ever be deployed[2], because they're two of the most invasive defence measures and fragile wrt updates. [0] https://www.w3.org/TR/SRI/ https://www.w3.org/TR/SRI/ [1] https://scotthelme.co.uk/content-security-policy-an-introduction/ https://scotthelme.co.uk/content-security-policy-an-introduc... [2] https://scotthelme.co.uk/how-widely-used-are-security-based-http-response-headers/ https://scotthelme.co.uk/how-widely-used-are-security-based-...
- phlo 11y ago
  > Not that any of this will ever be deployed[2], because they're two of the most invasive defence measures [...] SRI is going to be a tough sell. CSP, not so much. Case in point: within two years, HSTS use by Swiss Banks has gone from 0% to 40%. I managed to get the first deployment up and running, and at this point we made it into the preload lists. If just one company gets any of this stuff up and running (and whomever did it keeps pestering their colleagues at some others about it), adoption is possible. Right now I'm working on getting some traction with HPKP and CSP. HPKP is going to be challenging as doesn't offer protection against user-installed (or malware-installed) root certificates, but seeing how the cost of adoption is low, it shouldn't be impossible. CSP should be easier. Being the responsible bank we are, we aren't dropping any javascript files from CDNs into our pages. Anything running in our domain originates from there, so it's basically down to starting with -Report-Only, unsafe-eval and unsafe-inline options and gradually moving towards *-src 'self'. And it provides valuable protection against all sorts of Adware and Malware. Ping me in a year. I'm confident we'll get there by then.
  - nailer 11y ago
    > HSTS use by Swiss Banks has gone from 0% to 40%. That's awesome. Do you have a reference? Not doubting you, just want to read more.
    - phlo 11y ago
      Sorry, I don't have a public reference. The first number came from my (unpublished) 2013 bachelor's thesis, where I surveyed the 20 biggest banks (by balance sheet) in each of CH, DE, AT, IT and FR. HSTS was very new back then, so the 0% was no big surprise. The full thesis is in German. I can send you the PDF if you're interested. For the second number, I had a look at 15 banks represented at Vontobel, Credit Suisse, J. Safra Sarasin, PostFinance, Raiffeisen, Swissquote, UBS, Valiant and the State Banks from Basel, Geneva, Grisons, Schaffhausen, Thurgovia, Zug and Zurich. Of these 15 banks, six were using HSTS: CS, PostFinance, Raiffeisen as well as Basel, Thurgovia, Zug and Zurich. Switzerland has over 200 banks in total, but many of these are small private shops, only a couple dozen actually offer e-banking. The majority of people is banking with one of the top 5 (PF/CS/Raiffeisen already are, and I'm hoping for UBS and Valiant to adopt HSTS soon-ish). The 15 I had a look at in December 2015 are responsible for the vast majority (90+%) of online banking done in Switzerland.
angry-hacker 11y ago
Then you need to detect CDN's that actually serve your content. Images and such. They can also come from your subdomain(s) of course. Maybe you could whitelist the subdomains only.
- nailer 11y ago
  > Maybe you could whitelist the subdomains only. https://www.npmjs.com/package/csp-by-api https://www.npmjs.com/package/csp-by-api can help with that: it contains CSPs for popular APIs so you can just add the the APIs you're using to your own CSP: var policy = cspByAPI(basePolicy, ['twitter', 'mixpanel', 'googleFonts', 'stripe', 'typekit', 'ractive'])
anc84 11y ago
anyone similarly disturbed, check out the amazing https://github.com/Synzvato/decentraleyes https://github.com/Synzvato/decentraleyes add-on which will serve those common scripts from a local cache!
tombrossman 11y ago
You are presumably willing to trust the first-party website for content and it is not a big stretch to trust the third-party content they chose to include as well. Not much difference between trusting them to serve jQuery themselves (which they must source from a third-party initially) or link to it directly at the third-party site, for example.
- bsilvereagle 11y ago
  The code they source from the third-party initially can be audited and then self hosted. If the code is not self hosted, the third party can change the script to be malicious (or be compromised) without the first party ever knowing.
  - Phemist 11y ago
    I think this is why integrity hashes should be included anytime a CDN is used to load a third-party library. Bootstrap does this, for example: http://getbootstrap.com/getting-started/ http://getbootstrap.com/getting-started/ I'd like to see more lib providers, and even CDNs themselves, follow suit.
    - Too 11y ago
      Thank you, i always thought about this but didn't know it already existed. This should definitely be used for any content included on a page, especially third party CDN, it could also allow caching if the address changes but the content is the same.

pdkl95 11y ago

Try noscript? Douglas Crockford warned[1] us about years ago about the dangers of mixing 3rd party Javascript. Unfortunately, very few listened to that warning. [1] https://www.youtube.com/watch?v=V13wmj88Zx8 https://www.youtube.com/watch?v=V13wmj88Zx8

leeoniya 11y ago
my argument is that there should be no need for the average user to install noscript to prevent injection from third party "secure" domains. the default should be to deny loading them in the first place. there should be a "yesscript" for those who want to assume the risk.
- pdkl95 11y ago
  I completely agree - Javascript is cool, but it's also a security risk that needs to be limited. For the moment, unfortunately, we're stuck running noscript (or similar).
- Silhouette 11y ago
  But how do you know which resources from a separate domain are third party ones, and which are from (for example) a dedicated CDN run by the same people who operate the site you're visiting and fundamental to its normal operation? For now, there are still performance-related reasons you might want to do this, and many high volume sites do.
  - pdkl95 11y ago
    You don't know - which is why javascript needs to be whitelist-only, no exceptions. > performance-related reasons Security is always more important than performance. It's irresponsible to sacrifice security simply to make page loads faster. Some of these problems can be worked around in the future with authenticated hrefs (such as with a hash-check aka subresource integrity).
    - Silhouette 11y ago
      Security is always more important than performance. It's irresponsible to sacrifice security simply to make page loads faster. And where does functionality fit in, in your black and white world? It's easy to make a lot of things perfectly secure, but if in doing so you give up the essential functionality that made those things useful in the first place, what have you really achieved? If you make JS whitelist-only, no exceptions, then you will break the web for huge numbers of people on huge numbers of sites they value, because JS is useful. Those people aren't going to thank you for keeping them safe, they're going to say your browser doesn't work, and then they're going to use someone else's browser that does work instead. In reality, security is nearly always a sliding scale, and the best results are nearly always achieved by balancing security against other factors like performance and functionality to keep the user as safe as possible while still providing whatever it is they actually want.
- CaptSpify 11y ago
  There is a yesscript! https://addons.mozilla.org/en-US/firefox/addon/yesscript/ https://addons.mozilla.org/en-US/firefox/addon/yesscript/ But your point stands. That should be done in the browser by default
  - leeoniya 11y ago
    except it's kinda pointless because it does exactly what noscript does - it selectively blacklists specific scripts. the desired behavior is: when on https, auto-blacklist everything except current and sub-domains.

icebraining 11y ago

Mixed content means HTTP+HTTPS resources, not HTTPS-only resources from multiple domains. And it's not always clear what's "third-party", as a common optimization technique is to serve static assets form a second domain, to increase the number of parallel connections.

pdkl95 11y ago
> what's "third-party" That's already defined by the same-origin policy. > a common optimization technique Optimization should never happen at the expense of security. (and yes, 3rd party scripts are a security risk) > increase the number of parallel connections. I believe that trick is to save bandwidth by not sending the (large) cookies that would normally be sent to the normal domain.
- richardwhiuk 11y ago
  >> increase the number of parallel connections. > I believe that trick is to save bandwidth by not sending the (large) cookies that would normally be sent to the normal domain. No, Internet Explorer (and other browsers) used to only allow a small number of connections per domain. Long running COMET requests ate up these connections, so if you wanted to simultaneously download multiple resources from a single domain, and reduce time to page ready, then you had to use multiple domains.
  - extra88 11y ago
    The limit is per host, not per domain. Before using CDNs became commonplace, it was not unusual for a site to use multiple hostnames of their own to spread out their content and have more parallel connections for a single page load; example.com img1.example.com, img2.example.com, etc.
    - richardwhiuk 11y ago
      It's per FQDN, not per host. Host refers to either an individual machine, or an IP address, and the restriction is to neither of these.

deleted 11y ago

[deleted]

Freak_NL 11y ago

Privacy Badger can answer some of those questions: https://www.eff.org/privacybadger https://www.eff.org/privacybadger

nly 11y ago

I agree generally, although Subresource Integrity[0] and Content Security Policy[1] somewhat solve the problem. Not that any of this will ever be deployed[2], because they're two of the most invasive defence measures and fragile wrt updates. [0] https://www.w3.org/TR/SRI/ https://www.w3.org/TR/SRI/ [1] https://scotthelme.co.uk/content-security-policy-an-introduction/ https://scotthelme.co.uk/content-security-policy-an-introduc... [2] https://scotthelme.co.uk/how-widely-used-are-security-based-http-response-headers/ https://scotthelme.co.uk/how-widely-used-are-security-based-...

phlo 11y ago
> Not that any of this will ever be deployed[2], because they're two of the most invasive defence measures [...] SRI is going to be a tough sell. CSP, not so much. Case in point: within two years, HSTS use by Swiss Banks has gone from 0% to 40%. I managed to get the first deployment up and running, and at this point we made it into the preload lists. If just one company gets any of this stuff up and running (and whomever did it keeps pestering their colleagues at some others about it), adoption is possible. Right now I'm working on getting some traction with HPKP and CSP. HPKP is going to be challenging as doesn't offer protection against user-installed (or malware-installed) root certificates, but seeing how the cost of adoption is low, it shouldn't be impossible. CSP should be easier. Being the responsible bank we are, we aren't dropping any javascript files from CDNs into our pages. Anything running in our domain originates from there, so it's basically down to starting with -Report-Only, unsafe-eval and unsafe-inline options and gradually moving towards *-src 'self'. And it provides valuable protection against all sorts of Adware and Malware. Ping me in a year. I'm confident we'll get there by then.
- nailer 11y ago
  > HSTS use by Swiss Banks has gone from 0% to 40%. That's awesome. Do you have a reference? Not doubting you, just want to read more.
  - phlo 11y ago
    Sorry, I don't have a public reference. The first number came from my (unpublished) 2013 bachelor's thesis, where I surveyed the 20 biggest banks (by balance sheet) in each of CH, DE, AT, IT and FR. HSTS was very new back then, so the 0% was no big surprise. The full thesis is in German. I can send you the PDF if you're interested. For the second number, I had a look at 15 banks represented at Vontobel, Credit Suisse, J. Safra Sarasin, PostFinance, Raiffeisen, Swissquote, UBS, Valiant and the State Banks from Basel, Geneva, Grisons, Schaffhausen, Thurgovia, Zug and Zurich. Of these 15 banks, six were using HSTS: CS, PostFinance, Raiffeisen as well as Basel, Thurgovia, Zug and Zurich. Switzerland has over 200 banks in total, but many of these are small private shops, only a couple dozen actually offer e-banking. The majority of people is banking with one of the top 5 (PF/CS/Raiffeisen already are, and I'm hoping for UBS and Valiant to adopt HSTS soon-ish). The 15 I had a look at in December 2015 are responsible for the vast majority (90+%) of online banking done in Switzerland.

angry-hacker 11y ago

Then you need to detect CDN's that actually serve your content. Images and such. They can also come from your subdomain(s) of course. Maybe you could whitelist the subdomains only.

nailer 11y ago
> Maybe you could whitelist the subdomains only. https://www.npmjs.com/package/csp-by-api https://www.npmjs.com/package/csp-by-api can help with that: it contains CSPs for popular APIs so you can just add the the APIs you're using to your own CSP: var policy = cspByAPI(basePolicy, ['twitter', 'mixpanel', 'googleFonts', 'stripe', 'typekit', 'ractive'])

anc84 11y ago

anyone similarly disturbed, check out the amazing https://github.com/Synzvato/decentraleyes https://github.com/Synzvato/decentraleyes add-on which will serve those common scripts from a local cache!

tombrossman 11y ago

You are presumably willing to trust the first-party website for content and it is not a big stretch to trust the third-party content they chose to include as well. Not much difference between trusting them to serve jQuery themselves (which they must source from a third-party initially) or link to it directly at the third-party site, for example.

bsilvereagle 11y ago
The code they source from the third-party initially can be audited and then self hosted. If the code is not self hosted, the third party can change the script to be malicious (or be compromised) without the first party ever knowing.
- Phemist 11y ago
  I think this is why integrity hashes should be included anytime a CDN is used to load a third-party library. Bootstrap does this, for example: http://getbootstrap.com/getting-started/ http://getbootstrap.com/getting-started/ I'd like to see more lib providers, and even CDNs themselves, follow suit.
  - Too 11y ago
    Thank you, i always thought about this but didn't know it already existed. This should definitely be used for any content included on a page, especially third party CDN, it could also allow caching if the address changes but the content is the same.