[Wikitech-l] Re: New developer feature: $wgUseXssLanguage / x-xss language code

[Lucas Werkmeister]

I’d also like to discourage the Mustache “.” feature (“current context”, as
in {{#html-items}}{{{.}}}{{/html-items}}), at least in unescaped HTML (i.e.
{{{.}}}) but perhaps also in escaped HTML ({{.}}) – it made one of the
related issues much harder to debug for me, because I couldn’t even find
the template that was using the unescaped variable. (Admittedly, part of
this was just because I didn’t know this feature existed.)

Am Fr., 29. Sept. 2023 um 21:55 Uhr schrieb Bartosz Dziewoński <
matma@gmail.com>:

> On 2023-09-29 19:55, bawolff wrote:
> > This is clearly yielding some interesting results.
> >
> > One of the patterns i've noticed is that several of the examples seem to
> > involve mustache templates. I think there are two reasons for this:
> >
> > * mustache templates cannot currently be checked by phan-taint-check
> > * Because they are a separate file, the escaping is now fairly far away
> > from the context where the variable is used. Its easy to lose track of
> > if a specific variable is supposed to be escaped between the template
> > file and the call into TemplateProcessor.
>
> Let's not go too easy on Mustache, there are several more reasons why
> these templates are full of security gaps:
>
> * Escaping or failing to escape HTML is the difference between {{ }} and
> {{{ }}}, and unless you spent your whole life writing Mustache
> templates, you won't remember which is which.
>
> * Mustache has no concept of HTML structure, or any structure, or
> variable types; it just concatenates strings, so it's difficult to
> automatically detect any problems.
>
>
> > Anyways, i'd like to propose a naming convention. Any mustache variable
> > that is used as raw html should have some sort of easily identifiable
> > prefix so it is easy to keep track of which parameters are escaped and
> > which are not. e.g. instead of naming the parameter foo, it would be
> > named something like HTMLFoo.
>
> We already do this, at least! Most Mustache variables used as raw HTML
> are prefixed with 'html-'. Vector is pretty consistent about this [1],
> but even it has some exceptions. Other code is not all so good.
>
> [1]
>
> https://codesearch.wmcloud.org/search/?q={{{=\.mustache%24==Skin%3AVector
> 
>
>
> --
> Bartosz Dziewoński
> ___
> Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
> To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
> https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/



-- 
Lucas Werkmeister (he/er)
Software Engineer

Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Phone: +49 (0)30-577 11 62-0
https://wikimedia.de

Imagine a world in which every single human being can freely share in the
sum of all knowledge. Help us to achieve our vision!
https://spenden.wikimedia.de

Wikimedia Deutschland — Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Charlottenburg, VR 23855 B.
Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin,
Steuernummer 27/029/42207.
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] Re: New developer feature: $wgUseXssLanguage / x-xss language code

[Bartosz Dziewoński]

On 2023-09-29 19:55, bawolff wrote:

This is clearly yielding some interesting results.

One of the patterns i've noticed is that several of the examples seem to 
involve mustache templates. I think there are two reasons for this:


* mustache templates cannot currently be checked by phan-taint-check
* Because they are a separate file, the escaping is now fairly far away 
from the context where the variable is used. Its easy to lose track of 
if a specific variable is supposed to be escaped between the template 
file and the call into TemplateProcessor.


Let's not go too easy on Mustache, there are several more reasons why 
these templates are full of security gaps:


* Escaping or failing to escape HTML is the difference between {{ }} and 
{{{ }}}, and unless you spent your whole life writing Mustache 
templates, you won't remember which is which.


* Mustache has no concept of HTML structure, or any structure, or 
variable types; it just concatenates strings, so it's difficult to 
automatically detect any problems.



Anyways, i'd like to propose a naming convention. Any mustache variable 
that is used as raw html should have some sort of easily identifiable 
prefix so it is easy to keep track of which parameters are escaped and 
which are not. e.g. instead of naming the parameter foo, it would be 
named something like HTMLFoo.


We already do this, at least! Most Mustache variables used as raw HTML 
are prefixed with 'html-'. Vector is pretty consistent about this [1], 
but even it has some exceptions. Other code is not all so good.


[1] 
https://codesearch.wmcloud.org/search/?q={{{=\.mustache%24==Skin%3AVector



--
Bartosz Dziewoński
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] Re: New developer feature: $wgUseXssLanguage / x-xss language code

[bawolff]

This is clearly yielding some interesting results.

One of the patterns i've noticed is that several of the examples seem to
involve mustache templates. I think there are two reasons for this:

* mustache templates cannot currently be checked by phan-taint-check
* Because they are a separate file, the escaping is now fairly far away
from the context where the variable is used. Its easy to lose track of if a
specific variable is supposed to be escaped between the template file and
the call into TemplateProcessor.

Anyways, i'd like to propose a naming convention. Any mustache variable
that is used as raw html should have some sort of easily identifiable
prefix so it is easy to keep track of which parameters are escaped and
which are not. e.g. instead of naming the parameter foo, it would be named
something like HTMLFoo.

Thoughts?
--
Brian


On Thu, Sep 28, 2023 at 9:01 AM Lucas Werkmeister <
lucas.werkmeis...@wikimedia.de> wrote:

> Hi all! This is an announcement for a new developer feature in MediaWiki.
> If you don’t develop MediaWiki core, extensions or skins, you can stop
> reading :)
>
> MediaWiki interface messages are generally “safe” to edit: when they
> contain markup, it is either parsed (as wikitext), sanitized, or fully
> HTML-escaped. For this reason, administrators are allowed to edit normal
> messages on-wiki in the MediaWiki: namespace, while editing JS code (which
> is more dangerous) is restricted to interface administrators. (A few
> exceptions, messages that are not escaped and which can only be edited by
> interface administrators, are configured in $wgRawHtmlMessages
> .)
> Occasionally, a bug in the software means that a message isn’t properly
> escaped, which can in theory be abused by administrators to effectively
> gain interface administrator powers (by editing a MediaWiki: page for a
> message to contain 

[Wikitech-l] Re: New developer feature: $wgUseXssLanguage / x-xss language code

[Yaron Koren]

>
> If the developer setting $wgUseXssLanguage is set to true, then an “x-xss”
> language code becomes available and can be selected with *?uselang=x-xss*
> in the URL. When using this language code, all messages become “malicious”:
> every message is replaced by a snippet of HTML that tries to run alert('
> *message-key*').


Clever feature - this will be great for testing. Thank you!

-Yaron

-- 
WikiWorks · MediaWiki Consulting · http://wikiworks.com
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/