On 1/1/17, 11:35 PM, "omup...@gmail.com on behalf of OmPrakash Muppirala" <omup...@gmail.com on behalf of bigosma...@gmail.com> wrote:
>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. Which popular JS frameworks have builtin sanitization and have wrapped the innerHTML setter on all HTMLElements? This is not how I was trained to handle these scenarios, but maybe things have changed since I last went through security training. IIRC, you are supposed to sanitize the HTML on its return from the database/web service or when the user submits the input, not when you pass it on to the UI widgets. -Alex
