Re: Comments on the Triple Patterns Fragments draft

> 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. And like Markus said, cookies aren't sent along
the way, so it's just like a regular HTTP request.

> 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.

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, which frankly I
haven't still understood.

On Tue, Oct 14, 2014 at 1:18 PM, Markus Lanthaler
<markus.lanthaler@gmx.net> wrote:
> On 10 Okt 2014 at 16:59, Kjetil Kjernsmo wrote:
>> So, I discovered there were some points that I hadn't responded to. Markus
>> wrote way back:
>>
>>> Access-Control-Allow-Origin is not about authentication... thus I'm
>>> actually a bit confused what you are discussing here. Access-Control-
>>> Allow-Origin is about allowing browsers to access resources on other
>>> servers.
>>
>> Right. I was refering to some of the attacks that is made possible by
> CORS,
>> as far as I have understood it.
>>
>> If someone puts up a TPF server on an Intranet containing information not
>> meant for outsiders, and this has a CORS header allowing anybody, an
>> attacker could access this information if they can trick an internal user
>> who has authenticated to access the Internet resource to execute a script
>> that cross-origin-shares the secret information...  Such attacks are
>> discussed in the CORS spec, perhaps this resource is better to understand
>> it: http://resources.infosecinstitute.com/demystifying-html-5-attacks/
>
> Yes, that's of course completely right.
>
>
>> Or it may of course be that I haven't understood the attack, but
> personally,
>> I'd be very cautious about adding CORS to private resources, and * I would
>> certainly never add to anything that weren't meant for the public
> Internet.
>
> If the resource requires authentication and doesn't work with cookies, then
> the attack would be impossible (or at least very very difficult).
>
>
>> So, you could of course say that TPFs are *just* for the public Internet,
>> but I think that would be a mistake.
>
> +1
>
> I actually forgot what we are discussing here but I just had a look at the
> LDF specs and see that we are probably discussing the following statement in
> the TPF spec [1]
>
>   In order to allow browser applications to access fragments, Cross-
>   Origin Resource Sharing [CORS] MUST be enabled on the server. To this
>   end, triple pattern fragments servers MUST emit the following header
>   and value on all HTTP responses to requests for triple pattern
>   fragments, regardless of their status code:
>
> I would thus suggest to change the spec as follows [2]:
>
>   In order to allow browser applications to access fragments, Cross-
>   Origin Resource Sharing [CORS] **has to be** enabled on the server. To
>   this end, triple pattern fragments servers **SHOULD** emit the
>   following header and value on all HTTP responses to requests for
>   triple pattern fragments, regardless of their status code:
>
>
>
> [1]
> http://www.hydra-cg.com/spec/latest/triple-pattern-fragments/#h4_accessibili
> ty-for-web-applications
> [2] https://github.com/HydraCG/Specifications/pull/76
>
>
> --
> Markus Lanthaler
> @markuslanthaler
>
>

Received on Tuesday, 14 October 2014 11:48:59 UTC