Post

2 followers Follow
0
Avatar

Security concerns with client side parameters

With many video settings implemented through parameters on the embedded Ziggeo client I am concerned about the possibility of attacks where a user overrides the client side settings and uploads with no limits.

Consider the parameters: `expiration-days`, `timelimit`, `videobitrate`, `audiobitrate`. All of these could be changed by a client allowing them to upload arbitrarily long videos at high bit-rates with no expiration. Since these are not tied to the auth token a user could get an auth token legitimately, then load the recorder with their custom parameters with no way to reject them.

Is there any way to enforce these parameters for the application as a whole regardless of what the client uses?

Alex Stavrinou

Please sign in to leave a comment.

1 comment

0
Avatar

That is a very good question Alex. Definitely something that might cause you to end up with longer videos, or to have setup that you might not like.

For that reason all of the destructive calls or setups are disabled by default. Such as the one you have mentioned - `expiration-days` (for example you need to approve it from the dashboard as well).

Now there are 2 things around this that can help:

1. we will have a global parameters setup in near future

 * This will allow you to set everything within your account and then just reference it as a template name within the embedding. If someone was to change it differently, it would no longer work. Of course this would not stop someone from using some other template name that you have on your website which allows more time or alike.

2. a better approach is to add a detection for this.

There are several ways you can do this. One is by utilizing the JS APIs that allow you to see if any part of DOM is changed at any point. This would allow you to detect when it happens and do any checks you want.

The other approach is easier since it involves our own events.

embedding.on("attached", function () {
//Your code goes here
});

Now the interesting thing about it is that it only fires once the embedding is added to the DOM. If this happens you know that embedding is ready. If it happens again, then you know that something is off.

Let me give you 2 examples how events can be used.

One is that events are associated with specific embedding. That means that they would really need to know the JS in order to recreate the same events that you already hook into in order to be able to go through all of the steps you incorporate.

And of course to do all that through the length of the auth tokens that you have set up (which would be recommended if you think that your audience is likely to do something like that).

Now the second example goes around the fact that the events are embedding specific (and this is most easily seen if you are using all JS codes, not HTML for embeddings).

In this example we can check out the global events for all embeddings. While they are private to embedding by default, we have a way to hook into the global notifications as well.

Now, if your events do not fire (the ones you set up) and the global does, something is off and you can recreate your own embedding on fly, raise alert, etc.

If the attached event fires again and did not fire for your own attached event, something is off, and so on.

For reference:

> list of events (private to embedding): https://ziggeo.com/docs/sdks/javascript/browser-interaction/events

> page to global setup of same events: https://ziggeo.com/docs/sdks/javascript/browser-interaction/application-embedding-events

Hope this helps :)

PS: If your users / audience is likely to make such changes, I would also suggest adding clause into your terms of use that do not allow reverse engineer or modify any part of your code, system or service. That way if you do detect someone doing it, you can just deal with them as per your terms of use or other contract policy you have.

Bane

Bane 0 votes