https://bugzilla.wikimedia.org/show_bug.cgi?id=72676
Bug ID: 72676 Summary: JavaScript caching within localStorage allows persisten XSS on all *.wikipedia.org domains. Product: MediaWiki Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: Unprioritized Component: JavaScript Assignee: wikibugs-l@lists.wikimedia.org Reporter: lekies-sebast...@gmx.de CC: krinklem...@gmail.com, matma....@gmail.com, tpars...@wikimedia.org Web browser: --- Mobile Platform: --- The wikipedia main page caches a piece of JavaScript code within localStorage under the the key "MediaWikiModuleStore:enwiki" (*en*wiki depends on the language). The JavaScript gets executed every time the page loads. This allows active network attackers and people with access to the local computer, to persist XSS payloads within localStorage. Let's assume the following scenario: A wikipedia user uses an open wifi to surf on unrelated Web sites. An active network attacker injects an invisible iframe into the unrelated http traffic of the user pointing to the domain en.wikipedia.org. This will cause the browser of the user to conduct an http request towards en.wikipedia.org. The active network attacker injects a piece of JavaScript into this request that tampers with the JavaScript cached wihtin localStorage: localStorage.setItem("MediaWikiModuleStore:enwiki", localStorage.getItem("MediaWikiModuleStore:enwiki").replace("jQuery.byteLength=", "alert(document.domain)/* attacker controlled code */;jQuery.byteLength=")) The user leaves the openWifi and returns to a safe wifi network (let's say at home). Feeling safe, he opens wikipedia.org to login using his username and password. At this point the wikipedia Web site executes the JavaScript stored in the localStorage. Hence, the attacker controlled code gets executed within the seemingly secure environment. While logging in, the JavaScript records the user's password and username and sends it to the attacker. I tested this scenario locally and it works as described. To record the password, the password from needs to be located within the same origin (same host, port and protocol). While the login link on the main page, redirects the user to an https version of the login form (where the attack is not possible due to the different protocol (http vs https)), the same login form is also available via http. So the attacker can simply rewrite all the links to the login form, from https to http and wait for the vicitim to click on one of the links. As soon as the victim visits the http version of the login page, the attacker's code executes again and is able to steal the user's credentials. If you have any questions, just let me know. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l