[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kfm-devel
Subject:    Re: Possible security problem in KHTML or KMail?
From:       Martijn Klingens <mklingens () yahoo ! com>
Date:       2001-10-11 18:32:05
[Download RAW message or body]

On Thursday 11 October 2001 20:03, Andreas Pour wrote:
> Would it be difficult to add a 'private' property to a frame, which is
> set if any data comes from the local file system, and whenever a
> JavaScript variable is set with data, it is marked as "private" (just
> has to check the flag of that frame)?  If so, then it should be
> relatively straightforward to issue a warning to a user if a "private"
> variable is being used in a URL request.  Of course I don't know the JS
> internals . . . .

I'd prefer Ilya's suggestion here: deny access between two frames that are 
not using the same protocol (http/ftp/etc.) _and_ the same server. Maybe 
filtering on protocol should be loosened a bit to make http/https 
cross-references possible, but apart from that I mostly agree with Ilya's 
suggestion.

If we can make the distinction between file:/ urls that point to user files 
the HTML that can be embedded in e.g. an email then we can also give file: 
(or actually anything for which isLocalFile() returns true) full access, even 
to foreign URLs. After all, the base URL is local and thus 'trusted'. Again, 
that only works if it is possible to distinguish local URLs from embedded 
HTML, which runs local but certainly shouldn't be treated as being local.

So in short:
Accessing elements from URLs that are foreign from the requesting URL should 
not be allowed _unless_ 1) the requesting URL and _all_ its parents are local 
files or 2) the requesting and requested URL only differ in having SSL 
enabled or not and both point to the same server. Temporary files, HTML 
emails and anything like this is _not_ considered a 'local file' here.

That's my two cents in this discussion.

Martijn

[prev in list] [next in list] [prev in thread] [next in thread]