Re: [hybi] New port and Tunneling?

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

Hi Adam,

Please skip down the numbered point first, to see your gross
mis-understandings.

Sincerely thanks for expressing your opinion. I appreciate it. I have
opened your web page ( http://adambarth.com ) and I understand you are a
PhD with some focus on cross origin security (my credentials are mentioned
below). Could we Skype for 20 mins, because it might be much more
efficient to resolve this? Or a private email discussion? Then one of us
can come here and admit defeat after we hash it out. I have no problem
with accepting when I am wrong, but I need to understand first. And I am
reasonably confident (you will read why below) that in this case the
misunderstanding is predominantly on your side. Let me see if I can clear
this up below. If you prefer to debate on this public list, that is fine
with me. If you prefer to ignore me or make only sweeping statements with
no specific debate, then I will consider you have lost the debate. Let's
try not to get personal and inflamed, and let us stick to the facts.

After sending this email, I am going to take some time to read some of
your publications, so I can understand better your expertise. I will show
you that respect/appreciation and give my time to understand you (for my
own benefit of course). I appreciate if you would allocate just a little
time to steering this thread to a successful conclusion (one way or the
other), without just a sweeping statement of expert authority (those often
are correct, but just once in a while they are gross errors). I do
understand that it is not a free market if I demand your time, so I will
understand if you decline.

We will probably discover that we are both correct, and we just didn't
understand the nuances of what each other. It is important that we
discover in what ways we are both correct, so that we are clear on the
nuances. We must respect each other, and assume intelligience until
clearly proven beyond any reasonable doubt otherwise. If we merely talk
past each other (because we are too lazy or too busy or too
arrogant...myself included), then understanding will fail. You obviously
take browser security very seriously as I do too. So unless you think I am
a total idiot (without even giving me an interactive dialogue to show you
otherwise), I can't imagine why you wouldn't want to at least make a
modicum of attempt at mutual understanding. But then again, I am confident
enough to go on without you and the list too (I love free markets).

Unfortunately, you didn't provide much specific information about your
misunderstandings, that could help me know if you are correct or not.
Based on the incorrect statements you made, I am nearly certain you just
broadstroked this without really understanding my points.  I will detail
as follows:

1. Contrary to your allegation, my prior points did not summarize the way
browser security currently works in every instance (e.g. XMLHttpRequest,
SOP applied to client-side resources, etc), rather to point out a way it
should work (in fact does work now! see below), if it was (is!) done
optimally. And my analysis was only focused on the aspect of SOP applied
specifically to browser network resource requests, i.e. when/should/does
the browser restrict network resource requests to SOP. Please re-read the
prior sentence a few times to remember the narrow focus.

Also I humbly suggest that you remember that SOP is never an avoidable
restriction for network script requests from the browser, because SOP is
not applied to the <script> tag (oh maybe there is a case that I am not
aware but it isn't common because I haven't seen it yet). So actually I
was explaining how the browser works now with respect to <script>. Then I
explained why that is optimal (in opposition to the current wrongheaded
trend to move away from that, wrongheaded is proven factually below). I
was explaining this in order to show that we do not need to apply SOP to
WebSockets. I was NOT explaining how the ENTIRE browser security system
works now. And I can assure you that my statements were correct and
factual (notwithstanding any mis-interpretations, grammatical errors, and
typos).

2. Your allegation that I am in conflict with Wikipedia is incorrect.
Wikipedia has a section "Other approaches to CSRF":

http://en.wikipedia.org/w/index.php?title=Cross-site_request_forgery&oldid=377197816#Other_approaches_to_CSRF

I agree that those are valid vulnerabilities. Wikipedia is even saying
that they are not exactly "CSRF".  Rather than create a name for them
(since Wikipedia is not allowed to create new things, only state what is
already), they have no place to put those vulnerabilities, so they stuck
them under a new name "Other approaches to CSRF". They are not CSRF
exactly. It is up us experts to give those a proper category of their own
with a name. I humbly suggest that you notice that CSRF contains the word
"Request". I will understand if you didn't notice that word in the
acronym, but then it would help if you did not speak as absolute authority
or expert, when apparently you are failable. My point is that CSRF
involves vulnerabilities that initiate from "Cross Site Request Forgery",
and that means they must initiate from "Request Forgery", and the
vulnerabilities in that section do not (as Wikipedia also states).

When I wrote "disagree", I meant I disagree with them being characterized
as "approaches to CSRF", because by the time the requests have been issued
in those vulnerabities, then request itself is no longer cross origin
(Cross Site). The request itself it not the vulnerability in those cases,
but rather the injection method is the vulnerability with the request as a
payload. As a cross origin security expert, I hope you can appreciate the
distinction and offer me a little due respect for my astute observation.

=======================
Now let's see if I can re-summarize the main thrust of my prior posts
below, in order to coax some initial "a ha, that is what he meant"
understanding from readers, that might motivate them to go back and
re-read my prior posts to have new epiphenies.

I am pointing out that all (cross site or same site or whatever) network
requests from the browser can be classified into 2 types of
vulnerabilities (ignoring vulnerabilities due to bugs in the browser or
server itself). And be clear that I mean where the request itself is the
vulnerability, not where the request was a payload of a prior
vulnerability (avoiding conflation is critical for correct analysis).
Those boil down to:

#1 Hijacking user data in a request, or more generally any request that
causes unintended side-effects on server state-machine.
#2 Requesting malicious resources (e.g. scripts).

Those 2 correspond to the prior 2 categories from my prior posts.

#1 is mis-classified (by you "experts") to be a SOP problem, when in fact
it is a bug in the server code. Any one who has any significant real world
experience in web programming security (I have 13 years as hands on CTO
with millions of users), knows that the server must always be secure from
any possible state-machine of its inputs. To require the client to help
the server be secure, is the antithesis of security.  That is why I said
the solution is for the browser to never rely on persistent data on the
client, if it wants to be secure. That is just common sense.

#2 afaik is not precisely categorized with any name. It falls I guess
under the general term XSS, but I am being more specific and talking about
the vulnerability of the request itself. I understand that not conflating
vulnerability categories, is the first fundamental step that an expert
researcher must do. With respect to the request vulnerability, there is no
vulnerability if the origin which is doing the requesting does not choose
to request untrusted resources. SOP is not the same as trusted. Yes the
same origin is trusted, but it is not the only origin that might be
trusted. To restrict #2 to SOP in all scenarios, is least common
denominator and not optimal. I proposed an easily granular solution that
would work very well in the marketplace. I am confident my solution will
win and I plan on implementing it soon, unless someone can explain why I
am wrong.

Good day.



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