On Thursday, November 6, 2014, Daniel Friesen <daniel(a)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(a)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(a)lists.wikimedia.org <javascript:;>
https://lists.wikimedia.org/mailman/listinfo/wikitech-l