Can we do special handling at compile time? React can't do this but we can. If we detect <script> tags we can filter that or throw some warning or error.
just my 2.... El lun., 16 mar. 2020 a las 8:45, Alex Harui (<[email protected]>) escribió: > > > On 3/16/20, 12:34 AM, "Harbs" <[email protected]> wrote: > > My thoughts: > > 1. We should avoid the use of innerHTML in framework code as much as > possible. > > IMO, we only really need to avoid unfiltered writes to innerHTML. You > should be able to read it. If a component writes it in a way that cannot > be modified, it should be fine, but writing <img src=" + imageURL + "/> is > not. > > 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. > > OK, but how? Compiler warning? Remove innerHTML from the APIs? Use > "dangerouslySetInnerHTML" like React? Always filter? > > 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. > > I didn't understand #3. > > FWIW, I agree we should agree on how we treat innerHTML. I'm done for > today, so will check tomorrow if there is more discussion. > > -Alex > > > 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Freactjs.org%2Fdocs%2Fdom-elements.html%23dangerouslysetinnerhtml&data=02%7C01%7Caharui%40adobe.com%7Cef849844168d4efeb06008d7c97c73de%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637199408666302957&sdata=RKArCFPOK%2FLm45yyHOHe6dl1XtntRsmefL5bPfo0R6w%3D&reserved=0 > > > > -- Carlos Rovira http://about.me/carlosrovira
