Hacker News Reader

Comment by i_cannot_hack | Hacker News Reader

I don't know much about this kind of architecture, but wouldn't it be problematic from an infosec standpoint? It seems like it would be very easy to accidentally leak information from the server to the client in a subtle manner if the developer makes a mistake somewhere. And in ways which would not be obvious from reading the code unless you carefully consider the implications of each e/server and e/client with respect to the mentioned graph analysis?

Are there any mitigations in place to prevent this, except the obvious "be careful and don't write bad code"? Or have I misunderstood things completely and it's a non-issue?

View on HN

Just as a data point, this is also true about very much noeadays "vanilla" stacks like Next.js.

It seems like you're doing SSR but not exactly.

You return the wrong prop in a getServerSideProps and boom, your stripe keys are dumped in a nice JSON for all to see.

Yikes!!!

Is anyone aware of automated testing/scanning for secret leakage via js framework magic? If not, how would you implement one?

(founder here) You're right that accidents can happen, and if we need to build in safeguards to prevent accidents (i.e. tag a value as server-only) – that should be trivial. To be clear, your backend still exists and has the same security model as a REST Backend-for-Frontend. The client/server markers denote at compile time where a computation (function) must occur. A scope binding like `password` will only transfer if the programmer asked it to by using it from a client region. That would be like putting passwords in a REST payload – it's a programming bug and should be caught in review. But you're right, providing safeguards is a great idea.

I agree it would be user error, but it seems to be a particularly easy mistake to make compared to the REST example, where you explicitly create REST endpoint to send a value to the client.

If you accidentally move filtering of a list of users from server-scope to client-scope during refactoring, everything will still work just as you expect it to and you'll be none the wiser – but suddenly every user has access to all the user data in the list. There's not many other frameworks I'm aware of where moving an operation to an adjacent row or forgetting to change a word suddenly (and silently) exposes the data to the client – except perhaps PHP, which does not have a good reputation when it comes to security to say the least. Altough to be fair adlpz mentioned something similar with Next.js in another thread.

Tagging values as server-only mostly seems like another thing that could be easily forgotten. Personally I would feel more comfortable if values intended to be sent from the server to client had to be explicitly tagged as mutual, with an optional compilation flag that enforces this, such that the intent to share it with the client must always be stated in plain text during creation.

As a security guy I would say this situation happens with reasonable frequency in REST web frameworks where developers are encouraged to use ORMs[0], and the design of Hyperfiddle/Electric is no more likely to fall victim to it.

I'd actually take a punt that it's less likely because of Clojure's data-orientation. Given that the above mentioned ORM-preferring frameworks typically have to define a whole new class and map the data from a server-side representation to a client-side representation, you're more likely to see developers not bother, forget or bungle the implementation aspect.

What I'm interested in is how Electric Clojure handles mass assignment (unconstrained deserialization)[1], sort of the flip side of excessive data exposure. If an (e/server) s-exp uses the symbol `is-admin?` will the server respect or discard values for `is-admin?` sent from the client?

[0] https://github.com/OWASP/API-Security/blob/master/2019/en/sr... [1] https://github.com/OWASP/API-Security/blob/master/2019/en/sr...

The only way for the client to set a server-side symbol to a value is to explicitly request it in code

    (e/server (let [is-admin? (e/client ...)]))

Even with mutable atoms you'd have to write the `reset!` on the server.

Code is precompiled so you could add all your safeguards during compilation. Should not be too hard to enforce fo only precompiled code to run instead of exposing eval. However, I don't believe this is implemented at this stage.

Accidental code execution vuln might not be the only issue though. How do you know that state which is being checked and verified on server is not bypassed if the application is written without client/server divide? How do you know the data isn't being passed back to the client which should've always stayed on the server?

There is a client/server divide as you can see in the code examples. But I think the issue you're describing is a permissions problem, not a question of whether the compiler manages the network for you. There are traditional client/server apps with wide open permissions that allow all kinds of queries to pass through to a prod DB. Then again there are others that are heavily permissioned. Those are implementation details. If you _can_ control which code can run then you can write that code to _only_ run with certain constraints.

I tried to get hands-on experience with this hyper fiddle stuff a few months ago but I think it was still in closed beta.

I would imagine you can inspect the network traffic. I would hope it would be readable so that you could have a good idea of what's going on and errors would be more obvious.

I see a sample todo app in their repo, so yes, one can run it and check out how it works https://github.com/hyperfiddle/electric-starter-app

Reply on news.ycombinator.com