While mitigated the issue still exists:
https://www.openbugbounty.org/reports/331317/
The attached patch fixes it:
Index: biblio/biblio.py
===================================================================
--- biblio/biblio.py (Revision 551)
+++ biblio/biblio.py (Arbeitskopie)
@@ -14,6 +14,7 @@
import string
import traceback
from SQLparsing import *
+from cgi import escape
from common import *
from login import *
from awardClass import awards
@@ -743,7 +744,7 @@
if noheader:
PrintHeader(message)
PrintNavbar('author', author, 0, self.cgi_script, author)
- print '<h2>%s</h2>' % message
+ print '<h2>%s</h2>' % escape(message)
PrintTrailer('author', author, 0)
sys.exit(0)
Anonymous
I have tried to recreate this and other reported XSS issues using Firefox, Google Chrome, Edge and IE 11. The first three refused to execute the injected script as per the ISFDB CSP settings. As expected, IE 11 executed them because it ignores the CSP standard. Also, running NoScript within Firefox gives the user the choice of executing or blocking the injected script.
Given these results, it looks like the problem only exists under IE 11 and other older browsers which do not follow the CSP standards. I could apply the submitted changes, but it wouldn't address the rest of the security issues that exist in older browsers.
You're mixing two things here:
not a major vulnerability. A possible way to exploit is to get a js-File onto the server and reference it. Then the CSP rules will no longer protect.
That's also why I wrote "while mitigated the issue still exists". The CSP always is only a workaround, not a fix. It should not be possible from user side to inject valid HTML into the pages!
Last edit: Dirk Stoecker 2020-09-15
I really wonder. The main trouble between you and me is that you have in my eyes a strange understanding of methods to ensure code quality, and then you're leaving obvious security related issues open for months, even years after I provided fixes for them. That's simply not understandable at all! As I already said above your mitigation does not help. It can easily circumvented!
To do so I made an exploit which bypasses the policies:
http://www.isfdb.org/cgi-bin/se.cgi?arg=%3Cscript+src%3D%22%2Fwiki%2Findex.php%3Ftitle%3DUser%3AStoecker%2FXSS%26action%3Draw%22%3E%3C%2Fscript%3E&type=Name
When you wrote that "A possible way to exploit is to get a js-File onto the server and reference it", I didn't grasp the implications of the fact that our Wiki is relatively open. Sorry about that! Fixing things now...
That's only one possibility. I have some other ideas to maybe bring files to the server as well. Didn't test them throughout as they are much more complex. But it is safe to assume that a dedicated attacker will reach that goal on any non-trivial website.
Fixed in biblio/biblio.py , installed in SVN 578 on 2020-11-20. Closing the Bug.