Re: Impending web-arch issue?

On Wed, Feb 2, 2011 at 9:59 AM, Nathan <nathan@webr3.org> wrote:
> Since it's came up again (and always will until it's addressed), here's a
> new reply to an old mail from last year, now that I'm not so wet behind the
> ears :)
>
> Anne van Kesteren wrote:
>>
>> On Mon, 10 May 2010 11:16:54 +0200, Nathan <nathan@webr3.org> wrote:
>>>
>>> long-term though, surely it's quite an issue that a web application,
>>> running in a web browser, conforming to all the standards and the design
>>> principals of the web, can't use the web?
>>
>> It's certainly annoying, but unless we start over I do not really see how
>> we can change the (arguably broken) security fundamentals of the platform.
>
> why not start over? the security fundamentals are broken, the browsers do
> not constitute "the web platform", and CORS is inconsistent with the web.
>
>> (What is being protected here are servers on an intranet that do not
>> require authentication and servers that use IP-based authentication. Without
>> the same-origin protection evil.example could get data from
>> intranet.corp.example if a user that is on an intranet with access to
>> intranet.corp.example visits evil.example (e.g. via a phishing attack).)
>
> That's incorrect, they are not being protected, you are creating an illusion
> of "no problem", when the problem still exists, and the illusion only
> encourages bad form and keeps these intranets vulnerable (surely you don't
> believe that /only/ web browsers can access the web and intranets?!)
>
> (1) insecure authentication methods
> (2) stateful use of a stateless protocol
> (3) using safe methods unsafely
>
> Essentially, every issue that the browser vendors have found and patched
> against is an existing and hidden issue in somebodies software or network
> that can be taken advantage of at any time by any malicious software.
>
> You are attempting to protect companies from fire by using a bit of paper,
> remove the paper and let them put the fire out.

There's no need for such a drastic action. The best, safest and
simplest thing to do is use UMP level 1 for cross-domain resources on
legacy hosts. Then do an UMP level 2 that uses a per-host opt-in to
enable the rest of the HTTP methods and headers.

That's all I'll say, since I've said it many times before. I'd be
happy to see someone else take up the charge though, since CORS is bad
for the Web.

--Tyler

-- 
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html

Received on Wednesday, 2 February 2011 18:17:23 UTC