parse-uri security alert

[christiaanbasson]

Can you please investigate and remedy the parse-uri vulnerability? I have been ignoring the GitHub security warning for the last 6 months and I understand there is low risk given the use-case. If you are not planning to address this I will dismiss the alert, but I hope you can resolve this at source.

Background
parse-uri Regular expression Denial of Service (ReDoS)
An issue in parse-uri v1.0.9 allows attackers to cause a Regular expression Denial of Service (ReDoS) via a crafted URL.
Affected versions: < 2.0.0

Dependency Graph
@ricado/api-client 2.6.1 > socket.io-client 2.5.0 > parse-uri 0.0.6.

@ricado/api-client@latest is 2.6.1
socket.io-client@latest is 4.8.0 (Oct'24) - seems to drop use parse-uri.

[christiaanbasson]

Please also review/include new security advisory for socket.io. This is surfacing as another security vulnerability to api-client in our internal checks.

"socket.io allows an unbounded number of binary attachments"
GHSA-677m-j7p3-52f9

@ricado/api-client 2.7.9 -> socket.io-client 2.5.0 -> socket.io-parser 3.3.4

[ashneilson]

@christiaanbasson Thank you for raising this issue and the concerns about these security advisories.

We have Merged in PR #262 which resolves a few of these, but the parseuri package issue isn't so easily resolved.

We’ve taken the compatible Socket.IO 2.x updates available, but we can’t simply move to newer socket.io-client major versions because our client must remain compatible with the existing Socket.IO 2.x server protocol; the remaining transitive dependency is parseuri@0.0.6 (sometimes referred to as parse-uri in advisories), and in our implementation the realistic risk is limited to cases where an attacker can control the configured WebSocket server URL, so for normal use against the fixed trusted RICADO endpoint this is a low practical risk rather than a remotely exploitable issue.

We do expect to split the API Client and Web-Socket Client responsibilities into separate libraries in the near future, so this library will become simpler and drop quite a few dependencies.

Are you comfortable with this for now @christiaanbasson?

[christiaanbasson]

Thanks @ashneilson . I totally understand the attack surface and probability of it affecting us directly as users of the SDK so comfortable with your approach. Until then it will continue showing up as an annoying security vulnerability and lower our 'score', which I have to keep explaining why we can't fix it ourselves... Any timeline on future remedy that I can use?