Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix http server XSS #1714

Merged
merged 3 commits into from Aug 27, 2019
Merged

Fix http server XSS #1714

merged 3 commits into from Aug 27, 2019

Conversation

@feross
Copy link
Member

feross commented Aug 27, 2019

Low risk xss. If the torrent contains a specially crafted title or file name, and a user running WebTorrent in Node.js starts the HTTP server via torrent.createServer(), and then the user visits the HTTP server's index page (which lists the files in the torrent), then the attacker can run JavaScript in this browser context.

This seems relatively low risk since the WebTorrent HTTP server only allows fetching data pieces from the torrent. So an attack that interacts with the HTTP server cannot control the torrent client or execute any code. They can only fetch data pieces from the torrent. So, attacker code could e.g. figure out what content the user is downloading and exfiltrate that to an external server.

This PR mitigates the issue in two ways (either of which could have prevented this XSS on its own):

  1. HTML-escape untrusted torrent metadata (name, path, file names, etc.)

  2. Add the strictest possible CSP to prevent all connections, scripts, styles, plugins, frames. Every capability is denied.

Low risk xss. If the torrent contains a specially crafted title or file name, and the user starts the WebTorrent HTTP server via createServer(), and then the user visits the HTTP server index page (which lists the contents of the torrent), then the attacker can run JavaScript in this browser context.

The reason this seems relatively low risk is that the WebTorrent HTTP server only allows fetching data pieces from the torrent. It doesn't support any other control of the torrent client. So, attacker code could e.g. figure out what content the user is downloading and exfiltrate that to an external domain.

This commit mitigates the issue in two ways (either of which could have prevented this XSS on its own):

1. HTML-escape untrusted torrent metadata (name, path, file names, etc.)

2. Add the strictest possible CSP to prevent all connections, scripts, styles, plugins, frames. Every capability is denied.
lib/server.js Outdated Show resolved Hide resolved
@diracdeltas

This comment has been minimized.

Copy link
Contributor

diracdeltas commented Aug 27, 2019

lgtm

@diracdeltas

This comment has been minimized.

Copy link
Contributor

diracdeltas commented on 9029557 Aug 27, 2019

lgtm

@feross feross merged commit 7e829b5 into master Aug 27, 2019
4 checks passed
4 checks passed
continuous-integration/appveyor/branch AppVeyor build succeeded
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details
@feross feross deleted the fix-server-xss branch Aug 27, 2019
@feross

This comment has been minimized.

Copy link
Member Author

feross commented Aug 27, 2019

0.107.6

feross added a commit to webtorrent/webtorrent-desktop that referenced this pull request Sep 4, 2019
To address minor xss vulnerability in http server. See: webtorrent/webtorrent#1714
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Linked issues

Successfully merging this pull request may close these issues.

None yet

2 participants
You can’t perform that action at this time.