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

WebSockets / WebRTC / WebTransport #32

Open
annevk opened this issue Dec 2, 2020 · 3 comments
Open

WebSockets / WebRTC / WebTransport #32

annevk opened this issue Dec 2, 2020 · 3 comments

Comments

@annevk
Copy link

annevk commented Dec 2, 2020

I'm curious where the hook for CORS RFC1918 should be. Is it primarily about HTTP connections, or is it about protecting specific IP addresses in general from web traffic?

@annevk annevk mentioned this issue Dec 2, 2020
@letitz
Copy link
Collaborator

letitz commented Dec 3, 2020

I think the most important is preventing HTTP connections, because private websites are most likely to be exploited via HTTP requests. Preventing any web traffic is probably a tad bit less important, but still useful - one can imagine buggy servers mishandling malicious malformed data, or even vulnerable websocket server implementations.

I have not yet formed an opinion regarding WebRTC and WebTransport.

@annevk
Copy link
Author

annevk commented Dec 4, 2020

WebSocket is essentially an HTTP connection, so it would have to be covered.

WebTransport uses ALPN so maybe that is fine indeed. We would need to make it very clear that not all browser connections to these network addresses are preflighted.

Unsure about WebRTC as well, but looking into it.

@annevk
Copy link
Author

annevk commented Feb 24, 2021

Given that we had to expand port blocking to WebRTC, it would make sense to me that this also applies there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants