[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
Re: [xml-dev] Open Platform
- From: Henri Sivonen <hsivonen@iki.fi>
- To: "xml-dev@lists.xml.org List" <xml-dev@lists.xml.org>
- Date: Wed, 15 Dec 2010 17:22:48 -0800
On Dec 13, 2010, at 18:55, Rob Koberg wrote:
> On Mon, Dec 13, 2010 at 5:06 PM, Henri Sivonen <hsivonen@iki.fi> wrote:
>> On Dec 13, 2010, at 06:30, Michael Kay wrote:
>>> Security restrictions in terms of what resources are accessible are of course reasonable, though as far as I can see the cross-site-scripting rules seem to be about as relevant to the real threat model as the theatrical checks performed in airport security halls.
>>
>> Could you, please, elaborate? How is the Same-Origin Policy not relevant to the threat of information leakage when the browser has ambient authorization to access private data from another origin?
>
> * Copy and paste
> * proxy content through a machine under your control
[...]
> Laws exist that offer remedies to copyright infringement.
It seems to me that multiple people on this list are quick to blast the browser security model without appearing to have a good understanding of what thread is being defended against.
If the user chooses to copy confidential information and paste it to another origin, that's the user's choice. The purpose of the Same-Origin Policy is to avoid information leakage against the wish of the user.
The security model has nothing to do with copyright.
The Same-Origin Policy is about making sure the browser doesn't become a proxy under the attacker's control. The intranet case is this:
The attacker runs a site outside a corporate firewall. The user runs a browser on a computer inside the firewall. There's a server on the same side of the firewall as the user's browser, and that server has no access control (other than the firewall) for confidential information.
Now, the attacker's server can't directly reach the server that hosts confidential information because the firewall blocks connections from the public Internet to the corporate network. However, when the user accesses the attacker's site, the attacker gets to run JavaScript on a computer that's inside the firewall. If that JavaScript program was permitted to use XHR to connect to origin's other than its own, the attacker could use XHR to fetch confidential information from the server on the corporate network and then use XHR to send the data to the attacker's server. The Same-Origin Policy prevents this.
(In the general Web case without a firewall, cookies and HTTP authentication (rather than requestor's place in the network topology) forms the ambient authorization. Even if a site considers the user as logged in, it's not desirable to allow JS from other site to access the information that has been sent to the browser on the condition of login.)
--
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]