On Sun, Jan 1, 2017 at 11:44 PM, Alex Harui <aha...@adobe.com> wrote:
> > > 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 AngularJS: https://docs.angularjs.org/api/ng/directive/ngBindHtml (By default the HTML is loaded in a secure way, i.e. sanitization is attempted) Jquery: https://api.jquery.com/jquery.parsehtml/ (By default, Jquery does not run scripts in the parsed HTML) React: https://facebook.github.io/react/docs/dom-elements.html (No sanitization(yet) , but you have to explicitly use the api called: dangerouslySetInnerHTML) > and have wrapped the > innerHTML setter on all HTMLElements? > Yes, you can do this with direct javascript. But this is exactly why people use frameworks. i.e. a framework is supposed to protect users from shooting themselves in their foot. > > 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 > > >
