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 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
Copy link
Contributor

lgtm

@feross feross merged commit 7e829b5 into master Aug 27, 2019
@feross feross deleted the fix-server-xss branch August 27, 2019 21:05
@feross
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
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 30, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants