On Sun, Jan 1, 2017 at 10:18 PM, Alex Harui <aha...@adobe.com> wrote:
> > > On 1/1/17, 1:15 AM, "omup...@gmail.com on behalf of OmPrakash Muppirala" > <omup...@gmail.com on behalf of bigosma...@gmail.com> wrote: > > > > >Hmm, to play the devil's advocate, security should not be pay-as-you-go. > >This should be opt-in by default. Someone will have to go the extra mile > >to turn it off. > > > >This is the sort of thing that will go out in the wild and folks will get > >affected by it soon enough. We will then need to push out an emergency > >release to fix an XSS attack made possible by FlexJS. > > > >Either that or we call the default implementation 'InsecureHTMLText' or > >something like that. > > Well, the article you posted specifically mentions "sanitizing any HTML > code submitted by a user." > > IMO, that is different from HTML code entered by a developer or sucked in > from a database. There are other opportunities to sanitize that non-user > HTML that won't have runtime performance issues. > We don't always have control over the database from which the html snippet is loaded from. Heck, I have access to flex.apache.org and I don't even know if the HTML in team.json has any insecure tags/js code. Also, if I am going to load data from a third party web resource, I better sanitize any HTML they throw at me. They might not have diligently cleaned every html snippet. For example, I might create an app that shows movie showtimes, user reviews and let them buy tickets. The movie showtimes comes from Fandango's REST APIs and the reviews come from RottenTomatoes' REST APIs. If RottenTomatoes does not sanitize their user entered reviews and saves them as HTML and we consume it, we will be putting our app at risk. This may seem like an uncommon usecase to you right now. But at work, I have an app sec team that routinely does penetration tests against every third party open source code we use. These sort of insecure features get flagged and we are blocked from using that framework/library until that issue has been publicly resolved. I can imagine several other companies being so strict about security of their web apps. > > Also, the article mentions there being more than one way to sanitize, so > we should let folks choose what to use and when to use it. > Or am I missing something? > We should have a default approach that satisfies most common scenarios. Of course, folks are welcome to add their own sanitizing logic by extending the base component. Thanks, Om > > -Alex > >
