[rank0]

This is amazing.

I’m imagining all the ways I could use this for offensive security tools.

If I had a way to import a js library that enabled running web servers, invoking OS commands, or running a reverse http proxy I’d be able to do so much damage to any target client.

[rezonant]

It doesn't let you escape the browser sandbox.

> Sockets include support for TCP socket servers and clients, making it possible to run applications like databases and HTTP servers *together with their clients in the browser*.

Emphasis is mine. You need to run the server and the client within Browsix. Furthermore the "OS commands" are commands within the Browsix environment.

[rank0]

Ah thanks for pointing that out.

But nonetheless, this is useful technology for a malicious actor.

For example, a functioning http server would enable an http proxy that could intercept/modify requests made from the client no?

Now I can add headers to requests made by an html form submit. This might allow for more potent csrf attacks, or circumvention of controls like the HttpOnly cookie flag.

Can I use a victims browser as a c2 server now? I bet with some brainstorming we could come up with some creative offensive capabilities using this technology.

[rezonant]

No, you can't start a web server within Browsix that can accept connections from outside Browsix.

Just like you can't do that in regular JavaScript in the browser.

[rank0]

I see. So an form submit POST request could not actually be sent to Browsix?

[rezonant]

That's right, unless the form was running in Browsix, or I suppose at least the same browsing context (ie same origin on the same browser instance on the same computing device) since you could emulate submission across multiple tabs of the same website using something like the BroadcastChannel API[1]

[1] https://developer.mozilla.org/en-US/docs/Web/API/Broadcast_C...

EDIT: To be clear, this would require effort (TM)- the form would need to have a Javascript onsubmit handler and use preventDefault to stop the browser itself from handling it in order to facilitate that

[rank0]

Neat! Thanks for working on this project and answering my questions.

Perhaps I need to look into it more but what you’re describing isn’t exactly far fetched.

With a csrf attack the victim has navigated to a malicious web app where the cross origin request does originate from the same browser instance where my hypothetical browsix http proxy is running.

Since I control the malicious app, I don’t see why I wouldn’t be able to have an onsubmit handler that proxies requests into browsix.

I’m not saying there’s guaranteed offensive use cases here…it’s just my intuition telling me it’s worth looking into for myself.

My comments aren’t intended as a criticism of your library. If I got a client to navigate to a web app I control there’s plenty of js-enabled damage to be caused without browsix.