AIUI, the suggestion is to default to sanitizing before writing to innerHTML so
that someone who does let someone type in "anything" and shoves it into a
Label's htmlText won't have their app used to run various exploits.
If a volunteer can propose a design that defaults to sanitizing and can easily
be removed leaving very little unused code so that it can be effectively PAYG,
I would not veto it. That design might include removing the htmlText property
on Basic Label unless someone is already using it. I only put it in there for
Flash equivalence, but isn't really a PAYG thing to do if nobody is using it.
MX Label really only needs to support the Flash HTML subset, so might not need
a third-party sanitizer.
HTH,
-Alex
On 12/10/21, 2:26 AM, "Harbs" <harbs.li...@gmail.com> wrote:
Sanitizing what? And why?
What is the use case which is “dangerous”?
> On Dec 10, 2021, at 11:49 AM, Edward Stangler <estang...@bradmark.com>
wrote:
>
>
> My mistake.
>
> Definitely should be sanitizing. If you want PAYG, then make it default
> (some global function) and something that can be overridden by those who
> want to live dangerously.
>
>
> On 12/10/2021 3:07 AM, Harbs wrote:
>>> It looks to me that most uses of innerHTML in Royale are assigning text
>>> to various labels (like Button).
>> I’m not sure which case you’re referring to.
>>
>> Ignoring examples, ASDoc and RoyaleSite, here is every use of innerHTML
in the framework with comments:
>>
>> HTMLText -- A component created specifically for applying innerHTML. It
would generally be used in mxml where the content would be provided by the
develper
>> ImageAndTextButton -- Uses innerHTML to combine text and and img tag. I
guess it could be safer if it would use Image and TextNode elements.
>> Label -- has an html getter/setter which is clearly for markup so
innerHTML is necessary.
>> LoadIndicator -- uses innerHTML, but the markup is generated internally
and not exposed, so not a risk.
>> TextButton -- has an html getter/setter which is clearly for markup so
innerHTML is necessary. It has a separate text getter/setter which *does not*
use innerHTML
>> UnselectableElementBead -- uses self-generated innerHTML for setting a
style. Not a risk.
>> addDynamicSelector -- uses innerHTML for setting a style but only the
first time it's used. Should not be a risk.
>> InspireTreeIconBead -- similar to UnselectableElementBead
>> Flat DropDownList -- uses innerHTML in six places. I don't know why.
>> Graphics -- uses innerHTML for self generated markup. Not a risk.
>> TextNodeContainerBase has an innerHTML getter/setter because it's
emulating the corresponding HTML elements.
>> InnerHTML -- is (as its name suggests) a component for setting innerHTML.
>> Jewel Button -- has an html getter/setter which is clearly for markup so
innerHTML is necessary. It has a separate text getter/setter which *does not*
use innerHTML
>> Jewel Label -- has an html getter/setter which is clearly for markup so
innerHTML is necessary. It has a separate text getter/setter which *does not*
use innerHTML
>> Jewel SnackbarView uses innerHTML for the "message". I don't know why.
>> MX Button -- I found it used innerHTML which should have been
textContent. Fixed.
>> MX Label -- has htmlText getter/setter which is clearly for markup so
innerHTML is necessary.
>> MX TinyEditor -- has htmlText getter/setter which is clearly for markup
so innerHTML is necessary.
>> MX UITextField -- has htmlText getter/setter which is clearly for markup
so innerHTML is necessary.
>> MX UITextFormat -- uses innerHTML for measuring. Should be safe.
>> Spark ButtonBase -- uses innerHTML. I don't know why.
>> Spark DropDownListButton -- uses innerHTML to draw the skin. The label
is part of that. It's possible that should be sanitized.
>> TextLine -- uses innerHTML in two places where textContent could likely
be used, but the string it's using came from textContent, so it should not be a
risk.
>>
>> Summary:
>> Ones which could use looking into:
>> ImageAndTextButton
>> Flat DropDownList
>> Jewel SnackbarView
>> Spark ButtonBase
>> Spark DropDownListButton
>>
>> I’m not personally very familiar with either Jewel or the Spark
components, so someone else should comment on those.
>>
>> The other risky area in HTML is setting “src” for Image tags and the
like.
>>
>> We’re not sanitizing that, but again, I’m not sure what the attack would
be.
>
