My thoughts: 1. We should avoid the use of innerHTML in framework code as much as possible. 2. We should discourage the use of it in application code, although I think it’s not going to be very heavily used in general in Royale no-matter. 3. We are using innerHTML in parsing MXML and innerHTML is one of the default MXML properties. This seems to be safe as it's compile-time.
Harbs > On Mar 16, 2020, at 7:17 AM, Greg Dove <[email protected]> wrote: > > Before I forget, I believe we need to have a discussion about the use of > innerHTML inside the framework before we get to 1.0 release. A few of us > discussed this briefly in Slack a couple of months back, and we decided it > needed shared input/scrutiny on list. I'm only raising it here to achieve > that. > > Replying to this > I'm suggesting this needs attention, but I don't have any simple answer. > Please share your thoughts/ideas. > > Why does it need scrutiny? > While I can't see a direct security risk (it seems the main risk is in > combination with other things), it is considered at least a weak point, and > it sounds like it would probably cause a fail in a security audit of an > application. Aside from that, if there is real risk then it could affect > Royale's reputation, or that of Apache. > I think we are using innertHTML at various depths in a number of different > places from a quick 'search in files'. If values for setting these could > come from externally created strings that are not filtered for security > risks (e.g. <script> tags), then I think those would be the areas of > concern in a security audit. > > Others > I already know what React does for this, but I did not look elsewhere, so I > don't know what other frameworks do. With React they make it possible to > use innerHTML, but doing so in itself is a very clear reminder that it is > not a great thing to do. > See here : > https://reactjs.org/docs/dom-elements.html#dangerouslysetinnerhtml
