Re: XHR: definition of same-origin

* Maciej Stachowiak wrote:
>(a) Find out that another frame has a specific exact URL from the fact  
>that a different resource with an identical URL can access it. If the  
>resource is a template with some variable information filled in, the  
>variable information can be determined by brute force guessing.
>
>(b) Modify the other resource; if it is embedded in another page this  
>could lead to a phishing attack or similar.
>
>Both of these would depend on the data: URL already having contents  
>that could be subverted to access a different frame containing the  
>same resource.

I am not really following you here. We have at least two frames, the
URL of both is data:X. If the X includes malicious code, you already
have complete access to both frames and any access restriction would
be irrelevant. So the only scenario would be that you have a third
frame that loads malicious code into one data:X frame and some other
information into the other data:X frame.

However, as you point out, the third frame cannot write to data:X,
and if it could, loading malicious code in there would be a security
hole no different from ordinary XSS vulnerabilities. The same would
go if data:X has a script injection vulnerability (perhaps that is
what you mean in your last paragraph).

In that sense, yes, every time you allow some kind of access, there
is a chance that it might be abused, and it would be a fair point to
say, if data:X can't access data:Y, it should not be able to access
data:X either -- so you might just have picked a bad example here.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Thursday, 30 August 2007 02:56:16 UTC