[Bug 11402] One problem of todays JavaScript libraries is, that the client has to download the same library over and over again, while visiting multiple sites. One could use services like Google Libraries API for a central location, but that introduces new points of

http://www.w3.org/Bugs/Public/show_bug.cgi?id=11402

Tab Atkins Jr. <jackalmage@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jackalmage@gmail.com
            Summary|One problem of todays       |One problem of todays
                   |JavaScript libraries is,    |JavaScript libraries is,
                   |that the client has to      |that the client has to
                   |download the same library   |download the same library
                   |over and over again, while  |over and over again, while
                   |visiting multiple sites.    |visiting multiple sites.
                   |One could use services like |One could use services like
                   |Google Libraries API for a  |Google Libraries API for a
                   |central location            |central location, but that
                   |                            |introduces new points of
            Summary|but that introduces new     |
                   |points of                   |

--- Comment #1 from Tab Atkins Jr. <jackalmage@gmail.com> 2010-11-24 22:32:28 UTC ---
This has been suggested before, and it suffers from a trivial and fundamental
cache-poisoning problem:

1) Figure out a set of common hashes for common libraries.
2) At your own site, set up an script that would do something evil if you could
trick another site to run it for you, like steal bank info.
3) On a page of your own, link to the script multiple times, each time
specifying a different hash from the list in (1).
4) Trick people into visiting your page.

Some fraction of people will visit your page with a fresh "script-hash" cache,
thus associating your evil script with that hash.  Later, when they visit a
page that uses the same hash legitimately to include a javascript library, your
script runs instead, and in a trusted context.  Chaos ensures.

This can be trimmed down in important ways, like seeing what hash particular
banking websites use, then setting up a standard phishing scheme that just
sends the victim to your evil site, poisons their cache, and then immediately
redirects them to the actual bank site.  The link in your phishing email thus
appears to lead to the bank site like it's supposed to, and so even savvy users
can be tricked.

This can potentially be mitigated by specifying particular hash algorithms that
can be used, so the browser can verify that the script actually hashes to the
provided value before committing it to the cache, but that still leaves us at
the mercy of hashing algorithms being strong.  Had this been specified before
we knew that MD5 was broken, for example, the attack described above would now
be completely doable even *with* hash verification.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Wednesday, 24 November 2010 22:32:31 UTC