If you want your head to hurt, you can try reading this whole page on avoiding XSS:
https://cheatsheetseries.owasp.org/cheatsheets/XSS_Filter_Evasion_Cheat_Sheet.html The numbers of ways to insert XSS is mind boggling. > On Dec 9, 2021, at 1:01 AM, Greg Dove <greg.d...@gmail.com> wrote: > > That's all I meant also. I expect the React framework minimizes or avoids > use of it for example. I have no idea (I haven't checked) if it 'sanitizes' > any use of it that it has internally, filtering out possible bad stuff in > setters, for example. > > Using that 'dangerouslySetInnerHTML' or whatever it is, is actually quite > rare in React. It is still an option (as well as being a reminder) for > users. I wasn't meaning that we try to do the same for that, just that the > framework itself should pass some sort of scrutiny against what is > acceptable as 'normal' in terms of being secure. Sounds like you have > already looked into that, thanks! > > > > > On Thu, Dec 9, 2021 at 11:46 AM Harbs <harbs.li...@gmail.com> wrote: > >> I went though every use of innerHTML and I only found two that really >> could use changing. I just changed those two cases. >> >> I’m not convinced that it’s the job of the Framework to prevent users from >> introducing XSS attacks. The framework should not use things like innerHTML >> of setting src in ways that is not obvious to the user, but we shouldn’t be >> preventing the users from doing it themselves. >> >> My $0.02, >> Harbs >> >>> On Dec 8, 2021, at 8:39 AM, Yishay Weiss <yishayj...@hotmail.com> wrote: >>> >>> In previous threads on the same topic documentation was cited as >> something holding us back from calling it a 1.0. >>> >>> There’s also the marketing issue. From what I see, the active members of >> this community are not keen to take on marketing challenges, and this may >> not change in the foreseeable future, but ideally we would want to create >> some sort of buzz, and be ready to face questions following that. Silently >> bumping to 1.0 may be the best we can do at this point though… >>> >>> The reason I brought up 1.0 on this thread was to decide what version >> the mvn snapshots will show after 0.9.9. Should we just vote on that? >>> >>> Also, it would be good to pass on some of the knowledge I have gained in >> previous releases to others here, so this is an opportunity for volunteers >> to step up. >>> >>> From: Harbs<mailto:harbs.li...@gmail.com> >>> Sent: Tuesday, December 7, 2021 10:15 PM >>> To: dev@royale.apache.org<mailto:dev@royale.apache.org> >>> Subject: Re: 0.9.9 >>> >>> It’s a bit of a stretch that it’s a concern because even where it’s >> used, the source is not typically going to be an outside source. I wouldn’t >> consider it an obstacle for “1.0”, but we should address it. >>> >>>> On Dec 7, 2021, at 10:11 PM, Greg Dove <greg.d...@gmail.com> wrote: >>>> >>>>> That said, we’re using innerHTML in some places in the Framework where >> it >>>> is not necessary. That should be fixed. >>>> >>>> Yeah, that's actually what I was meaning. I don't know if there are any >>>> other things like this which we might have overlooked, or whether it is >>>> critical to consider these for '1.0' >>>> >>>> >>>> >>>> >>>> On Wed, Dec 8, 2021 at 9:00 AM Harbs <harbs.li...@gmail.com> wrote: >>>> >>>>> In React, there’s a desire to set innerHTML because things are hard to >> do >>>>> there. In Royale, not so much. >>>>> >>>>> That said, we’re using innerHTML in some places in the Framework where >> it >>>>> is not necessary. That should be fixed. >>>>> >>>>>> On Dec 7, 2021, at 9:36 PM, Greg Dove <greg.d...@gmail.com> wrote: >>>>>> >>>>>> We discussed at one point the potential security risks associated with >>>>>> using innerHTML in some code, for example and that other frameworks >> avoid >>>>>> that (React requires that a dev use a method called >>>>> dangerouslySetInnerHTML >>>>>> or something like that). >>>>> >>>>> >>> >> >>
