Re: [hybi] New port and Tunneling?

[Adam Barth <[e-mail]>]

Thanks for your detailed response.  I think I understand your
perspective better now.  Unfortunately, whether or not we judge the
fault to lie with the server, browser vendors still take it upon
themselves to avoid these issues.  For some perspective on why this is
the case, you might enjoy reading this post:

http://www6.ietf.org/mail-archive/web/hybi/current/msg02400.html

Kind regards,
Adam


On Wed, Aug 18, 2010 at 12:19 AM, Shelby Moore <[e-mail]> wrote:
> 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
>>>
>>
>>
>
>