Re: [hybi] New port and Tunneling?

["Shelby Moore" <[e-mail]>]

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