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
