On 2014-11-06 4:45 PM, Chris Steipp wrote: > On Thu, Nov 6, 2014 at 11:41 AM, Derric Atzrott > <datzr...@alizeepathology.com> wrote: >> This seems completely reasonable to me. I'd merge is personally. Is there >> any reason not to? > It's fairly easy to inject javascript via css, so merging that patch > means an admin can run javascript on the login/preferences page, while > we specifically block javascript from Common.js, etc. > > For me, I like knowing that when I login on a random wiki in our > cluster, a site admin can't have (maliciously or unintentionally) put > javascript on the login page to sniff my password. I'd prefer Kunal's > patch had a feature flag so we could disable this on WMF wikis, but > sites with robust auditing of their common.css can enable it.
I should probably take some time to remind everyone that things hiding any form of JS from single pages like the login pages makes them secure, that restrictions like those are not that hard to bypass by using JS on a non-login page to use AJAX and history.pushState to trick someone clicking the login link into thinking that they actually navigated the page and are safe from site-js, when in reality they're actually still on the same page with malicious site-js running. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/] _______________________________________________ MediaWiki-l mailing list To unsubscribe, go to: https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
