[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTinT0L+FMf-m6c1kVrYFQUdc7Go-RaGWEXD4p4ZJ@mail.gmail.com>
Date: Wed, 20 Oct 2010 10:45:11 -0700
From: Michal Zalewski <lcamtuf@...edump.cx>
To: Dan Kaminsky <dan@...para.com>
Cc: Roberto Suggi Liverani <roberto.suggi@...urity-assessment.com>,
full-disclosure <full-disclosure@...ts.grok.org.uk>,
"bugtraq@...urityfocus.com" <bugtraq@...urityfocus.com>
Subject: Re: [Full-disclosure] Security-Assessment.com Advisory: Oracle JRE -
java.net.URLConnection class - Same-of-Origin (SOP) Policy Bypass
> Eh, you can see where it came from though. Design bugs like this are absolutely miserable to fix (see how we'll never get rebinding out of the browser) and letting identical IP's script against eachother lets an awful lot of legitimate traffic through while blocking almost all attacks.
>
> I'm not saying it's a preferred design, but let's reserve "horrible" for things that don't have quite the obvious thought process behind them.
"Horrible" in the sense it had significant consequences for the safety
of all Internet users, for at least a decade (ever since HTTP vhosts
became reasonably popular, which must be what, late 90s).
I don't really question the thought process - although it's
interesting to see that almost all attempts to redefine / reinvent SOP
led to significant issues over the years. This is not merely the fault
of plugin vendors, by the way - the incompatibility between DOM SOP
and cookie "SOP" pose some very interesting and underappreciated
problems for many classes modern web apps. And it's certainly not
unique to SOP, too:
http://lcamtuf.blogspot.com/2010/10/attack-of-monster-frames-mini.html
Anyway...
/mz
Powered by blists - more mailing lists