Re: [hybi] New port and Tunneling?

[Adam Barth <[e-mail]>]

Shelby,

You seem deeply confused about how browser security works.  I'm sorry
that I don't have a good reference to offer you to help you sort out
your confusion.  However, much of what you've written on this subject
is just plain incorrect.  (By the way, disagreeing with Wikipedia
usually isn't the best way to convince others that your definitions
are widely accepted.)

Adam


On Tue, Aug 17, 2010 at 10:07 AM, Shelby Moore <[e-mail]> wrote:
>>> SOP = same origin policy
>>>
>>> I will phrase this generally for all potential protocols, not just HTTP.
>>>
>>> Status quo should remain, where "cookies" (i.e. any client-side
>>> persistent
>>> user data) are (at least by default) inaccessible if they were not
>>> created
>>> by *.domain of the current page (i.e. window.location.*).
>>>
>>> There are only two categories of SOP attacks (all attacks fall under
>>> these
>>> two):
>>>
>>> 1. Cross-domain requests where "cookies" for the domain, receiving the
>>> request, are automatically included in the request.
>>>
>>> 2. Cross-domain requests that load malicious resources (e.g. usually
>>> scripts) from foreign domain into current domain.
>>
>>
>> Clarify that to be "There are only two categories of SOP applicable
>> cross-domain attacks for accessing network resources (all such attacks
>> fall under the above two)".
>>
>> Of course SOP still has to always apply to script access to the
>> client-side resources (e.g. to cookies, frames, etc). Someone could argue
>> for more user trust granularity for client-side-resources SOP, but I would
>> retort that it would be unreasonably complex for users to manage N-tuples
>> of domains that are trusted with respect to each other.
>>
>> The reason #2 does not involve N-tuples complexity is because the domain
>> of the current page is entirely in control of when it initiates access to
>> network resources.  Whereas for client-side resources, the domain is not
>> in control of when its resources are accessed-- the browser is the
>> gatekeeper.
>
> #1 is CSRF:
>
> http://en.wikipedia.org/w/index.php?title=Cross-site_request_forgery&oldid=377197816#Example_and_characteristics
>
> #2 is not XSS:
>
> http://en.wikipedia.org/wiki/Cross-site_scripting
>
> Rather #2 needs a name, perhaps XSSR(equests), since it is only concerned
> with vulnerabilities that derive when a malicious resource (script) is
> requested by the trusted domain.
>
>
> CSRF
> ====
> When I wrote "'cookies' (i.e. any client-side persistent user data)", I
> put it in quotes and defined it broadly because I didn't mean only HTTP
> cookies. I meant any way for the server to have persistance with the
> client that would be used by the server to do side-effects, and that would
> include Flash LSO objects, DOM storage, IP address (if only storing or
> dislaying this is probably safe side-effects), etc.. And I disagree with
> Wikipedia in that don't think just having the server check Referrer closes
> the security hole.
>
> The following are not CSRF as I have defined CSRF above and attacks due
> other unrelated vulnerabilities (disagree with Wikipedia for conflating
> them with CSRF):
>
> http://en.wikipedia.org/w/index.php?title=Cross-site_request_forgery&oldid=377197816#Other_approaches_to_CSRF
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi
>