On 1/2/17, 9:38 AM, "omup...@gmail.com on behalf of OmPrakash Muppirala" <omup...@gmail.com on behalf of bigosma...@gmail.com> wrote:
>On Jan 2, 2017 9:06 AM, "Alex Harui" <aha...@adobe.com> wrote: > >Are you saying that Angular and Jquery have ways of preventing you from >writing to innerHTML directly? Otherwise it is opt-in. You must use the >APIs they offer. > > >No, you cant do that unless you can change the way html/javascript works. > >If you use their framework APIs, security us opt-out by default. So, if I understand correctly, you have to opt-in to using their secure APIs right? I'm totally fine with us providing secure components and APIs that composite a trusted API surface with some security checking and recommending that folks use the secure version by default. Then those that are in trusted environments can skip the extra code. > > >The goal for me is to implement basic security features in FlexJS. I dont >want to adhere to an ideology blindly. There are going to be execeptions >to the pay as you go philosophy and basic security is one of them. I don't see any advantage to not implementing what you want in a PAYG way. How would folks opt-out and not carry or run that code? Opt-out in FlexJS is supposed to be done by changing the list of beads or changing to a lighter weight component set. I don't think that conflicts with what you want to do. > > > >Or is the goal to be able to make your app easier to analyze by some of >these penetration testing tools? > > > >And then what? This insecure, unsanitized html capabilities will be one >of >the first things caught by any decent pen-test tools. I was just trying to understand your goals. Remember that for the wrapping components (not for folks writing directly against the typedefs APIs), we can present just about any API we want. Right now there is no innerHTML property available on the wrapping components so folks cannot screw themselves over by directly slapping some un-sanitized HTML into one of our containers, but they probably can do so for Label and Button. Sounds like you are building a component that does allows for HTML in our containers which is fine. But besides standard sanitization, we could go even further if you want and explore having HTML be an actual type in our framework. Then you can't just assign a string to the html property of various widgets. And that might make for even better security or analysis of the security of an application. The web services might return an UnsecuredHTML if the request is cross-domain or something like that. IOW, we really can block direct access to innerHTML if we want to. > > >Whatever the goal, it doesn't seem right to me to try to sanitize in >HTMLText or Label. IIRC, my training is to check people at the door and >trust them after instead of having everyone check every person they talk >to before they talk to them. Once the bad person/data is in the door, it >is too late. > > >Lets agree to to diaagree here. Let me add the code and then we can >review/discuss at that point. > > >Can you bug your security team and see if they think an HTMLText widget is >the right place, or have you already checked with them? > > >No, I have not. But from my discussions with them in the past, this is a >vector for XSS attacks and they would be interested in having basic >protection by default. Other frameworks do this because they got dinged >in >the past. > I can check with my security folks, but I suspect they will first ask: "how did that HTML get into the app in the first place?" And the answer will be that someone typed it in, or it came in via a web service. And they will say that that is where the sanitization should take place. It doesn't make sense to me to have an HTTPService return a result that needs to go into two HTMLText widgets and have the sanitization run twice as it goes into each widget. Seems like you could create an HTMLSanitizerBead that goes on the HTTPService strand and sanitizes the results. Then create a component set with that bead baked in. For the team page, since it uses a small static "database", really some other tool should sanitize it prior to deployment. But in other cases, where the web service result is "deserialized" into ValueObjects is where the sanitization should occur. That's what I mean by checking people at the door. My 2 cents. I'd love to hear what others think. -Alex
