Resolve XSS vulnerability in local Wordnet browser #3096
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hello!
Pull Request overview
nltk.app.wordnet_app
. This only affected users of this browser interface to Wordnet, and not other users of Wordnet. If the following image is not familiar to you, then you are not affected:Details
Whenever an unknown path was supplied in the localhost, e.g.
http://localhost:8000/<script>alert(1)</script>.html
, then the wordnet app would try to find a file called<script>alert(1)</script>.html
, be unable to do so, and then report back with an error on the website saying that"Internal error: Path for static page '<script>alert(1)</script>' is unknown"
. However, this page was loaded as HTML, so the script would be executed.I don't believe that there is a real attack vector here, as the pages that are normally seen are directly from Wordnet, so one of the Wordnet URLs would need to be modified into a malicious link. That said, there is no reason not to fix this.
Reproducing
The wordnet browser app can be started like so:
Then, browsing to
http://localhost:8000/<script>alert(1)</script>.html
would cause the following popup to appear:The fix
By setting the
Content-type
totext/plain
when an unknown path is used, we prevent any code from being executed.After the fix
When running the reproduction code, we now see:
And no popup.
This vulnerability was disclosed according to our security policy, and we are thankful for that.