Re: [Wikitech-l] RFC: Add Content-Security-Policy header to MediaWiki

[Tyler Romeo]

First, as I expected, this proposal is to use CSP with the "unsafe-eval"
option enabled for both style-src and script-src. This means the JavaScript
eval() function can be used freely, and inline CSS via the style attribute
can still be used. Combined with the "default-src *" policy, which I
mention later in this email, this means an attacker can just use XHR to
download an external script and eval() it, thus defeating the entire point
of CSP: to prevent XSS attacks.

I understand the reason behind this is because we store scripts in
localStorage as cache and eval() them upon page load (which is perhaps the
worst abuse of browser technology I have ever seen). Not allowing both
inline scripts and styles and eval()ed code is one half of the two-sided
CSP coin, and eliminating it keeps open a pretty large attack vector. I
don't believe it's appropriate to sacrifice security for a quick kludge
that is used to improve the performance hole opened by the large
fragmentation of our JavaScript codebase.

Second, the proposal is to use the nonce-$RANDOM attribute for inline
scripts, but to cache the nonce for non-logged-in users. Does this mean
that the same nonce will be delivered to multiple pages and/or users?
Because that is a violation of the CSP spec, which says "If a server
delivers a nonce-source expression as part of a police, the server MUST
generate a unique value each time it transmits a policy." [0] Thus we
cannot use nonces in this way. Are these scripts whose contents we know
beforehand? Because then we can just use the hash-source policy.

(Not to mention that nonce-source and hash-source policies are part of CSP
2, which is not supported in the latest IE, Safari, or Opera Mini. What is
the plan to support these browsers? Fall back to unsafe-inline? Possibly
use a solution similar to what Dropbox used for their CSP deployment [1].)

Finally, as stage 1 hints at and as I mentioned above, there are a lot more
than just style-src and script-src, such as font-src, media-src, frame-src,
manifest-src, etc. Why are these not addressed, and instead just left to
the default policy of "default-src *"? Do we allow iframes on Wikipedia
pointing at arbitrary domains? At the very least, a scheme-source policy
can be used to enforce HTTPS.

[0] https://w3c.github.io/webappsec-csp/
[1]
https://blogs.dropbox.com/tech/2015/09/unsafe-inline-and-nonce-deployment/


*-- *
*Tyler Romeo*
Stevens Institute of Technology, Class of 2016
Major in Computer Science

On Mon, May 23, 2016 at 1:18 AM, Pine W  wrote:

> With the disclaimer that I'm not a security engineer and that I understand
> only parts of this proposal, in general this strikes me as a good idea. It
> seems to me that trying to develop a comprehensive list of what tools /
> scripts this proposal would likely break, how important those breaks are,
> and who could fix them and when, would help with developing a roadmap
> toward implementing this proposal with appropriate mitigation and
> communication.
>
> It seems to me that this is the kind of project for which product community
> liasons are well suited to help with developing and implementing a rollout
> plan. Is there any chance of getting a CL to help with this project?
>
> Thanks for the initiative,
>
> Pine
>
> Pine
> On May 22, 2016 18:18, "Brian Wolff"  wrote:
>
> > So the RFC process page says I should email wikitech-l to propose an RFC,
> > thus:
> >
> > Content-Security-Policy (CSP) header is a header that disables certain
> > javascript features that are commonly used to exploit XSS attacks, in
> > order to mitigate the risks of XSS. I think we could massively benefit
> > from using this technology - XSS attacks probably being the most
> > common security issue in MediaWiki. The downside is that it would
> > break compatibility with older user scripts.
> >
> > Please see the full text of my proposal at
> >
> https://www.mediawiki.org/wiki/Requests_for_comment/Content-Security-Policy
> >
> > The associated phabricator ticket is:
> > https://phabricator.wikimedia.org/T135963
> >
> > I'd appreciate any comments anyone might have.
> >
> > Thanks,
> > Brian
> >
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > 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
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] RFC: Add Content-Security-Policy header to MediaWiki

[Pine W]

With the disclaimer that I'm not a security engineer and that I understand
only parts of this proposal, in general this strikes me as a good idea. It
seems to me that trying to develop a comprehensive list of what tools /
scripts this proposal would likely break, how important those breaks are,
and who could fix them and when, would help with developing a roadmap
toward implementing this proposal with appropriate mitigation and
communication.

It seems to me that this is the kind of project for which product community
liasons are well suited to help with developing and implementing a rollout
plan. Is there any chance of getting a CL to help with this project?

Thanks for the initiative,

Pine

Pine
On May 22, 2016 18:18, "Brian Wolff"  wrote:

> So the RFC process page says I should email wikitech-l to propose an RFC,
> thus:
>
> Content-Security-Policy (CSP) header is a header that disables certain
> javascript features that are commonly used to exploit XSS attacks, in
> order to mitigate the risks of XSS. I think we could massively benefit
> from using this technology - XSS attacks probably being the most
> common security issue in MediaWiki. The downside is that it would
> break compatibility with older user scripts.
>
> Please see the full text of my proposal at
> https://www.mediawiki.org/wiki/Requests_for_comment/Content-Security-Policy
>
> The associated phabricator ticket is:
> https://phabricator.wikimedia.org/T135963
>
> I'd appreciate any comments anyone might have.
>
> Thanks,
> Brian
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> 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

[Wikitech-l] ArchCom-RFC status update: 2016-W20

[Rob Lanphier]

Hi everyone,

Here's the ArchCom RFC status update for 2016-W20 [1], which is also
available via mw:Architecture_committee/Status [2]

= Recent RFC meetings =
* ArchCom Planning meeting 2016W20: 2016-05-18: [[Phab:E183]] (E156/7)
** Notes: [[Architecture committee/2016-05-18]]
* ArchCom-RFC office hour 2016W20: 2016-05-18: [[Phab:E184]] (E66/35)
** [[Phab:T102476|T102476: RFC: Requirements for change propagation]]

= Upcoming RFC meetings =
* ArchCom Planning meeting 2016W21: 2016-05-25: [[Phab:E194]] (E156/8)
** Notes: [[Architecture committee/2016-05-25]]
* ArchCom-RFC office hour 2016W21: 2016-05-25: [[Phab:E187]] (E66/36)
** RFC triage meeting using [[phab:tag/archcom-rfc/|ArchCom RFC board]]
** Goal: assign priorities for items marked "needs triage" and ensure
that high priority items are clearly marked as such

= Entering Final Comment Period =
* None.

= Recently Approved =
* [[Phab:T120164|T120164 RFC: Institute "last call" period]]

 RFC inbox 
* [[phab:tag/archcom-rfc/|ArchCom RFC board]]:
** Inbox zero on 2016-06-11.

= Shepherd status =
* Brion
** (?)
* Daniel
** Software Quality working group?
** Working on Multi Content Rev Spec with Brion
** T113034 [[phab:T113034|RFC: Overhaul Interwiki map, unify with
Sites and WikiMap]]: (Update?)
* Gabriel
** Working with [[User:BSitzmann (WMF)|BSitzmann]] on
[[Phab:T132597|T132597]] (RFC: Agree on endpoints for feeds)
* Roan
** T108655 [[phab:T108655|RFC: Standardise JavaScript interfaces]]: I
need to start the second part, but the recent comments have me
confused. I'll need to talk to Timo and figure out what the subject of
part two should be.
* RobLa
** Still need to schedule an RFC triage meeting outside of ArchCom-RFC time
*** Filed [[phab:T135674|T135674]], and made it clear that I'm not
going to be able to do this without some help.
** Created [[phab:project/manage/2002/|#ArchCom-Approved Phab tag]]
([[Phab:T133803|T133803]])
* Tim
** Not many updates with cscott out of office.  T89331 (Replace Tidy
in MW parser with HTML 5 parse/reserialize)
** T11 [[phab:T11|RFC: Introduce notion of DOM scopes in
wikitext]]: (Update?)
* Timo
** No update

= No activity in the last two weeks =

* T18691 [[phab:T18691|RFC: Section headings should have a clickable
anchor]] (Timo)
* T111588 [[phab:T111588|RFC: API-driven web front-end]] (Timo)
* T123753 [[phab:T123753|Establish retrospective reports for Security
and Performance incidents]] (RobLa)
* T122825 [[phab:T122825|Service ownership and minimum maintenance
requirements]] (Gabriel)
* T105766 [[phab:T105766|RFC: Dependency graph storage]] (Gabriel)
* T124504 [[phab:T124504|Transition WikiDev '16 working areas into
working groups]] (RobLa)
* T66214 [[phab:T66214|Use content hash based image / thumb URLs &
define an official thumb API]] (Brion)
* T91162 [[phab:T91162|RFC: Shadow namespaces]] (Brion)
* T128351 [[phab:T128351|RFC: Notifications in core]] (Brion)
* T122825 [[phab:T122825|Service ownership and minimum maintenance
requirements]] (Gabriel)
* T54807 [[phab:T54807|Identify and remove legacy preferences from
MediaWiki core]] (no shepherd)
* T88596 [[phab:T88596|Improving extension management]] (Daniel)

Our meeting for 2016-W21 (this coming Wednesday) will be a triage of
the ArchCom-RFC queue[3]

Rob
[1] ISO week 2016-W20: https://en.wikipedia.org/wiki/ISO_week_date
[2] https://www.mediawiki.org/wiki/Architecture_committee/Status
[3] https://phabricator.wikimedia.org/tag/archcom-rfc/

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] RFC: Add Content-Security-Policy header to MediaWiki

[Brian Wolff]

So the RFC process page says I should email wikitech-l to propose an RFC, thus:

Content-Security-Policy (CSP) header is a header that disables certain
javascript features that are commonly used to exploit XSS attacks, in
order to mitigate the risks of XSS. I think we could massively benefit
from using this technology - XSS attacks probably being the most
common security issue in MediaWiki. The downside is that it would
break compatibility with older user scripts.

Please see the full text of my proposal at
https://www.mediawiki.org/wiki/Requests_for_comment/Content-Security-Policy

The associated phabricator ticket is: https://phabricator.wikimedia.org/T135963

I'd appreciate any comments anyone might have.

Thanks,
Brian

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] [MediaWiki-announce] Security Release: 1.26.3, 1.25.6, and 1.23.14

[Chad]

I would like to announce the release of MediaWiki 1.26.3, 1.25.6 and
1.23.14.

These releases fix sixteen security issues in core, one issue in the bundled
extension SyntaxHighlight_GeSHi and one issue in the non-bundled
extension Scribunto.
Download links are given at the end of this email.

== Security fixes ==

* T122056: Old tokens are remaining valid within a new session
* T127114: Login throttle can be tricked using non-canonicalized usernames
* T123653: Cross-domain policy regexp is too narrow
* T123071: Incorrectly identifying http link in a's href attributes, due to
m modifier in regex
* T129506: MediaWiki:Gadget-popups.js isn't renderable
* T125283: Users occasionally logged in as different users after
SessionManager deployment
* T103239: Patrol allows click catching and patrolling of any page
* T122807: [tracking] Check php crypto primatives
* T98313: Graphs can leak tokens, leading to CSRF
* T130947: Diff generation should use PoolCounter
* T133507: Careless use of $wgExternalLinkTarget is insecure
* T132874: API action=move is not rate limited

This fix affects both core and SyntaxHighlight_GeSHi:
* T110143: strip markers can be used to get around html attribute escaping
in (many?) parser tags

These two fixes are not applicable to 1.23.14 as the 1.23 branch does not
contain pbkdf2 support.
* T116030: Increase pbkdf2 parameter strengths
* T127420: Pbkdf2Password does not check if hash_pbkdf2() succeeded

This fix is already in master and the 1.27 release branch, and is just being
backported to 1.23 and 1.25:
* T126685: Globally throttle password attempts

== Links to all mentioned tasks ==
https://phabricator.wikimedia.org/T122056
https://phabricator.wikimedia.org/T127114
https://phabricator.wikimedia.org/T123653
https://phabricator.wikimedia.org/T123071
https://phabricator.wikimedia.org/T129506
https://phabricator.wikimedia.org/T125283
https://phabricator.wikimedia.org/T103239
https://phabricator.wikimedia.org/T122807
https://phabricator.wikimedia.org/T98313
https://phabricator.wikimedia.org/T130947
https://phabricator.wikimedia.org/T133507
https://phabricator.wikimedia.org/T132874
https://phabricator.wikimedia.org/T110143
https://phabricator.wikimedia.org/T116030
https://phabricator.wikimedia.org/T127420
https://phabricator.wikimedia.org/T126685

== Release notes ==

Full release notes for 1.26.3:


Full release notes for 1.25.6:


Full release notes for 1.23.14:


For information about how to upgrade, see


**
   1.26.3
**
Download:
https://releases.wikimedia.org/mediawiki/1.26/mediawiki-1.26.3.tar.gz
https://releases.wikimedia.org/mediawiki/1.26/mediawiki-core-1.26.3.tar.gz

Patch to previous version:
https://releases.wikimedia.org/mediawiki/1.26/mediawiki-1.26.3.patch.gz

GPG signatures:
https://releases.wikimedia.org/mediawiki/1.26/mediawiki-1.26.3.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.26/mediawiki-1.26.3.patch.gz.sig
https://releases.wikimedia.org/mediawiki/1.26/mediawiki-core-1.26.3.tar.gz.sig

Public keys:
https://www.mediawiki.org/keys/keys.html

**
   1.25.6
**
Download:
https://releases.wikimedia.org/mediawiki/1.25/mediawiki-1.25.6.tar.gz
https://releases.wikimedia.org/mediawiki/1.25/mediawiki-core-1.25.6.tar.gz

Patch to previous version:
https://releases.wikimedia.org/mediawiki/1.25/mediawiki-1.25.6.patch.gz

GPG signatures:
https://releases.wikimedia.org/mediawiki/1.25/mediawiki-1.25.6.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.25/mediawiki-1.25.6.patch.gz.sig
https://releases.wikimedia.org/mediawiki/1.25/mediawiki-core-1.25.6.tar.gz.sig

Public keys:
https://www.mediawiki.org/keys/keys.html

**
   1.23.14
**
Download:
https://releases.wikimedia.org/mediawiki/1.23/mediawiki-1.23.14.tar.gz
https://releases.wikimedia.org/mediawiki/1.23/mediawiki-core-1.23.14.tar.gz

Patch to previous version:
https://releases.wikimedia.org/mediawiki/1.23/mediawiki-1.23.14.patch.gz

GPG signatures:
https://releases.wikimedia.org/mediawiki/1.23/mediawiki-1.23.14.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.23/mediawiki-1.23.14.patch.gz.sig
https://releases.wikimedia.org/mediawiki/1.23/mediawiki-core-1.23.14.tar.gz.sig

Public keys:
https://www.mediawiki.org/keys/keys.html

-Chad H. & Chris S.
___
MediaWiki announcements mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce

Re: [Wikitech-l] update: wikipedia.org portal

[MZMcBride]

rupert THURNER wrote:
>ah, interesting. moving this to git sounds ok to me from a technical
>viewpoint. i read
>https://www.mediawiki.org/wiki/Wikipedia.org_Portal/Migration_to_gerrit.
>despite that i am not clear how the current portal maintainers would
>then activate a proposal e.g. from the discovery team?

It turns out that the other portals were quietly moved to Git in November
2015. I filed  about cleaning
up the project portals, since they're now being updated in two places, one
of which is a decoy, and the various wiki pages on Meta-Wiki don't seem to
reflect or acknowledge this at all.

MZMcBride



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Discovery Weekly Update for the week starting 2016-05-16

[Chris Koerner]

Hi,
Here is this week's update from the Discovery department.

* A Wikipedia.org survey was run from May 10 - 17, 2016 to determine how
visitors arrived at the portal page. Survey results here. [1]
* A Wikipedia.org production release was done on May 18, 2016 which added
descriptive text to the sister wiki project links. [2]
* WikiVoyage experimental map with custom layers. [3]
* Analysis was done for the Portal A/B test for the addition of descriptive
text to the sister wiki project links. [4]
* Deb will be coordinating with User Research team to get interviews setup
for survey responders that want to talk about how they use the wikipedia
portal.

[1]
https://commons.wikimedia.org/wiki/File:Wikipedia_Portal_Survey_-_May_2016.pdf
[2]
https://www.mediawiki.org/wiki/Wikipedia.org_Portal_A/B_testing#A.2FB_test:_adding_descriptive_text_to_sister_.28other.29_project_links
[3]
https://en.wikivoyage.org/wiki/Wikivoyage:Travellers%27_pub#Maps_with_extra_layers_on_en-Wikivoyage
[4]
https://commons.wikimedia.org/wiki/File:Descriptive_Text_for_Sister_Project_Links_Wikipedia_Portal_AB_Test.pdf



Feedback and suggestions on this weekly update are welcome!

The full update, and archive of past updates, can be found on Mediawiki.org:

https://www.mediawiki.org/wiki/Discovery/Status_updates

-- 
Yours,
Chris Koerner
Community Liaison - Discovery
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] update: wikipedia.org portal

[rupert THURNER]

MZMcBride wrote:
> rupert THURNER wrote:
>>quim, i would not be angry if you would show a little bit more empathy
>>towards a client, a volunteer. if mzmcbride is right and there is a
>>well established procedure to change this page which was not followed,
>>the person not following might read the "expected behaviour" page.
>
> Project portals such as www.wikipedia.org were managed on Meta-Wiki:
> . I believe most of the
> portals continue to be managed on Meta-Wiki, with the exception of
> www.wikipedia.org; background: .

ah, interesting. moving this to git sounds ok to me from a technical
viewpoint. i read
https://www.mediawiki.org/wiki/Wikipedia.org_Portal/Migration_to_gerrit.
despite that i am not clear how the current portal maintainers would
then activate a proposal e.g. from the discovery team?

rupert

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l