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