Re: [hybi] New port and Tunneling?

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

I will read it next, but quick reply to say:

1) Agreed, because if the browser has a bug that reveals my session id for
AsiaDear.com, my security is broken.  I have to rely on the browser for
persistance, but what I have done is made sure that only a bug in the
browser can do it, not some other type of vulnerability.

2) Apologize for the tone of my prior email about your research paper.  I
wasn't expecting that you would appreciate my points, but seems I wasn't
patient enough (past experience sorry). Also if you are approaching this
from a "what is practical in real world" perspective, I can understand why
your research would be less "idealistic" than my points.  Nevertheless, I
hope we can agree that it is a major win when we can be idealistic and
achieve the isolation of #1 above.

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