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