Closure's sanitizer was originally based on Google Caja sanitizer. It looks like Angular DomSanitizer was also based on Caja's or Closure's. All of them are whitelist-style sanitizers.
It looks to me that most uses of innerHTML in Royale are assigning text to various labels (like Button). Is it intentional that labels can contain arbitrary HTML, or even basic visual markup? Or should most/all of them use textContent instead? (innerText would be insufficient to secure this, but could be used as an intermediate solution, I guess, to retain basic visual markup.) On 12/9/2021 10:14 AM, Harbs wrote: > 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 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
