This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author steve.dower
Recipients eryksun, matrixise, mdk, paul.moore, steve.dower, tim.golden, vstinner, zach.ware
Date 2019-02-20.15:28:30
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1550676511.04.0.0365301790658.issue36021@roundup.psfhosted.org>
In-reply-to
Content
> Maybe webbrowser must be changed to become *very strict*.

This is the only acceptable suggestion I've seen (since my suggestion ;) )

I'd propose making it very strict by *requiring* a browser to be detected. So remove the os.startfile default and always require Chrome/Edge/etc. to be found. If they're not, you get an exception.

Personally, I'd hate this behaviour :) But for my cases I'd just switch to os.startfile unconditionally (as I only use this in my own scripts and not libraries).

One other thing to factor in is that if you use os.startfile to launch a malicious program, it will first be scanned by any anti-malware or antivirus software, and likely also by Windows SmartScreen. So you're not exactly getting arbitrary execution. It also only runs in the context of the current user, so there's not necessarily any escalation here.

All in all, I'd label this a vulnerability in applications that use webbrowser.open(), rather than in webbrowser.open() itself. The function is doing exactly what it is told, and if someone is passing untrusted input, then they'll get the exact untrusted output they expect.
History
Date User Action Args
2019-02-20 15:28:31steve.dowersetrecipients: + steve.dower, paul.moore, vstinner, tim.golden, zach.ware, eryksun, matrixise, mdk
2019-02-20 15:28:31steve.dowersetmessageid: <1550676511.04.0.0365301790658.issue36021@roundup.psfhosted.org>
2019-02-20 15:28:31steve.dowerlinkissue36021 messages
2019-02-20 15:28:30steve.dowercreate