I’m not following what your attack vector is. I don’t think security is an afterthought. I’m struggling to see what the attack vector would be in a Royale app and what you are proposing we should protect.
Can you give me some examples and what you think needs to be changed? > On Dec 9, 2021, at 6:32 PM, Kessler CTR Mark J > <mark.kessler....@usmc.mil.INVALID> wrote: > > I like the fact that the Closure library has those, but those are optional. > > We have our own mechanisms already in our private libraries because the > Royale SDK had no consideration for it. Security should not be an > afterthought, and by not defaulting to having some form of security baked in > by default we are contributing to the global problems of it. We cannot > expect newer developers to follow things like OWASPs top [1], and they will > not see a need for it until there is an incident. > > [1] https://owasp.org/www-project-top-ten/ > > > -Mark K > > -----Original Message----- > From: Harbs <harbs.li...@gmail.com> > Sent: Thursday, December 9, 2021 11:13 > To: dev@royale.apache.org > Subject: [Non-DoD Source] Re: 0.9.9 > > I just went poking around and I found that Google Closure has a pretty > extensive library for sanitizing HTML: > https://github.com/google/closure-library/tree/master/closure/goog/html/sanitizer > > Considering we’re already using the goog libs for other things, it should be > fairly straight-forward to wrap the functionality in Royale classes. Feel > free to work on that… ;-) > > I do think that the sanitizing should be opt-in. > > Harbs > >> On Dec 9, 2021, at 5:03 PM, Kessler CTR Mark J >> <mark.kessler....@usmc.mil.INVALID> wrote: >> >> I am on the opposite spectrum of this opinion. We had to write our own >> library on-top of the basic Royale for our applications that was more >> security minded. All of our defaults are for innerText as it will not >> interpret the contents or use new variants that already have security built >> it such as a textarea's "value" has security considerations by default now. >> This is important as cybersecurity teams or software tests can easily show >> basic XSS in fields either reflected or stored. Remember the end users are >> the ones that are directly affected by vulnerabilities built into a web >> application and a developer that does not follow good sanitization practices >> will surely allow easily preventable vulnerabilities in. >> >> We should always have secure defaults, but allow developers to violate good >> security practices on their own as a conscious decision. >> >> >> -Mark K >
