8 ms·

Browsers really have to be a lot more skeptical about the code they run. Running code should not be able to randomly attack any IP address on the internet. Code

Browsers really have to be a lot more skeptical about the code they run. Running code should not be able to randomly attack any IP address on the internet. Code from non-TLS pages should not be able to run at all. Perhaps that should also apply to code loaded from 3rd party sites. Connecting to a web page should not be consent to allow the operators of that web page to make my computer/phone do whatever they want on the net. It certainly should not be consent to delegate that power to others, either via a embedded link or a MITM attack.

saagarjha 7y ago
> Running code should not be able to randomly attack any IP address on the internet. How would you prevent this? What constitutes an "attack", and how would you make sure you're not interfering with non-malicious use cases?
- Despegar 7y ago
  JavaScript was a mistake
  - lonelappde 7y ago
    This is a network protocol flaw not a language flaw
  - hombre_fatal 7y ago
    This is just another kneejerk. They could have just injected an <img> tag with randomized src="" directly.
    - xorcist 7y ago
      That would not consitute such a problem. The script is what provides the amplification factor here.
kortilla 7y ago
You do know you’re suggesting that sites not be able to load assets from other sites right?
- sli 7y ago
  They are specifically suggesting that HTTP-only sites not be able to load from third party sites, which is quite a bit different than your interpretation of generally preventing any site from loading any external content. HTTPS ought to be the default and browsers can, and should, move towards that. But to answer your question more directly, yes they clearly know what they are suggesting.
  - kortilla 7y ago
    > But to answer your question more directly, yes they clearly know what they are suggesting. Highly unlikely, or else the suggestion would be to just ban http all-together. Http without the ability to load resources from other domains would break the majority of sites.
  - thaumasiotes 7y ago
    I note this language in the writeup: > These attacks would not be successful if the following resources were served over HTTPS instead of HTTP: > http://push.zhanzhang.baidu.com/push.js; http://push.zhanzhang.baidu.com/push.js; or > http://js.passport.qihucdn.com/11.0.1.js http://js.passport.qihucdn.com/11.0.1.js This seems overly generous. I personally would not assume that the government of China couldn't persuade Baidu or qihucdn.com to serve government-provided JavaScript. It also assumes that the end users ("victims") here don't trust any Chinese certificate authority.
    - thyrsus 7y ago
      I'll speculate that there are sufficient locations failing to use https that they haven't felt a need to use https. I further speculate that China is sufficiently entangled with the international internet that they would prefer not to have their certificate authorities de-listed by the major browser vendors.
greggman2 7y ago
Unfortunately there's a giant category of devices that can't serve TLS. Like pretty much every consumer router in existence that you connect to through a webpage. Someone needs to come up with a solution for that. Ideally one that works with free and open source projects and not just well funded companies.
- jMyles 7y ago
  > Unfortunately there's a giant category of devices that can't serve TLS. Like pretty much every consumer router in existence that you connect to through a webpage. Come on now. Of course those devices can use TLS - they just can't do so in the capricious constraints imposed by the system of "certificate authorities". It's not a fundamental limitation of the technology. If we were using something like noise protocol, nobody would be saying that tiny devices are incapable of proper security at the transport layer. There's just no clear way to assess the validity of a self-signed cert in the browser given today's political constraints.
  - smabie 7y ago
    I'm not familiar with this problem, could someone explain? Thanks!
    - lonelappde 7y ago
      There is no problem. Routers can use a self signed cert.
      - zeven7 7y ago
        Could you expand on that a little? What do you mean? Won't my browser complain if the cert if self signed?
        etatoby 7y ago
        Yes, it will complain and for good reason: it has no way of knowing whether the kid next door is spoofing your router's IP or Mac address and presenting their own self-signed certificate. I wouldn't go as far as calling it «capricious constraints imposed by the system of "certificate authorities"» but at the same time, I agree that it's not a fundamental limitation of the technology. Better protocols could be developed to allow a browser to trust a server without (all) the limitations of the current system.
TheRealPomax 7y ago
This sounds like a knee-jerk reaction that doesn't take into consideration the ramifactions of the suggested policy. It won't stop DDoS attacks, because those exist _because the internet exists_ and unless you dismantle the very concept of interconnected "everyone can reach everyone" networking, all you're doing is locking down access to more and more people until only technical experts or the people with enough money to hire those experts get to use it. Advocate the other direction: more freedom, including the freedom to say "thank you, browser, for being locked down by default, but I trust this website and I am okay with everything it wants to do". Instead of locking the web down, let's give users the freedom to put on or remove as many locks as they want to live with. And letting make mistakes with that, too: you don't make things better by taking away important life lessons, either.
- jstummbillig 7y ago
  This, on the other end of the spectrum, seems overly and naively liberal, when not being paired with a workable solution to the massive body of education required to provide adequate technical sophistication to (what has to be most of) 8 billion people.
  - chachachoney 7y ago
    >> a workable solution to the massive body of education required to provide adequate technical sophistication The problem doesn't have to be one of education if it is tackled as a legitimate UI/UX problem and served by a WC3 that supports the needs of end users over corporate partners.
- lonelappde 7y ago
  That requires allowing web servers to blacklist all browsers known to allow http and therefore ddos....which is equivalent to banning http code.
- deleted 7y ago
  [deleted]
- thyrsus 7y ago
ehsankia 7y ago
Each individual user isn't doing that much, just loading an asset from another site, which is fairly inconspicuous. It's when billions of users start doing it that it becomes a problem (the first D in DDoS), but any individual person isn't doing anything out of the ordinary.
nitwit005 7y ago
You don't need to inject scripts to make this sort of thing work. Just add img or style tags with the source set to the target you want to attack. The browser will happily go try to fetch the files from the server, adding to the request load. You can see unintentional examples of this happening. Small sites get taken down occasionally when larger sites directly link to images or videos hosted there.
paulddraper 7y ago
> Connecting to a web page should not be consent to allow the operators of that web page to make my computer/phone do whatever they want on the net. But that is literally what web users want. Everything you named is a fine opinion, but runs contrary to the wishes of the vast majority of millions and millions and millions and millions of web users. EDIT: That said, browsers have features for users such as yourself to disable JavaScript, and there are third party extensions for finer-grained control. Again, adding these limitations is unpopular among web users.
- geofft 7y ago
  I think you'll need some evidence for that. Silence is not consent, and it's certainly not enthusiastic consent. And even if you do want to take silence for consent, the fact that the vast majority of millions of millions of web users do not install an extension to route around Google AMP indicates that they do not want the operators of the web page to do whatever they want, they want to run a restricted subset of what the web designer might imagine. AMP is extremely popular among web users; approximately 100% of Google users use it. (The more defensible argument, of course, is that users don't really want AMP, at which point the question of what users really do want gets back on the table.) Also, users did vote with their feet against downloading EXEs from the internet - which can actually do whatever the developer wants - and using JS on the web platform, which can make unrestricted GET requests (even if it can't see the responses), sure, but can't do anything near "whatever." It stands to reason that users would gladly accept even more restrictions on the execution platform.
  - paulddraper 7y ago
    > they want to run a restricted subset of what the web designer might imagine For the kinds of places that AMP is used, I would suspect so. > Also, users did vote with their feet against downloading EXEs from the internet So....this CAN happen??? > users would gladly accept even more restrictions on the execution platform. The recent popularity of clipboard permissions, geolocation permissions, notification permissions, etc. would suggest otherwise. What makes you so sure that web users care so much about the uptime of lihkg.com ?
kerng 7y ago
It's called hyperlink and doesnt require any code or javascript to run. Maybe excessive requests to same IP could be throttled by a user agent. An outbound browser firewall could helps also.
- thaumasiotes 7y ago
  > It's called hyperlink and doesnt require any code or javascript to run. Hyperlinks generally don't open themselves. There is an obvious exception -- img tags[1] -- and I think it's worth considering whether they should be allowed to have the behavior they do. As far as I see, img tags load themselves so that, if you're editing HTML by hand, you don't have to deal with binary image data in the middle of what was supposed to be a clean text file. That may not be the right tradeoff. [1] The img model got extended to other external resource loads, like script and css. But both of those frequently do appear as part of the same HTML that uses them. Image data can, but usually doesn't. Also, external script loads are such an obvious problem that we got the Content-Security-Policy just to deal with it.
  - sonofhans 7y ago
    HTML was initially intended as, and still largely is, a markup language. An HTML file provides a container and presentation for other types of content. If you saved all those types of content into the same file you'd have many of the problems HTML was specifically designed to avoid, like bloat, vendor lock-in, format incompatibility, and editing difficulty.
  - kerng 7y ago
    Iframes are popular for these things - also, dont require javascript to run.
jrockway 7y ago
TLS should be required, but it seems likely to me that the Chinese government can issue TLS certificates for MITM purposes that their browsers will trust. As for the DoS aspect, maybe it's time to do a CORS preflight on ALL cross-origin requests, including images. (Webfonts, for whatever reason, already require a CORS preflight. Probably because Adobe is on the W3C and they sell a service where certain origins can legally use certain fonts from their servers. I hate it when user security features get turned into subsidies for large corporations, but here we are.) Of course, if you have broken TLS I guess you can just forge the CORS response. Edit to add: I have read more comments and better understand the attack now. China is modifying the Javascript on Chinese websites that are being viewed from outside China. Making TLS mandatory would be a big help here. China could say "all Chinese companies must buy certificates from the Great Chinese CA" and they could still do the MITM. But with evidence of the CA issuing fake certificates to DoS websites, browsers would probably stop trusting that CA entirely. I imagine China would like to avoid that, so I feel like this would have stopped the attack.
- netsharc 7y ago
  > But with evidence of the CA issuing fake certificates to DoS websites, browsers would probably stop trusting that CA entirely. "Hey Tim Apple/Microsoft/Google, if you want to do business in China you have to put our CA on your devices/software...". At least Firefox would still be free from that. And Apple already has China-specific iOS, so they'd just activate the bad CA on Chinese devices...
  - jrockway 7y ago
    My guess is that Firefox and Chrome would push back. Apple probably has too much to lose, though.
zzo38computer 7y ago
> Browsers really have to be a lot more skeptical about the code they run. I absolutely believe you, and wrote a document how to make improvement. > Code from non-TLS pages should not be able to run at all. Whether or not it is TLS is irrelevant. Either way the user may wish to put their own code, and either way the server operator can change things whether or not is what the user intends. (TLS does prevent spies from adding code, but not all unwanted code is from spies.) > Instead of locking the web down, let's give users the freedom to put on or remove as many locks as they want to live with. I agree. Furthermore, allow the user to override any behaviour they want to do, too. Allow the user to examine and copy the script (possibly with modifications); if the script changes (whether due to MITM or due to the author altering it or due to some other company purchasing them), it no longer runs unless the user approves the new one, too. Extensions that only allow free software to run don't help either; just because it is free software does not necessarily mean it is a program the user wants their computer to execute. Or, maybe the user wants to execute a modified version instead!
collsni 7y ago
Tls sadly won't make a difference.
ngcc_hk 7y ago
Can there be a list that come up so user who want control can see what pages the link they have selected to link implicitly. Just on the side perhaps. They can explicitly block or AI learn etc. It may have to a feature as deny or enable all is too rough to be useful. For china need some way to handle that whole commerical-military-party all one entity.
Ayesh 7y ago
Sites embedding said JS "analytics" files could have implemented HSTS and CSP with SRI, and this attack wouldn't exist.
LifeLiverTransp 7y ago
Users should be able to restrain communication and duration of computation..

saagarjha 7y ago

> Running code should not be able to randomly attack any IP address on the internet. How would you prevent this? What constitutes an "attack", and how would you make sure you're not interfering with non-malicious use cases?

Despegar 7y ago
JavaScript was a mistake
- lonelappde 7y ago
  This is a network protocol flaw not a language flaw
- hombre_fatal 7y ago
  This is just another kneejerk. They could have just injected an <img> tag with randomized src="" directly.
  - xorcist 7y ago
    That would not consitute such a problem. The script is what provides the amplification factor here.

kortilla 7y ago

You do know you’re suggesting that sites not be able to load assets from other sites right?

sli 7y ago
They are specifically suggesting that HTTP-only sites not be able to load from third party sites, which is quite a bit different than your interpretation of generally preventing any site from loading any external content. HTTPS ought to be the default and browsers can, and should, move towards that. But to answer your question more directly, yes they clearly know what they are suggesting.
- kortilla 7y ago
  > But to answer your question more directly, yes they clearly know what they are suggesting. Highly unlikely, or else the suggestion would be to just ban http all-together. Http without the ability to load resources from other domains would break the majority of sites.
- thaumasiotes 7y ago
  I note this language in the writeup: > These attacks would not be successful if the following resources were served over HTTPS instead of HTTP: > http://push.zhanzhang.baidu.com/push.js; http://push.zhanzhang.baidu.com/push.js; or > http://js.passport.qihucdn.com/11.0.1.js http://js.passport.qihucdn.com/11.0.1.js This seems overly generous. I personally would not assume that the government of China couldn't persuade Baidu or qihucdn.com to serve government-provided JavaScript. It also assumes that the end users ("victims") here don't trust any Chinese certificate authority.
  - thyrsus 7y ago
    I'll speculate that there are sufficient locations failing to use https that they haven't felt a need to use https. I further speculate that China is sufficiently entangled with the international internet that they would prefer not to have their certificate authorities de-listed by the major browser vendors.

greggman2 7y ago

Unfortunately there's a giant category of devices that can't serve TLS. Like pretty much every consumer router in existence that you connect to through a webpage. Someone needs to come up with a solution for that. Ideally one that works with free and open source projects and not just well funded companies.

jMyles 7y ago
> Unfortunately there's a giant category of devices that can't serve TLS. Like pretty much every consumer router in existence that you connect to through a webpage. Come on now. Of course those devices can use TLS - they just can't do so in the capricious constraints imposed by the system of "certificate authorities". It's not a fundamental limitation of the technology. If we were using something like noise protocol, nobody would be saying that tiny devices are incapable of proper security at the transport layer. There's just no clear way to assess the validity of a self-signed cert in the browser given today's political constraints.
- smabie 7y ago
  I'm not familiar with this problem, could someone explain? Thanks!
  - lonelappde 7y ago
    There is no problem. Routers can use a self signed cert.
    - zeven7 7y ago
      Could you expand on that a little? What do you mean? Won't my browser complain if the cert if self signed?
      - etatoby 7y ago
        Yes, it will complain and for good reason: it has no way of knowing whether the kid next door is spoofing your router's IP or Mac address and presenting their own self-signed certificate. I wouldn't go as far as calling it «capricious constraints imposed by the system of "certificate authorities"» but at the same time, I agree that it's not a fundamental limitation of the technology. Better protocols could be developed to allow a browser to trust a server without (all) the limitations of the current system.

TheRealPomax 7y ago

This sounds like a knee-jerk reaction that doesn't take into consideration the ramifactions of the suggested policy. It won't stop DDoS attacks, because those exist _because the internet exists_ and unless you dismantle the very concept of interconnected "everyone can reach everyone" networking, all you're doing is locking down access to more and more people until only technical experts or the people with enough money to hire those experts get to use it. Advocate the other direction: more freedom, including the freedom to say "thank you, browser, for being locked down by default, but I trust this website and I am okay with everything it wants to do". Instead of locking the web down, let's give users the freedom to put on or remove as many locks as they want to live with. And letting make mistakes with that, too: you don't make things better by taking away important life lessons, either.

jstummbillig 7y ago
This, on the other end of the spectrum, seems overly and naively liberal, when not being paired with a workable solution to the massive body of education required to provide adequate technical sophistication to (what has to be most of) 8 billion people.
- chachachoney 7y ago
  >> a workable solution to the massive body of education required to provide adequate technical sophistication The problem doesn't have to be one of education if it is tackled as a legitimate UI/UX problem and served by a WC3 that supports the needs of end users over corporate partners.
lonelappde 7y ago
That requires allowing web servers to blacklist all browsers known to allow http and therefore ddos....which is equivalent to banning http code.
deleted 7y ago
[deleted]
thyrsus 7y ago

ehsankia 7y ago

Each individual user isn't doing that much, just loading an asset from another site, which is fairly inconspicuous. It's when billions of users start doing it that it becomes a problem (the first D in DDoS), but any individual person isn't doing anything out of the ordinary.

nitwit005 7y ago

You don't need to inject scripts to make this sort of thing work. Just add img or style tags with the source set to the target you want to attack. The browser will happily go try to fetch the files from the server, adding to the request load. You can see unintentional examples of this happening. Small sites get taken down occasionally when larger sites directly link to images or videos hosted there.

paulddraper 7y ago

> Connecting to a web page should not be consent to allow the operators of that web page to make my computer/phone do whatever they want on the net. But that is literally what web users want. Everything you named is a fine opinion, but runs contrary to the wishes of the vast majority of millions and millions and millions and millions of web users. EDIT: That said, browsers have features for users such as yourself to disable JavaScript, and there are third party extensions for finer-grained control. Again, adding these limitations is unpopular among web users.

geofft 7y ago
I think you'll need some evidence for that. Silence is not consent, and it's certainly not enthusiastic consent. And even if you do want to take silence for consent, the fact that the vast majority of millions of millions of web users do not install an extension to route around Google AMP indicates that they do not want the operators of the web page to do whatever they want, they want to run a restricted subset of what the web designer might imagine. AMP is extremely popular among web users; approximately 100% of Google users use it. (The more defensible argument, of course, is that users don't really want AMP, at which point the question of what users really do want gets back on the table.) Also, users did vote with their feet against downloading EXEs from the internet - which can actually do whatever the developer wants - and using JS on the web platform, which can make unrestricted GET requests (even if it can't see the responses), sure, but can't do anything near "whatever." It stands to reason that users would gladly accept even more restrictions on the execution platform.
- paulddraper 7y ago
  > they want to run a restricted subset of what the web designer might imagine For the kinds of places that AMP is used, I would suspect so. > Also, users did vote with their feet against downloading EXEs from the internet So....this CAN happen??? > users would gladly accept even more restrictions on the execution platform. The recent popularity of clipboard permissions, geolocation permissions, notification permissions, etc. would suggest otherwise. What makes you so sure that web users care so much about the uptime of lihkg.com ?

kerng 7y ago

It's called hyperlink and doesnt require any code or javascript to run. Maybe excessive requests to same IP could be throttled by a user agent. An outbound browser firewall could helps also.

thaumasiotes 7y ago
> It's called hyperlink and doesnt require any code or javascript to run. Hyperlinks generally don't open themselves. There is an obvious exception -- img tags[1] -- and I think it's worth considering whether they should be allowed to have the behavior they do. As far as I see, img tags load themselves so that, if you're editing HTML by hand, you don't have to deal with binary image data in the middle of what was supposed to be a clean text file. That may not be the right tradeoff. [1] The img model got extended to other external resource loads, like script and css. But both of those frequently do appear as part of the same HTML that uses them. Image data can, but usually doesn't. Also, external script loads are such an obvious problem that we got the Content-Security-Policy just to deal with it.
- sonofhans 7y ago
  HTML was initially intended as, and still largely is, a markup language. An HTML file provides a container and presentation for other types of content. If you saved all those types of content into the same file you'd have many of the problems HTML was specifically designed to avoid, like bloat, vendor lock-in, format incompatibility, and editing difficulty.
- kerng 7y ago
  Iframes are popular for these things - also, dont require javascript to run.

jrockway 7y ago

TLS should be required, but it seems likely to me that the Chinese government can issue TLS certificates for MITM purposes that their browsers will trust. As for the DoS aspect, maybe it's time to do a CORS preflight on ALL cross-origin requests, including images. (Webfonts, for whatever reason, already require a CORS preflight. Probably because Adobe is on the W3C and they sell a service where certain origins can legally use certain fonts from their servers. I hate it when user security features get turned into subsidies for large corporations, but here we are.) Of course, if you have broken TLS I guess you can just forge the CORS response. Edit to add: I have read more comments and better understand the attack now. China is modifying the Javascript on Chinese websites that are being viewed from outside China. Making TLS mandatory would be a big help here. China could say "all Chinese companies must buy certificates from the Great Chinese CA" and they could still do the MITM. But with evidence of the CA issuing fake certificates to DoS websites, browsers would probably stop trusting that CA entirely. I imagine China would like to avoid that, so I feel like this would have stopped the attack.

netsharc 7y ago
> But with evidence of the CA issuing fake certificates to DoS websites, browsers would probably stop trusting that CA entirely. "Hey Tim Apple/Microsoft/Google, if you want to do business in China you have to put our CA on your devices/software...". At least Firefox would still be free from that. And Apple already has China-specific iOS, so they'd just activate the bad CA on Chinese devices...
- jrockway 7y ago
  My guess is that Firefox and Chrome would push back. Apple probably has too much to lose, though.

zzo38computer 7y ago

> Browsers really have to be a lot more skeptical about the code they run. I absolutely believe you, and wrote a document how to make improvement. > Code from non-TLS pages should not be able to run at all. Whether or not it is TLS is irrelevant. Either way the user may wish to put their own code, and either way the server operator can change things whether or not is what the user intends. (TLS does prevent spies from adding code, but not all unwanted code is from spies.) > Instead of locking the web down, let's give users the freedom to put on or remove as many locks as they want to live with. I agree. Furthermore, allow the user to override any behaviour they want to do, too. Allow the user to examine and copy the script (possibly with modifications); if the script changes (whether due to MITM or due to the author altering it or due to some other company purchasing them), it no longer runs unless the user approves the new one, too. Extensions that only allow free software to run don't help either; just because it is free software does not necessarily mean it is a program the user wants their computer to execute. Or, maybe the user wants to execute a modified version instead!

collsni 7y ago

Tls sadly won't make a difference.

ngcc_hk 7y ago

Can there be a list that come up so user who want control can see what pages the link they have selected to link implicitly. Just on the side perhaps. They can explicitly block or AI learn etc. It may have to a feature as deny or enable all is too rough to be useful. For china need some way to handle that whole commerical-military-party all one entity.

Ayesh 7y ago

Sites embedding said JS "analytics" files could have implemented HSTS and CSP with SRI, and this attack wouldn't exist.

LifeLiverTransp 7y ago

Users should be able to restrain communication and duration of computation..