Skip to content

Please support running websocket on localhost #778

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

Closed
bdrung opened this issue Jun 20, 2021 · 6 comments
Closed

Please support running websocket on localhost #778

bdrung opened this issue Jun 20, 2021 · 6 comments

Comments

@bdrung
Copy link

bdrung commented Jun 20, 2021

Issue type
  • Feature request
Description

I want to use obs-websocket to wire up an Elgato Stream Deck with OBS on Linux. The Stream Deck is connected via USB with the computer running OBS. So the websocket client will run on the same machine as OBS and therefore binding obs-websocket to localhost instead of 0.0.0.0 would be enough. In that case, obs-websocket would not be accessible from outside and setting a password would not be needed.

Technical information
  • Operating System : Linux (Ubuntu)
  • OBS Studio version : 26.1.2+dfsg1-1
  • obs-websocket version : 4.9.0

PS: I am currently packaging obs-websocket for Debian/Ubuntu.

@tt2468
Copy link
Member

tt2468 commented Jun 20, 2021

It sounds like the problem you have is that you don't want to use a password on your applications. Luckily, you have the option to disable password authentication. Adding functionality to only bind to loopback interfaces has little direct use as I see it.

The main reason we made authentication enabled by default is because malicious website owners would be able to embed JS into their pages which would connect to any locally hosted OBS instance. In this scenario, binding to loopback would be useless anyway.

@bdrung
Copy link
Author

bdrung commented Jun 20, 2021

Valid point that JS code could connect to any locally hosted OBS instance.

I do not want to disable the password authentication when the service is not bound to the loopback interface, because I don't want to make the service available in my local network.

@tt2468
Copy link
Member

tt2468 commented Jun 20, 2021

In that case, I suggest blocking access to obs-websocket via UFW or an alternative firewall.

@FlyingFathead
Copy link

FlyingFathead commented Nov 19, 2024

It should really be listening on localhost only by default.

This is just a bad oversight and extremely lazy security thinking atm. It's baffling that this is somehow "okay".

The fact that you're listening on 0.0.0.0 instead of 127.0.0.1 by default and that there's not even an option to change it -- it goes against all basic network security principles. It's basically an accident waiting to happen once you leave that on, as others have noted in threads related to this issue.

@idc77
Copy link

idc77 commented Jan 3, 2025

Tbh why not just have an IP address parameter?
0.0.0.0 listening is an accident bound to happen, and not encrypted.
Did the Snowden revelations completely pass you by? @tt2468

@drt24
Copy link

drt24 commented Feb 14, 2025

Looks like there is a pull request to add a command line option that fixes this problem: #1279. In my case on Linux on Wayland running as a normal user I need to use websockets to enable a global hotkey to trigger starting and stopping the recording. I don't need any remote access and I don't want OBS listening on the external network interfaces (even if the firewall should stop traffic actually arriving at them).

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

5 participants