Re: Comments on the Triple Patterns Fragments draft

On Tuesday 14. October 2014 13.48.32 Luca Matteis wrote:
> > Such attacks are
> > discussed in the CORS spec, perhaps this resource is better to
> > understand it:
> > http://resources.infosecinstitute.com/demystifying-html-5-attacks/
> 
> In my opinion if your data is sensitive, you shouldn't make it public
> in the first place. 

Well, this is not about public data. This is about privileged data on the 
Web, which is a huge and very important part of the Web.

> And like Markus said, cookies aren't sent along
> the way, so it's just like a regular HTTP request.

I don't see how that is relevant to the proposed attack at all, but I'm not 
a security expert. The malicious code is executed with the internal user's 
tokens and/or credentials, what exactly they are, doesn't seem to me to 
alleviate the concern. 

> 
> > So, you could of course say that TPFs are just for the public Internet,
> > but I think that would be a mistake.
> 
> What makes them only for the public internet? The CORS? CORS set to
> "*" makes it just accessible via other tabs and greatly improves the
> accessibility of your data by web applications. The same level of
> security applies as any other system. So you can still have CORS set
> to * and a private TPF site with regular cookie authentication.

As I said, I don't think you can. But I'm not a security expert, I believe 
strongly that the CG should have this reviewed by someone who is... :-)

> Regarding the attack described in your link, if someone is able to
> make you go to a malicious site and make you think it's the intranet
> instead, well they could just pop-up a login form and steal your
> username/password. So for that type of attack there's a lot of other
> exploits possible before reaching the CORS attack, 

This attack is in another class altogether...: People are by now quite used 
to being careful about putting their username and password into any random 
form. If they click on cutekittens.com, and they are presented with a "Log 
in to your corporate Intranet to see pictures of cute kittens" (or other 
attractive content, as it may be ;-) ), they are not likely to fall in that 
trap. They are quite likely to glance at the address bar, and see that the 
page has a valid SSL certificate. Even though that process may be imperfect, 
it is quite unlikely that they will be compromised that way.

If their internal site has a CORS header '*', it would already have been 
compromised the moment they click on that cutekittens.com link, if that 
happens to be an attack site. That's my understanding of the attack 
anyway... 

> which frankly I haven't still understood.

Well, another reason for someone else to review it, I'd say :-) Of course, I 
may be exaggerating the vulnerability too... 

I think CORS advocacy is important, I have it in my implementation, and I've 
contributed to Michael Hausenblas' site, but I think it should be orthogonal 
to the TPF specification because of the security implications it introduces.
 
Cheers,

Kjetil

Received on Tuesday, 14 October 2014 13:46:14 UTC