11 ms·

An introduction to JavaScript-based DDoS

122 points by hepha1979 11y ago

mangeletti 11y ago
Subresource integrity (SRI) is a really great idea, especially considering many websites' resources are hosted on many different CDNs, providing many attack vectors. Here is the SRI working draft - http://www.w3.org/TR/SRI/ http://www.w3.org/TR/SRI/ Here is a tool for generating SRI hashes - https://srihash.org/ https://srihash.org/
rakoo 11y ago
It's especially important to realize that Cloudflare offering free TLS for everyone isn't enough to prevent javascript-based DDOS, if you don't make sure that third-party resources are also behind TLS.
- parryjacob 11y ago
  It does a lot considering the fact that most resources on a page served over HTTPS also have to be served over HTTPS.
  - thirsteh 11y ago
    All of them, if you want to do it right. Biggest reason inactive mixed content is allowed at all is that blocking it would break too much.
- kpcyrd 11y ago
  I think "use our free TLS" is directed towards the people who host scripts that get embedded by people, like baidu. Embedding scripts that are hosted behind cloudflare is a terrible idea though.
userbinator 11y ago
You don't even need JS to perform "DDoS" - simply link to an image or some other resource on the target site from another site with high traffic, and you accomplish essentially the same effect. Forums that allow linking to images/etc. in inline posts and/or signatures are another way to "gather a crowd", and I've accidentally DDoS'd in this way too... not unlike the "slashdot effect". In fact it could be argued that HTTPS makes DDoS even more effective, due to the additional overhead it introduces on each connection. I think per-IP rate limiting is one of the best ways of preventing DDoS - stop answering clients that issue too many requests in a short time and they will probably choke on their own open-connections limit very soon as the connections start timing out, since the packets are coming from the browser initiating TCP connections and not a dedicated packet-spewing program.
- hn_ 11y ago
  I remember "hot-linking" was a big problem in the 1990s web. Also one time a myspace template linked to pictures on some guys website and became really popular. He decided to goatse the myspace profiles who were hot-linking his photos.
  - kpcyrd 11y ago
    http://ascii.textfiles.com/archives/1011 http://ascii.textfiles.com/archives/1011
    - timboslice 11y ago
      Risky click of the day after seeing Goatse mentioned above. It was actually a pretty good read, thanks for sharing!
- heatish 11y ago
  How effective would per-IP rate limiting be for these new types of JS attacks though? As I understand it, it's just the sheer number of requests that they can get sent to the server with these types of attacks rather than say a botnet spamming requests over and over from the couple hundred PC's they have under their control or a HTTP POST attack where they trickle in the body of the request to hang up the server.
TazeTSchnitzel 11y ago
SRI is only part of the solution. What you really want is hash-and-name-based lookup with a fallback. That way: * Loading common resources is fast - already loaded by other sites * If resource isn't cached, the browser doesn't need to open a second connection to a CDN, it can grab the file from the same site * Proliferation of multiple CDNs ceases to be an issue, as each does not have separate browser cache * Evil CDNs cannot provide bad JS as integrity is checked and the site isn't relying on a CDN anyway * If a CDN goes down, your site isn't broken, because the fallback can be to a local file Would work something like this: <script src="hash-lookup:jquery-1.10.2.min.js,sha256-C6CB9UYIS9UJeqinPHWTHVqh/E1uhG5Twh+Y5qFQmYg=,static/jquery-1.10.2.min.js"></script> Browser checks cache for a file with a matching name and hash, ignoring site (this looks in a special cache for files loaded with hash-lookup, you can't check for arbitrary web resources). If there is one, it's used. If not, it loads it from the fallback URL, checks the hash, and catches it. Now, this would create potential for hash collision attacks. However: * If hash algorithms found to be weak, browsers can disable them * Unlikely to be effective given users will usually already have a file cached
- zimbatm 11y ago
  Isn't it what SRI does ? (plus SRI is backwards-compatible) If a hash is weak then the browser can disable it. The only consequence is that the src fallback will now be used every time.
  - TazeTSchnitzel 11y ago
    > Isn't it what SRI does ? (plus SRI is backwards-compatible) No it's not. SRI means you keep relying on multiple CDNs, so you keep having cache fragmentation, CDN unavailability continues to be a problem, and uncached items still require a second connection.
    - kpcyrd 11y ago
      (SRI being backwards-compatible is true, though)
    - 11y ago
jetm9 11y ago
i dont get the severity of this attack. for this attack to work you have to include a js from CDN that has been compromised. if you are using a high profile CDN then it would probably be learned sooner. in other case that's plain DDOS not necessarily a JS-based DDOS.

122 points by hepha1979 11y ago

Subresource integrity (SRI) is a really great idea, especially considering many websites' resources are hosted on many different CDNs, providing many attack vectors. Here is the SRI working draft - http://www.w3.org/TR/SRI/ http://www.w3.org/TR/SRI/ Here is a tool for generating SRI hashes - https://srihash.org/ https://srihash.org/

rakoo 11y ago

It's especially important to realize that Cloudflare offering free TLS for everyone isn't enough to prevent javascript-based DDOS, if you don't make sure that third-party resources are also behind TLS.

parryjacob 11y ago
It does a lot considering the fact that most resources on a page served over HTTPS also have to be served over HTTPS.
- thirsteh 11y ago
  All of them, if you want to do it right. Biggest reason inactive mixed content is allowed at all is that blocking it would break too much.
kpcyrd 11y ago
I think "use our free TLS" is directed towards the people who host scripts that get embedded by people, like baidu. Embedding scripts that are hosted behind cloudflare is a terrible idea though.

userbinator 11y ago

You don't even need JS to perform "DDoS" - simply link to an image or some other resource on the target site from another site with high traffic, and you accomplish essentially the same effect. Forums that allow linking to images/etc. in inline posts and/or signatures are another way to "gather a crowd", and I've accidentally DDoS'd in this way too... not unlike the "slashdot effect". In fact it could be argued that HTTPS makes DDoS even more effective, due to the additional overhead it introduces on each connection. I think per-IP rate limiting is one of the best ways of preventing DDoS - stop answering clients that issue too many requests in a short time and they will probably choke on their own open-connections limit very soon as the connections start timing out, since the packets are coming from the browser initiating TCP connections and not a dedicated packet-spewing program.

hn_ 11y ago
I remember "hot-linking" was a big problem in the 1990s web. Also one time a myspace template linked to pictures on some guys website and became really popular. He decided to goatse the myspace profiles who were hot-linking his photos.
- kpcyrd 11y ago
  http://ascii.textfiles.com/archives/1011 http://ascii.textfiles.com/archives/1011
  - timboslice 11y ago
    Risky click of the day after seeing Goatse mentioned above. It was actually a pretty good read, thanks for sharing!
heatish 11y ago
How effective would per-IP rate limiting be for these new types of JS attacks though? As I understand it, it's just the sheer number of requests that they can get sent to the server with these types of attacks rather than say a botnet spamming requests over and over from the couple hundred PC's they have under their control or a HTTP POST attack where they trickle in the body of the request to hang up the server.

TazeTSchnitzel 11y ago

SRI is only part of the solution. What you really want is hash-and-name-based lookup with a fallback. That way: * Loading common resources is fast - already loaded by other sites * If resource isn't cached, the browser doesn't need to open a second connection to a CDN, it can grab the file from the same site * Proliferation of multiple CDNs ceases to be an issue, as each does not have separate browser cache * Evil CDNs cannot provide bad JS as integrity is checked and the site isn't relying on a CDN anyway * If a CDN goes down, your site isn't broken, because the fallback can be to a local file Would work something like this: <script src="hash-lookup:jquery-1.10.2.min.js,sha256-C6CB9UYIS9UJeqinPHWTHVqh/E1uhG5Twh+Y5qFQmYg=,static/jquery-1.10.2.min.js"></script> Browser checks cache for a file with a matching name and hash, ignoring site (this looks in a special cache for files loaded with hash-lookup, you can't check for arbitrary web resources). If there is one, it's used. If not, it loads it from the fallback URL, checks the hash, and catches it. Now, this would create potential for hash collision attacks. However: * If hash algorithms found to be weak, browsers can disable them * Unlikely to be effective given users will usually already have a file cached

zimbatm 11y ago
Isn't it what SRI does ? (plus SRI is backwards-compatible) If a hash is weak then the browser can disable it. The only consequence is that the src fallback will now be used every time.
- TazeTSchnitzel 11y ago
  > Isn't it what SRI does ? (plus SRI is backwards-compatible) No it's not. SRI means you keep relying on multiple CDNs, so you keep having cache fragmentation, CDN unavailability continues to be a problem, and uncached items still require a second connection.
  - kpcyrd 11y ago
    (SRI being backwards-compatible is true, though)
  - 11y ago

jetm9 11y ago

i dont get the severity of this attack. for this attack to work you have to include a js from CDN that has been compromised. if you are using a high profile CDN then it would probably be learned sooner. in other case that's plain DDOS not necessarily a JS-based DDOS.