3 ms·

Thanks! The original poster said to also use the size. If you include that, my understanding is that crafting a hash collision is into the realms of impossibi

• MichaelGG 11y ago
  There is no hash collision happening.
• deathanatos 11y ago
  I'm not seeing how size would prevent the attack. If I understand bugmen0t correctly, in the attack outlined, the file "evil.js" size (and hash and contents) are completely controlled by the attacker. If you did need to specify size, the attack would simply change to: 3. the XSS attack is loading <script src=www.victim.com/evil.js hash=foo size=123> > If you include that, my understanding is that crafting a hash collision is into the realms of impossibility. Crafting a hash collision is already in the realm of impossibility. (They're using cryptographic hashes: if you can make SHA256 collide, we have bigger problems.) The attack here isn't that you're getting the wrong file, it's that you're getting a file the webserver does not have, at all. Step 4 is where we go wrong: we load the file from cache, while we should instead request it from the server, which will 404 the request because it does not have the file. (And it's JS: even if size did matter, you can just add spaces to the end…)
  • AndrewDucker 11y ago
    Sorry, my brain clearly imploded while I was reading that. On re-reading it makes perfect sense. Thanks!
  • kuschku 11y ago
    How about you'd do a request saying "hey, I’d like to have victim.com/evil.js, I have a file with hash 93987590837309, is that still up-to-date?", and then you’d hope for 304 Not Modified (and load from evil.com/evil.js), or you’d get a 404 or 200 or whatever.