On Thursday, November 6, 2014, Daniel Friesen daniel@nadir-seen-fire.com wrote:
On 2014-11-06 4:45 PM, Chris Steipp wrote:
On Thu, Nov 6, 2014 at 11:41 AM, Derric Atzrott <datzrott@alizeepathology.com javascript:;> 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.
Very true, but the paranoid can still type in Special:UserLogin and get the correct page. A url parameter to disable site css/js would be just fine by me too...
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org javascript:; https://lists.wikimedia.org/mailman/listinfo/wikitech-l