Yes. Why do you include innerText? AFAIK innerText is safe. (Although textContent usually makes more sense.)
> On Dec 12, 2021, at 12:02 PM, Edward Stangler <estang...@bradmark.com> wrote: > > > OK, that make sense. > > If you use innerHTML / innerText inside Royale, then you need to sanitize. > > (And whatever equivalent for "src" / "url" and other such areas.) > > > > On 12/12/2021 3:32 AM, Harbs wrote: >>> If I set a string variable (i.e. title of a movie) to an unsafe value, >>> and then some class in Royale--written by someone else--uses that value >>> within some HTML that they then assign to an innerHTML, how am I protected? >> I’m saying we should have a policy that it will not be written as innerHTML. >> If there’s some overpowering reason to use innerHTML then it should be >> sanitized. >> >> There’s very little reason to use innerHTML in Royale framework code. >> >> That’s precisely why I wrote that list. Unless I’m mistaken the only places >> that we need to address something in the framework is: >> >> ImageAndTextButton >> Flat DropDownList >> Jewel SnackbarView >> Spark ButtonBase >> Spark DropDownListButton >> >> >>> On Dec 12, 2021, at 10:44 AM, Edward Stangler wrote: >>> >>> >>> I guess I'm confused. >>> >>> If I set a string variable (i.e. title of a movie) to an unsafe value, >>> and then some class in Royale--written by someone else--uses that value >>> within some HTML that they then assign to an innerHTML, how am I protected? >>> >>> That is, I set a string variable not knowing that it would be used in an >>> innerHTML, and the Royale developer didn't sanitize. >>> >>> >>> >>> On 12/12/2021 2:33 AM, Harbs wrote: >>>>> If I need to prove (to the best of my ability) that my app is protected >>>>> against XSS with regards to innerHTML / innerText, how am I supposed to >>>>> do this? >>>> I think we should have a guarantee that the framework will not insert >>>> unsanitized HTML without the knowledge of the developer. >>>> >>>> That was why I audited every use of innerHTML. >>>> >>>> I have been trying to get an answer to what others think a danger is, but >>>> I have no gotten a clear answer yet. >>>> >>>> Here’s my thoughts: >>>> >>>> 1. The framework should not surprise the developer. If the developer did >>>> not use innerHTML, their app should be safe on that front. >>>> 2. The framework should not set “src” without the knowledge of the >>>> developer either. >>>> 3. If we identify other sources for XSS attacks, we should address that >>>> too. >>>> 4. For code that’s compiled from MXML or AS, there’s no danger of XSS >>>> attacks, so there’s no need to sanitize code there. So any use of >>>> innerHTML and the like or src and the like is safe. >>>> 5. We should provide easy methods for sanitizing string which might come >>>> from an unsafe source. The developer should know if they are using >>>> potentially dangerous sources. >>>> 6. If the developer does not use innerHTML, html or htmlText, setting text >>>> values even from non-safe sources should be safe. >>>> 7. If the developer does want to use one of the html setters, they should >>>> call foo.html = sanitizeHTML(badSource); That responsibility should be on >>>> the developer’s shoulders. They are the only one who knows if they are >>>> setting from an outside source and removing all the sharp knives from the >>>> drawer is not our job IMO. >>>> 8. Setting url sources are called either “src” or “url”. Unless a >>>> developer calls one of these setters, we should have a similar guarantee >>>> to innerHTML. >>>> 9. Again, coming from MXML and AS, there’s no danger setting src. The >>>> exception to this would be for bound values. If a URL might be coming from >>>> an untrusted source, the value should be set using sanitizeUrl(unsafeUrl). >>>> 10 I don’t know if there’s any danger when it comes to setting styles. If >>>> someone can identify issues there, that should be addressed similarly. >>>> >>>> This should make it very straight-forward to audit an app to see if >>>> there’s potential XSS dangers and not penalize the performance of the vast >>>> majority of apps that don’t have these issues. I cannot figure out how >>>> unsafe html can possibly get into any of my apps. I’d love to hear >>>> thoughts on where/when/how such risks might arise. >>>> >>>> Thanks, >>>> Harbs >>>> >>>>> On Dec 11, 2021, at 12:26 AM, Edward Stangler wrote: >>>>> >>>>> >>>>> If I need to prove (to the best of my ability) that my app is protected >>>>> against XSS with regards to innerHTML / innerText, how am I supposed to >>>>> do this? >>>>> >>>>> There are three possible protectors (normally): >>>>> >>>>> a. The browser. The browsers will not able to do this automatically, >>>>> even with proposed standards. >>>>> b. The framework. >>>>> c. The application code. >>>>> >>>>> With Label, for example, currently only htmlText = S will use >>>>> innerHTML. But there could be a multitude of other APIs that eventually >>>>> cause framework code to set innerHTML. It seems a monumental effort for >>>>> the developer to grep for all possible API calls that might somehow end >>>>> up doing an innerHTML = X in the framework, perhaps after layers and >>>>> layers of calls. (And the developer may not be familiar with the app >>>>> code, either.) >>>>> >>>>> That leaves the framework. Seems pretty easy to grep for all uses of >>>>> innerHTML / innerText to validate it. >>>>> >>>>> (And application code that uses innerHTML / innerText directly can be >>>>> validated like that, too, of course.) >>>>> >>>>> >>>>> Browsers are going to have HTML Sanitizer API some day: >>>>> >>>>> https://developer.mozilla.org/en-US/docs/Web/API/HTML_Sanitizer_API >>>>> >>>>> How is the application code suppose to even use this, if the framework >>>>> doesn't have a hook? You really want to force apps to do >>>>> sanitizeFor(...).innerHTML? That will cause double-parsing (since the >>>>> framework eventually does innerHTML = X on that value) and potential >>>>> side-effects if the two parses don't match due to context. >>>>> >>>>> >>>>> As for use cases, if something like Label or UITextField or such is used >>>>> in a List, and dataProvider comes from remote data, I would think it's >>>>> pretty easy to get into trouble if someone where to use htmlText = S for >>>>> display. But that's just theoretical. >>>>> >>>>> I'm actually not very familiar with how often the htmlText property is >>>>> used in the libraries. I see that MX LegendItem seems to use it, but >>>>> maybe that's an outlier. >>>>> >>>>> >>>>> But htmlText is not the only place where innerHTML / innerText might be >>>>> used, so I don't want to focus just on that. You don't know what Royale >>>>> contributors might use innerHTML / innerText for in the future, but you >>>>> could insist that they always call the sanitizer hook. >>>>> >>>>> >>>>> >>>>> >>>>> On 12/10/2021 4:27 AM, Harbs wrote: >>>>>> Sanitizing what? And why? >>>>>> >>>>>> What is the use case which is “dangerous”? >>>>>> >>>>>>> On Dec 10, 2021, at 11:49 AM, Edward Stangler 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. >> >
