Normally when we create an HTTP REST endpoint, we add code to our server endpoint, and assume the client provides the arguments to our code. What if we could reverse this responsibility, such that the client provides the code the server executes?
Among other things, this implies we can have one endpoint doing “everything”. We wouldn’t need to create dozens of endpoints to expose our API, and we could get away with creating a single endpoint, that clients invokes, regardless of what they want to do. If the client wants to create a record in our database, read records from our database, or count records in our database is irrelevant – He’d still use the same endpoint for all of these tasks. In addition, the client could become much more creative in regards to how he interacts with our API, and do things we couldn’t even imagine as we created our API. The latter of course sums up the problem, which is that clients could inject malicious code into our server.
Securing your lambda functions
However, if we had a method to make sure the client was never able to inject malicious code into our endpoint, we could safely allow him to inject code and execute his code on our server, even without knowing what his code does, or even caring about who the client is for that matter. The latter is actually possible in Hyperlambda due to a feature I just released yesterday called “whitelist”. Whitelisting keywords and functions in Hyperlambda allows me to create an execution context where only the stuff I consider to be safe are allowed to be executed. This allows me to avoid having clients doing stuff such as for instance.
- Reading passwords from my configuration files
- Deleting database tables
- Creating malicious files
- Etc …
This is only possible in Hyperlambda due to the fact that Hyperlambda is a “virtual execution machine”, kind of like ByteCode or the CLR, only way more structured. This again allows me to create a list of keywords and functions that I allow for being executed within an execution context, and have all other function and keyword invocations throw an exception, never even being executed. Let me show you some code.
The above code is actually Hyperlambda intended to become an HTTP REST endpoint. To invoke it, you can pass in a payload such as the following.
If you put the first code above into a file called e.g. “evaluate.patch.hl” in your modules folder, for then to invoke the endpoint and pass in the second code snippet from above, what will occur is as follows.
- Your code will be passed into the HTTP REST endpoint
- Your code will be structurally parsed, resulting in a “lambda” structure
- The lambda will be added to the above [.lambda] node
- A new [whitelist] scope will be created
- Your code will be executed within this secured whitelist scope
This process prohibits the user from invoking anything not explicitly declared inside of the above [vocabulary] node, which means that if the user tries to invoke for instance [config.get], to read configuration settings, an exception will be thrown. Only the following functions and keywords are allowed in the client’s code.
If the client attempts to invoke anything not found in the above list, my server will throw an exception. And of course, since I whitelisted vocabulary above, the client can query my endpoint, to ask it what functions and keywords he’s allowed to use in his code. Watch me demonstrate the concept in the following video.
This reversed responsibility way of thinking about your HTTP endpoints, results in many interesting scenarios. For instance, the Ethereum cryptocurrency network is exclusively built upon similar ideas, except referring to this is “smart contracts”. However, in Ethereum a client can easily inject malicious code, something Microsoft research proved a long time ago. Once a client injected malicious code, and as a consequence 50 million dollars was lost. Later they patched and forked the network as a consequence, trying to fix the problem – But with Hyperlambda endpoints, such a scenario couldn’t even exist in theory, assuming you trust its [whitelist] functionality, and don’t whitelist dangerous keywords and functions.
Basically, it becomes the very implementation of what we have referred to as the “semantic web”, where web servers and clients can “communicate with each other”, speaking a common language, being the sub set of a vocabulary, explicitly allowed by the server. Resulting in a common language, understood by both parties, allowing them to communicate semantically with each other. Hence, it becomes a common platform of understanding, between two distinctly different parties, that normally have no ideas about what the other party is even trying to communicate. Or to use an analogy.
It allows us to communicate with aliens