You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 8, 2021. It is now read-only.
Hello stackery folks, I wanted to get an opinion on whether integrating with an OSS project we're building at Polyverse would be of any interest.
Free-as-in-speech: It's free in the way that you take it, and make billions off of it, and we'll be happy for you. There's no catch (and if you foresee any, happy to license/legalese/sign-something stating that it won't be ever.) We have no interest in backdoor monetizing this. We literally built it to see if it could be done, and whether it could be seamless to utilize. And it worked!
We had the idea of stopping code injections in PHP by just-before-deployment changing the PHP built-in keywords/symbols (over time we want to change the AST/Grammar itself), transforming the closure to this new "language", and deploying it. Nothing changes for the developer, but everything changes for the attacker, especially with things like unguraded eval()s and what not.
More details here: One of our open source (the kind where you can fork it and make billions off of it and we'll be happy for you) R&D projects is called Polyscripting where we generate a new PHP runtime right at deployment, unique to a particular closure of execution.
The intent behind this is project is to effectively make code-injections impossible, by evading against the attack entirely (and detecting an attempt thanks to the syntax error.)
Background:
Hello stackery folks, I wanted to get an opinion on whether integrating with an OSS project we're building at Polyverse would be of any interest.
Free-as-in-speech: It's free in the way that you take it, and make billions off of it, and we'll be happy for you. There's no catch (and if you foresee any, happy to license/legalese/sign-something stating that it won't be ever.) We have no interest in backdoor monetizing this. We literally built it to see if it could be done, and whether it could be seamless to utilize. And it worked!
We had the idea of stopping code injections in PHP by just-before-deployment changing the PHP built-in keywords/symbols (over time we want to change the AST/Grammar itself), transforming the closure to this new "language", and deploying it. Nothing changes for the developer, but everything changes for the attacker, especially with things like unguraded
eval()
s and what not.More details here: One of our open source (the kind where you can fork it and make billions off of it and we'll be happy for you) R&D projects is called Polyscripting where we generate a new PHP runtime right at deployment, unique to a particular closure of execution.
We call the approach Polyscripting: https://polyverse.com/polyscripting/
The intent behind this is project is to effectively make code-injections impossible, by evading against the attack entirely (and detecting an attempt thanks to the syntax error.)
We prototyped deploying this to lambda: https://github.com/polyverse/pxp-lambda
We've merged it in Wordpress: https://www.katacoda.com/polyverse/scenarios/polyversepolyscripted-wordpress-v2
Here's a detailed whitepaper of the concept/internals:
Polyscripting-10-18.pdf
Any interest?
Would this be of interest to the PHP lambda layer? Happy to answer any questions and discuss.
If there is interest, we're happy to invest in integration.
Definitely let me know your thoughts, opinions, and don't hold back criticism!
The text was updated successfully, but these errors were encountered: