canhorn / eventhorizon.blazor.interop Goto Github PK

Hello, there!

As part of the university research we are currently doing regarding the security of Github Actions, we noticed that one or many of the workflows that are part of this repository are referencing vulnerable versions of the third-party actions. As part of a disclosure process, we decided to open issues to notify GitHub Community.

Please note that there are could be some false positives in our methodology, thus not all of the open issues could be valid. If that is the case, please let us know, so that we can improve on our approach. You can contact me directly using an email: ikoishy [at] ncsu.edu

Thanks in advance

1. The workflow dotnet-package.yml is referencing action gittools/actions/gitversion/setup using references v0.9.6. However this reference is missing the commit 90150b4 which may contain fix to the vulnerability.
2. The workflow dotnet-package.yml is referencing action gittools/actions/gitversion/execute using references v0.9.6. However this reference is missing the commit 90150b4 which may contain fix to the vulnerability.
3. The workflow main-tag-bump.yml is referencing action gittools/actions/gitversion/setup using references v0.9.6. However this reference is missing the commit 90150b4 which may contain fix to the vulnerability.
4. The workflow main-tag-bump.yml is referencing action gittools/actions/gitversion/execute using references v0.9.6. However this reference is missing the commit 90150b4 which may contain fix to the vulnerability.

The vulnerability fix that is missing by actions' versions could be related to:
(1) CVE fix
(2) upgrade of vulnerable dependency
(3) fix to secret leak and others.
Please consider updating the reference to the action.

If you end up updating the reference, please let us know. We need the stats for the paper :-)

When nested objects are passed down through the bridge it will not introspect the object properties to see if they might be cached entities.
To fix this the cache should be checked against the child properties.

I'm not sure if the problem comes from EventHorizon or BabylonJS itself.
scene.pointerX seems to work (but actually returns an integer instead of decimal)
scene.pointerY throw a Format Exception (although checking the string representation gives a proper decimal).

I get the values as string to check

var x_ = EventHorizon.Blazor.Interop.EventHorizonBlazorInterop.Get<string>(scene.___guid, "pointerX");
var x = scene.pointerX;
var y_ = EventHorizon.Blazor.Interop.EventHorizonBlazorInterop.Get<string>(scene.___guid, "pointerY");
var y = scene.pointerY;

x_ = '58'
y_ = '251.40625'

This would remove the need to add a <script> tag with the interop-bridge to every project that uses this library.

https://docs.microsoft.com/en-us/aspnet/core/blazor/call-javascript-from-dotnet?view=aspnetcore-5.0#blazor-javascript-isolation-and-object-references

Using EventHorizon.Blazor.TypeScript.Interop.Generator creates a method calling FuncArray for a type that returns a TypedArray.
This fails the Array.isArray check and returns an empty result.

An example of this is when converting BabylonJS the Mesh.getVerticesData fails to return the data (FloatArray) https://doc.babylonjs.com/typedoc/classes/babylon.mesh#getverticesdata.

Not clear if this is an issue in Interop or Interop.Generator sorry.

Description

Calling set with a null value causes an error.

EventHorizonBlazorInterop.Set(___guid, memberName, null);

Suggested Solution

A simple null check in the interop-bridge.js before looking up the cacheKey should suffice. Sometimes null is desired instead of a property being simply undefined.

• Create a PoC

Hi, I noticed there isn't any mechanism for removing objects from the JS cache. I think it would be possible to implement it using a finalizer in the CachedEntity class.