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