TL;DR: Should we merge https://gerrit.wikimedia.org/r/#/c/165979/ and release it with MediaWiki 1.24?
A lot of sites have used MediaWiki:Common.js and MediaWiki:Common.css to customize the appearance of their site.
In a recent security release[1], support for JS and CSS with on-wiki origins was removed from being displayed on the Special:Login and Special:Preferences page.
Because of how the on-wiki MediaWiki:Common.* pages are used and the access restrictions on them, I think it is reasonable to allow JS and CSS from them while continuing to disallow individual's JS and CSS on the Special:Preferences and Special:Login page.
Alexia filed a bug[2] and Kunal (Legoktm) has provided a patch[3] to allow site-wide styling back on those pages.
I'd like to merge this, but I want some input from the community and security people before I do that.
Thanks,
Mark.
(Reply-to set to mediawiki-l.)
Footnotes: [1] https://bugzilla.wikimedia.org/70672
[2] https://bugzilla.wikimedia.org/71621
[3] https://gerrit.wikimedia.org/r/#/c/165979/
On 11/6/14 6:58 AM, Mark A. Hershberger wrote:
TL;DR: Should we merge https://gerrit.wikimedia.org/r/#/c/165979/ and release it with MediaWiki 1.24?
A lot of sites have used MediaWiki:Common.js and MediaWiki:Common.css to customize the appearance of their site.
In a recent security release[1], support for JS and CSS with on-wiki origins was removed from being displayed on the Special:Login and Special:Preferences page.
To be clear, only CSS was removed. JS was already not allowed on Special:Login/Preferences.
Because of how the on-wiki MediaWiki:Common.* pages are used and the access restrictions on them, I think it is reasonable to allow JS and CSS from them while continuing to disallow individual's JS and CSS on the Special:Preferences and Special:Login page.
Alexia filed a bug[2] and Kunal (Legoktm) has provided a patch[3] to allow site-wide styling back on those pages.
Right, the patch only re-adds site-wide CSS, not JS.
-- Legoktm
TL;DR: Should we merge https://gerrit.wikimedia.org/r/#/c/165979/ and release it with MediaWiki 1.24?
A lot of sites have used MediaWiki:Common.js and MediaWiki:Common.css to customize the appearance of their site.
In a recent security release[1], support for JS and CSS with on-wiki origins was removed from being displayed on the Special:Login and Special:Preferences page.
To be clear, only CSS was removed. JS was already not allowed on Special:Login/Preferences.
Because of how the on-wiki MediaWiki:Common.* pages are used and the access restrictions on them, I think it is reasonable to allow JS and CSS from them while continuing to disallow individual's JS and CSS on the Special:Preferences and Special:Login page.
Alexia filed a bug[2] and Kunal (Legoktm) has provided a patch[3] to allow site-wide styling back on those pages.
Right, the patch only re-adds site-wide CSS, not JS.
This seems completely reasonable to me. I'd merge is personally. Is there any reason not to?
Thank you, Derric Atzrott
"Derric Atzrott" datzrott@alizeepathology.com writes:
TL;DR: Should we merge https://gerrit.wikimedia.org/r/#/c/165979/ and release it with MediaWiki 1.24?
This seems completely reasonable to me. I'd merge is personally. Is there any reason not to?
The discussion on the bug and the fact that this was in a security release.
I'll merge it tomorrow for RC.1 unless someone objects or a problem arises.
Mark.
On Thu, Nov 6, 2014 at 11:41 AM, Derric Atzrott datzrott@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.
On 2014-11-06 4:45 PM, Chris Steipp wrote:
On Thu, Nov 6, 2014 at 11:41 AM, Derric Atzrott datzrott@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/]
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
On 11/6/14 4:45 PM, Chris Steipp wrote:
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've amended https://gerrit.wikimedia.org/r/#/c/165979/3 to be controlled by a config setting.
-- Legoktm
wikitech-l@lists.wikimedia.org