Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > webbrowser module + urls ending in .py = a security hole?

Reply
Thread Tools

webbrowser module + urls ending in .py = a security hole?

 
 
Blair P. Houghton
Guest
Posts: n/a
 
      01-30-2006
I'm just learning Python, so bear with.

I was messing around with the webbrowser module and decided it was
pretty cool to have the browser open a URL from within a python script,
so I wrote a short script to open a local file the same way, using the
script file as an example target:

# browser-test.py
import webbrowser
import sys
pathname = sys.argv[0]
protocol = 'file://'
url = protocol + pathname
webbrowser.open(url)

And what I got, instead of a browser window with the text of my script,
was a sequence of DOS windows popping up and disappearing.

Apparently that's because either Windows (XP SP2) or the browser
(Firefox) was interpreting the .py file extension and running Python to
execute it.

So is this a known (mis)feature, and will it happen if I chance to use
webbrowser.open() on a remote .py file?

Because if so, it's a king-hell security hole.

--Blair

 
Reply With Quote
 
 
 
 
Blair P. Houghton
Guest
Posts: n/a
 
      01-30-2006
Oh, uh, Python version 2.4.2, in case you're wondering.

--Blair

 
Reply With Quote
 
 
 
 
Peter Hansen
Guest
Posts: n/a
 
      01-30-2006
Blair P. Houghton wrote:
> I was messing around with the webbrowser module and decided it was
> pretty cool to have the browser open a URL from within a python script,
> so I wrote a short script to open a local file the same way, using the
> script file as an example target:
>
> # browser-test.py
> import webbrowser
> import sys
> pathname = sys.argv[0]
> protocol = 'file://'
> url = protocol + pathname
> webbrowser.open(url)
>
> And what I got, instead of a browser window with the text of my script,
> was a sequence of DOS windows popping up and disappearing.
>
> Apparently that's because either Windows (XP SP2) or the browser
> (Firefox) was interpreting the .py file extension and running Python to
> execute it.
>
> So is this a known (mis)feature, and will it happen if I chance to use
> webbrowser.open() on a remote .py file?


What happens when you load a remote .py file using the web browser
directly? With Firefox on my machine, it just displays the file, as
expected, whether loaded via webbrowser.open() or not. Make sure you're
testing with the same browser that webbrowser loads (try a regular HTML
file first if you're not sure which that is).

> Because if so, it's a king-hell security hole.


It might probably worth a warning in the docs, but it's no larger a
security hole than the browser itself already has. If your browser is
configured to load files of a given type directly into a particular
application without first checking with you if you want it to do so,
you're potentially screwed already.

But is Firefox really your default browser? The webbrowser module could
be loading Internet Explorer on your machine, and we all know just how
safe *that* is...

-Peter

 
Reply With Quote
 
Fuzzyman
Guest
Posts: n/a
 
      01-30-2006
It sounds like you're running on windows *and* that webbrowser.py just
uses ``os.startfile``.

For html files (associated with your default browser) this will *do the
right thing*. For everything else, it will *do the wrong thing*.

I could well be wrong though...

All the best,


Fuzzyman
http://www.voidspace.org.uk/python/index.shtml

 
Reply With Quote
 
jason.lai@gmail.com
Guest
Posts: n/a
 
      01-30-2006
Does that only happen when you open file:// urls? You already have
local access from Python, so it'd be more concerning if it happened
with Python files on remote servers.

- Jason

 
Reply With Quote
 
Blair P. Houghton
Guest
Posts: n/a
 
      01-30-2006
I'm going to try it out on a remote server later today.

I did use this script to fetch remote HTML
(url='http://www.python.org') before I tired the remote file, and it
opened the webpage in Firefox.

I may also try to poke around in webbrowser.py, if possible, to see if
I can see whether it's selecting the executable for the given
extension, or passing it off to the OS. I would think, since Python is
not /supposed/ to have client-side scripting powers, that even when the
script is on the client this is bad behavior.

Just don't have the bandwidth, just now.

Anyone got a good regex that will always detect an extension that might
be considered a script? Or reject all but known non-scripted
extensions? Because wrapping the webbrowser.open() call would be the
workaround, and upgrading webbrowser.py would be a solution.

--Blair

 
Reply With Quote
 
Blair P. Houghton
Guest
Posts: n/a
 
      01-30-2006
Sorry...should read:

"I did use the script to fetch remote HTML
(url='http://www.python.org') before I tried the local file, and it
opened the webpage in Firefox."

Too many chars, too few fingers.

--Blair

 
Reply With Quote
 
Peter Hansen
Guest
Posts: n/a
 
      01-30-2006
Blair P. Houghton wrote:
> I'm going to try it out on a remote server later today.


Don't bother. I've confirmed the behaviour you saw, and that it is not
what I'd expect either. My Firefox certainly isn't configured to run
..py scripts even when invoked with the "file:" protocol, so webbrowser
is almost certainly Doing Bad Things on Windows.

The relevant code from webbrowser.py shows this, confirming FuzzyMan's
suspicions:

class WindowsDefault:
def open(self, url, new=0, autoraise=1):
os.startfile(url)

def open_new(self, url):
self.open(url)

> I may also try to poke around in webbrowser.py, if possible, to see if
> I can see whether it's selecting the executable for the given
> extension, or passing it off to the OS. I would think, since Python is
> not /supposed/ to have client-side scripting powers, that even when the
> script is on the client this is bad behavior.


I'd agree. I suspect this ought to be reported as a security flaw,
though it would be nice to know what the fix should be before doing so.
Anyone know a more suitable approach on Windows than just passing
things off to startfile()?

> Just don't have the bandwidth, just now.
>
> Anyone got a good regex that will always detect an extension that might
> be considered a script? Or reject all but known non-scripted
> extensions?


Would it be sufficient in your case merely to allow only .html files to
be loaded? Or URLs without .extensions? Or even just permit only the
http: protocol?

-Peter

 
Reply With Quote
 
Peter Hansen
Guest
Posts: n/a
 
      01-30-2006
Peter Hansen wrote:
> I'd agree. I suspect this ought to be reported as a security flaw,
> though it would be nice to know what the fix should be before doing so.
> Anyone know a more suitable approach on Windows than just passing
> things off to startfile()?


It appears the correct approach might be something along the lines of
reading the registry to find what application is configured for the
"HTTP" protocol (HKCR->HTTP->shell->open->command) and run that, passing
it the URL. I think that would do what most people expect, even when
the URL actually passed specifies the "file" protocol and not "http".

Thoughts?

-Peter

 
Reply With Quote
 
Bengt Richter
Guest
Posts: n/a
 
      01-30-2006
On Mon, 30 Jan 2006 16:00:25 -0500, Peter Hansen <(E-Mail Removed)> wrote:

>Blair P. Houghton wrote:
>> I'm going to try it out on a remote server later today.

>
>Don't bother. I've confirmed the behaviour you saw, and that it is not
>what I'd expect either. My Firefox certainly isn't configured to run
>.py scripts even when invoked with the "file:" protocol, so webbrowser
>is almost certainly Doing Bad Things on Windows.
>
>The relevant code from webbrowser.py shows this, confirming FuzzyMan's
>suspicions:
>
>class WindowsDefault:
> def open(self, url, new=0, autoraise=1):
> os.startfile(url)
>
> def open_new(self, url):
> self.open(url)
>
>> I may also try to poke around in webbrowser.py, if possible, to see if
>> I can see whether it's selecting the executable for the given
>> extension, or passing it off to the OS. I would think, since Python is
>> not /supposed/ to have client-side scripting powers, that even when the
>> script is on the client this is bad behavior.

>
>I'd agree. I suspect this ought to be reported as a security flaw,
>though it would be nice to know what the fix should be before doing so.
> Anyone know a more suitable approach on Windows than just passing
>things off to startfile()?
>
>> Just don't have the bandwidth, just now.
>>
>> Anyone got a good regex that will always detect an extension that might
>> be considered a script? Or reject all but known non-scripted
>> extensions?

>
>Would it be sufficient in your case merely to allow only .html files to
>be loaded? Or URLs without .extensions? Or even just permit only the
>http: protocol?
>

How about finding the browser via .html association and then letting that
handle the url? E.g., slong the lines of

>>> import os
>>> ft = os.popen('assoc .html').read().split('=',1)[1].strip()
>>> ft

'MozillaHTML'
>>> os.popen('ftype %s'%ft).read().split('=',1)[1].strip()

'D:\\MOZ\\MOZILL~1\\MOZILL~1.EXE -url "%1"'


Regards,
Bengt Richter

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
JDBC URLs ...not really URLs? Adam Monsen Java 11 02-08-2009 08:14 PM
Converting Relative URLs into Absolute URLs Nathan Sokalski ASP .Net 1 08-12-2008 07:03 AM
[python] -- interesting use of the webbrowser module David Stockwell Python 0 06-10-2004 06:37 PM
dynamic URLS convert to static URLS for search engines Steve T. ASP .Net Web Services 7 03-04-2004 03:16 PM
Distinguish text URLs from non-text URLs? Kaidi Java 5 01-04-2004 10:15 AM



Advertisments