> 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 <estang...@bradmark.com> 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.
