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
