joepeck02 at gmail.com
Mon Jun 15 20:48:05 PDT 2009
>> In the event of a collision there would be huge issues - imagine
>> someone else's script in your application. Basically XSS - someone
>> take over your app, steal passwords, do bank transactions on your
>> 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.
More information about the whatwg