Sorry for my delay, the use cases is based on not allowing unsanitized input 
from either the user, a request property, or server response. Generally 
speaking XSS is an injection style exploitation.

2 main types of XSS:

1. Reflected: happens when information from a user or request property is not 
sanitized and used in things like popups or assigned to display elements like 
might occur when trying to return an error message to the end user with a 
portion of their input.  Can also be DOM based.

2. Stored: This type is generally when a server has stored a value that 
contains the exploit and sends it clients later on.  This one is more serious 
as it could affect multiple users at once. Imagine something more akin to 
blogging where one person posts an article and then all the people who visit it 
later to read the article that triggers the exploit.


My compromise of a recommendation is that properties like the TEXT getters / 
setters or similar properties automatically use the sanitizer methods before 
assigning the new values to the element.  I feel like that would still allow 
some manual formatting if designed, but we would have done our due diligence / 
due care.


Thoughts?


-Mark K

-----Original Message-----
From: Harbs <harbs.li...@gmail.com>
Sent: Friday, December 10, 2021 05:26
To: dev@royale.apache.org
Subject: [Non-DoD Source] Re: Sanitizing HTML (was Re: 0.9.9)

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.
>

Reply via email to