[Feature request] Inject custom javascript

Duckle29 commented

2017-08-17 16:11:33 -05:00

(Migrated from github.com)

It would be nice if you could add some custom javascript to be run along with the custom css :)

👍 27

OfficialSmudge commented

2017-08-21 16:33:20 -05:00

(Migrated from github.com)

I agree. Similarly, it would be nice to have a developer console to view errors or run code directly

👍 4

macharborguy commented

2017-10-31 11:29:31 -05:00

(Migrated from github.com)

@OfficialSmudge Developer console is already available. You need to run OBS Studio itself with the flag "--remote-debugging-port=PORT" where PORT is the port you wish to use to access the remote debugger.

Then simply load "http://localhost:PORT" in a browser to access the console.

@OfficialSmudge Developer console is already available. You need to run OBS Studio itself with the flag "--remote-debugging-port=PORT" where PORT is the port you wish to use to access the remote debugger. Then simply load "http://localhost:PORT" in a browser to access the console.

👍 10

kuhnchris commented

2018-10-06 16:26:18 -05:00

(Migrated from github.com)

Hi there, I added a new pull request solving this feature, would you mind checking it out on other platforms? I only was able to check it on MacOS since that's the only build platform available for me right now.

https://github.com/obsproject/obs-browser/pull/137

Thanks!

Hi there, I added a new pull request solving this feature, would you mind checking it out on other platforms? I only was able to check it on MacOS since that's the only build platform available for me right now. https://github.com/obsproject/obs-browser/pull/137 Thanks!

👍 1

RytoEX commented

2018-10-07 00:41:38 -05:00

(Migrated from github.com)

As an aside, this seems to be a duplicate of Issue #56, though that may not have been immediately apparent.

rogueyoshi commented

2019-01-15 18:44:16 -06:00

(Migrated from github.com)

Hi there, I added a new pull request solving this feature, would you mind checking it out on other platforms? I only was able to check it on MacOS since that's the only build platform available for me right now.

#137

Thanks!

will this be merged into master? OBS very badly needs this.

> Hi there, I added a new pull request solving this feature, would you mind checking it out on other platforms? I only was able to check it on MacOS since that's the only build platform available for me right now. > > #137 > > Thanks! will this be merged into master? OBS very badly needs this.

kuhnchris commented

2019-01-16 08:40:30 -06:00

(Migrated from github.com)

@rogueyoshi well, this PR ( #137 ) is still open, so I assume if someone wants to pick it up it should work pretty much instantly right now. It did at least for me while i was playing around with OBS. I'm not an active streamer (never was, sadly), so I cannot tell you if any problems arise, but I assume that it works fine.

Voldi87 commented

2019-04-17 10:04:25 -05:00

(Migrated from github.com)

How can I open the Javascript box? I don't see it.

kuhnchris commented

2021-01-08 05:43:28 -06:00

(Migrated from github.com)

As I experimented with trying to auto-pull master changes in, #137 is closed as it auto-closed due to the changes from master force-pushed being in. The changes now live in my repository in the javascript branch, so this should avoid issues like this. The question still stands, as it was noted in #137 - are the security implications worth the effort? We need someone to make a decision if the current implmentation is enough or if we need any additional checkboxes, checkes, etc. to ensure no harmful code is executed.

On a related note: isn't the CEF sandboxed anyways, or do we have access to file system and other components without a user prompt/without having to start OBS with additionally malicious flags?

I do get the security implications, but the question here is, how hard do we need to make it for a user to use it v.s. the actual use. You are as little responsible for user entering malicious code as the bash devs are for someone pasting a fork-bomb or crashing their system. A certain amount of security (message, maybe a alert box when you check the checkbox, etc.) is OK, but we cannot cover all possible cases where users are being unreasonable.

Let me know and I'll reopen a PR.

As I experimented with trying to auto-pull master changes in, #137 is closed as it auto-closed due to the changes from master force-pushed being in. The changes now live in my repository in the javascript branch, so this should avoid issues like this. The question still stands, as it was noted in #137 - are the security implications worth the effort? We need someone to make a decision if the current implmentation is enough or if we need any additional checkboxes, checkes, etc. to ensure no harmful code is executed. On a related note: isn't the CEF sandboxed anyways, or do we have access to file system and other components without a user prompt/without having to start OBS with additionally malicious flags? I do get the security implications, but the question here is, how hard do we need to make it for a user to use it v.s. the actual use. You are as little responsible for user entering malicious code as the bash devs are for someone pasting a fork-bomb or crashing their system. A certain amount of security (message, maybe a alert box when you check the checkbox, etc.) is OK, but we cannot cover all possible cases where users are being unreasonable. Let me know and I'll reopen a PR.

marcusviar commented

2021-01-16 17:26:58 -06:00

(Migrated from github.com)

It's no more insecure than the console in any browser, which is available to every browser user regardless of their knowledge of what could happen when pasting in code they don't understand.

A simple message would be enough to warn users. If you look at your browser's console when on facebook, they show a simple warning message.

I think the benefits of being able to inject custom javascript outweigh the security risks, as long as users are warned with a message.

It's no more insecure than the console in any browser, which is available to every browser user regardless of their knowledge of what could happen when pasting in code they don't understand. A simple message would be enough to warn users. If you look at your browser's console when on facebook, they show a simple warning message. I think the benefits of being able to inject custom javascript outweigh the security risks, as long as users are warned with a message.

👍 1

helloitsdani commented

2021-04-03 13:10:19 -05:00

(Migrated from github.com)

I agree--whilst it's theoretically possible for JS injection to be misused, it presents a similar level of danger to the console already available in all major browsers. A warning message (maybe something pre-filled in the box?) seems like a good solution, and it broadly follows other messages warning about the same dangers. I think JS injection is a fairly common use case for using things like Discord's StreamKit, browser-based overlays, etc, which have all become pretty essential parts of the streaming ecosystem.

Did you ever re-raise that PR, @kuhnchris?

I agree--whilst it's theoretically possible for JS injection to be misused, it presents a similar level of danger to the console already available in all major browsers. A warning message (maybe something pre-filled in the box?) seems like a good solution, and it broadly follows other messages warning about the same dangers. I think JS injection is a fairly common use case for using things like Discord's StreamKit, browser-based overlays, etc, which have all become pretty essential parts of the streaming ecosystem. Did you ever re-raise that PR, @kuhnchris?

kuhnchris commented

2022-02-25 09:50:50 -06:00

(Migrated from github.com)

I agree--whilst it's theoretically possible for JS injection to be misused, it presents a similar level of danger to the console already available in all major browsers. A warning message (maybe something pre-filled in the box?) seems like a good solution, and it broadly follows other messages warning about the same dangers. I think JS injection is a fairly common use case for using things like Discord's StreamKit, browser-based overlays, etc, which have all become pretty essential parts of the streaming ecosystem.

Did you ever re-raise that PR, @kuhnchris?

sorry for the very long radio-silence. I talked to the guys over in the OBS Discord about 1 or 2 years ago and they were telling me to actually hold on tight for the CEF upgrade, as this would change significant things.
With the new OBS version (and new version of obs-browser) there were a couple of changes that broke javascript injection, and I was personally contacted on discord regarding a fix for this, so I re-raised the PR on this issue.
If anyone else needs the change in question, pull in that branch in #354 and let me know how it goes for you guys.

Thanks,
Chris

> I agree--whilst it's theoretically possible for JS injection to be misused, it presents a similar level of danger to the console already available in all major browsers. A warning message (maybe something pre-filled in the box?) seems like a good solution, and it broadly follows other messages warning about the same dangers. I think JS injection is a fairly common use case for using things like Discord's StreamKit, browser-based overlays, etc, which have all become pretty essential parts of the streaming ecosystem. > > Did you ever re-raise that PR, @kuhnchris? sorry for the very long radio-silence. I talked to the guys over in the OBS Discord about 1 or 2 years ago and they were telling me to actually hold on tight for the CEF upgrade, as this would change significant things. With the new OBS version (and new version of obs-browser) there were a couple of changes that broke javascript injection, and I was personally contacted on discord regarding a fix for this, so I re-raised the PR on this issue. If anyone else needs the change in question, pull in that branch in #354 and let me know how it goes for you guys. Thanks, Chris

👀 3 ❤️ 6

dcmouser commented

2023-04-05 21:32:45 -05:00

(Migrated from github.com)

I just wanted to say thank you for sharing this work -- the ability to modify the javascript on a page is extremely useful.

👍 2

Warchamp7 commented

2023-08-08 17:38:54 -05:00

(Migrated from github.com)

I think any sort of automated injecting of javascript opens up too many potential concerns, especially since source settings can be silently manipulated via things like obs-websocket. I do not think we will implement this, at least not in an automated way. Custom css is already a rather aggressive injection from a security standpoint.

We do not have a way like Greasemonkey/Tampermonkey which would that ensures a user is 100% aware of injected javascript on a browser source beforehand, since sources can be manipulated by third parties, or pre-configured with it via a scene collection they are shared, etc. etc.

The console for a given browser source can be accessed via remote-debugging-tools for any one-off cases. If you are trying to do something complex enough that it requires injecting javascript, I'd argue it should instead be done properly via APIs for that service. If it is ONLY possible via direct js injection for one reason or another (such as a lack of API) then that should be an extremely deliberate process done via the debugging tools, and require that explicit effort every time.

I think any sort of automated injecting of javascript opens up too many potential concerns, especially since source settings can be silently manipulated via things like obs-websocket. I do not think we will implement this, at least not in an automated way. Custom css is already a rather aggressive injection from a security standpoint. We do not have a way like Greasemonkey/Tampermonkey which would that ensures a user is 100% aware of injected javascript on a browser source beforehand, since sources can be manipulated by third parties, or pre-configured with it via a scene collection they are shared, etc. etc. The console for a given browser source can be accessed via remote-debugging-tools for any one-off cases. If you are trying to do something complex enough that it requires injecting javascript, I'd argue it should instead be done properly via APIs for that service. If it is ONLY possible via direct js injection for one reason or another (such as a lack of API) then that should be an **extremely** deliberate process done via the debugging tools, and require that explicit effort every time.

👎 13

barkermn01 commented

2024-04-28 14:54:30 -05:00

(Migrated from github.com)

since sources can be manipulated by third parties

Understanding security principles is crucial, especially for those working in application security. For instance, if a WebSocket system's security is the compromise entry point , it would be prudent to block the property from being written by the WebSocket system. If that's not possible, then the system's security may be deemed a failure and, following the logic you have used as to why injecting JS as you just made means the WebSocket system should be removed. (I'm not advocating for that just showing the hypocrisy of your argument).

It's clear that the WebSocket API should not expose such risks. Injected JavaScript should only be possible through the OBS UI. If that's not possible as it currently stands, it indicates that the WebSocket API is automatically built from the properties of everything without a basic flag from a base/abstract class using inheritance.

Programmers must avoid assuming they understand security or adopting a mindset of 'thinking' something is secure without proper security training. More often than not, this leads to errors, such as being overly aggressive in one area while being lax in another. As an example, the WebSocket system should have a property to exclude properties from alteration by WebSocket API if a flag indicates 'expose all by default,' then it should have a "exclude properties list" as a property or conversely, 'include properties list property' if the flag is not set to expose all, using a base class to maintain these states for children to override would be very easy then the WebSocket API knows these properties exist for validation.

>since sources can be manipulated by third parties Understanding security principles is crucial, especially for those working in application security. For instance, if a WebSocket system's security is the compromise entry point , it would be prudent to block the property from being written by the WebSocket system. If that's not possible, then the system's security may be deemed a failure and, following the logic you have used as to why injecting JS as you just made means the WebSocket system should be removed. (I'm not advocating for that just showing the hypocrisy of your argument). It's clear that the WebSocket API should not expose such risks. Injected JavaScript should only be possible through the OBS UI. If that's not possible as it currently stands, it indicates that the WebSocket API is automatically built from the properties of everything without a basic flag from a base/abstract class using inheritance. Programmers must avoid assuming they understand security or adopting a mindset of 'thinking' something is secure without proper security training. More often than not, this leads to errors, such as being overly aggressive in one area while being lax in another. As an example, the WebSocket system should have a property to exclude properties from alteration by WebSocket API if a flag indicates 'expose all by default,' then it should have a "exclude properties list" as a property or conversely, 'include properties list property' if the flag is not set to expose all, using a base class to maintain these states for children to override would be very easy then the WebSocket API knows these properties exist for validation.

Rows
Columns

[Feature request] Inject custom javascript #87