Reflected XSS in any wordnet URL in nltk/nltk
Reported on
Dec 23rd 2022
Description
A reflected XSS can be achieved by simply creating a URL such as: http://localhost:8000/<script>alert(1)</script>.html
Proof of Concept
nltk.app.wordnet_app.app()
Then hit http://localhost:8000/<script>alert(1)</script>.html in the browser.
Impact
Browser hijacking, sensitive information loss.
Occurrences
@admin I'm somewhat unfamiliar with how to interpret the CVSS Severity, as I've only used it a handful of times previously. My concern is as follows: NLTK is a collection of many, many small tools, many of which are rarely used. This XSS vulnerability does seem real, but it affects only one such (very rarely used) tool. Intuitively, this implies a lower severity. How should I set the Severity accordingly?
@danmcinerney Thank you for reporting! I'll mark this as valid once I've set the severity correctly. I have a fix lined up locally already, so that'll be no worries.
Hey Tom! The CVSS system doesn't take into account the popularity of the affected feature/module but the CVE system does so we can go about this in two ways:
We either publish a high severity advisory specifying that the vulnerability only afflicts wordnet_app (which users should recognise as something they don't use) OR we can downgrade the severity of this vulnerability in case they think it's against NLTK generally.
@admin I'm personally of the opinion that it is unnecessary to notify all NLTK users of this vulnerability. In 2.5 years of maintaining NLTK I've never once used wordnet_app, nor have I heard of anyone else using it. I wouldn't say that it's "demo code" exclusively, but people tend to use wordnet directly via code rather than playing around with this (XSS vulnerable) local wordnet browser.
What are the consequences of the CVE being published? Will users be notified in some way, or can they only discover the NLTK vulnerabilities if they search for CVEs published for NLTK (there's about 4 now)? NLTK is primarily used "behind the scenes" of other products, while this vulnerability may only affect people directly using NLTK's wordnet browser. I wouldn't want to unnecessarily worry the developers of those other products with a vulnerability report that wouldn't affect them.
That said, the way that you describe it, it doesn't make much sense to lower the severity via CVSS directly.
I'm open to your advice on this.
Makes sense! CVEs feed dependabot and it notifies downstream users of NLTK on GitHub. Severity more broadly is used to determine how much attention your users should dedicate to a vulnerability. By the sound of it, it doesn't seem like this finding merits a CVE advisory.
That being said, if you're not planning on releasing a fix for this, you can close it as informative (which will make it public immediately) OR if you are planning on a fix, you can validate it as a Low / None. Again, in any case this won't get a CVE.
@admin I'd like to set it to Low, but I cannot do that without erroneously filling in the CVSS scores. Any advice? I'll push out a fix for this soon.
That's the only way today unfortunately but as long as a CVE doesn't go out we're fine. You can always ask the researcher for a fix if you're unsure :)