- From: Joseph Pecoraro <joepeck02@gmail.com>
- Date: Mon, 15 Jun 2009 23:48:05 -0400
>> In the event of a collision there would be huge issues - imagine >> running >> someone else's script in your application. Basically XSS - someone >> could >> take over your app, steal passwords, do bank transactions on your >> behalf, >> etc. >> Collisions are made easier in plain text than in certs given that >> your input >> is not constrained. > > Aaron Boodman: I think the idea was for browser vendors to select > and include these > libraries in the browser. So there isn't an obvious (to me) way for an > attacker to use hash collisions to create an XSS. Yes, thanks for clearing that up. > That said, I don't think content hashes are the right identifier. > Using a sha-1 of a specific jquery version would prevent anyone from > ever fixing critical bugs in it. There's be all this legacy content > out there referring to an outdated version. Assuming there is a buggy version of a JS library: 1. It probably shouldn't be used. 2. The browser vendor can (and should) eliminate it from their repository and proceed with the usual fallback of downloading the script from the <script>'s src attribute would take effect. I could see where this could get confusing. JS Library X gets released and tells its users to use SHA1 "ABC...". Thousands of people download it, and later that day they fix an issue, update their site and say use this new version with SHA1 "FDE...". Canonical listings would makes this easier. - Joe
Received on Monday, 15 June 2009 20:48:05 UTC