On Thursday, November 6, 2014, Daniel Friesen <dan...@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 > > <datzr...@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 _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
