Cross-frame 'security' (Internet Explorer and Python/COM)

Alexandre Ferrieux alexandre.ferrieux at rd.francetelecom.fr
Tue Jul 4 08:44:34 EDT 2000


Roger Upole wrote:
> 
> Here's a small sample of how to navigate to a URL.
> >>> import win32com.client
> >>> x=win32com.client.Dispatch('InternetExplorer.Application.1')
> >>> x.Visible=1
> >>> x.Navigate('http://www.python.org')

I've been doing something similar in some other scripting language
(replace Python/win32com by Tcl/Optcl), and it worked quite well,
however I've run into a show-stopper, and I would like to gather
insights:

The so-called cross-frame security issue.

Once you've created the automation object x above, you can to some
extent
walk down the document tree. The problem is, if the page contains a
frame
which is hosted in some other 'domain' (the last two items in the DNS
name),
you simply can't access that subtree, even in read-only mode.

In my case it was nasty because the sole purpose of the whole stuff was
to reuse IE's parsing machinery to extract only text from the page -- 
a poor man's Lynx in a maximum-reuse context if you prefer.

I've seen some explanations on the MS site (security bulletin and so
on).
The beginning of the story was the possibility for malevolent
client-side
code to insert its own text input box right on top of the one from a
securized credit card number input dialog. This, sure enough, was a
critical
security hole. However, the counter attack doesn't make sense to me: why
bar
access to extradomain frames, even readonly, while the real issue was to
prevent
only *write* access (or visual overlay) of other frames ?

Please please somebody enlighten me !

TIA,

-Alex



More information about the Python-list mailing list