WordPress codebase is extremely secure, however, considering the fact that a majority of sites run on WordPress it does create great incentives for hackers to attack WordPress sites using code injection techniques. Most WordPress users are not tech-savvy enough to protect their sites, that’s where Polyverse enters the picture and brings it polyscripting technology to WordPress to make them even more secure.

In this interview, CTO of Polyverse talks about this technology and how users can benefit from it.

[expander_maker]

Swapnil Bhartiya: Archis, first of all, thanks for coming on the show. I want to know from your perspective, how secure or vulnerable are the sites that are powered by WordPress?

Archis Gore: So surprisingly they’re very, very secure, right? They’re doing the best that they can. That being said, we do have a lot of code injection attacks happening almost every week, but it’s a systemic problem and it’s not a WordPress problem. So I want to be clear though, the space that WordPress owns on a website, the area that it plays in, it does a very good job of protecting you.

Swapnil Bhartiya: You talked about code injection. Talk about that a bit, that what real threats are there?

Archis Gore: Yeah. So, what code injection really means is WordPress has code and it’s all PHP and it’s all shipped in pure source code, right? So when you’re running your website, all your plugins for WordPress, your teams, everything, all the source code is on the production server at all times.

What code injection simply means is code that you don’t want running is now able to run, and it can run through a variety of ways. People can upload an image, a JPEG that actually contains PHP inside, and your web server can see the PHP header and say, “Hey, even if the extension is JPEG, I’m going to execute this because I’m going to be helpful”. Or you can have an eval where a URL parameter or some form post comes in and you just, it concatenates into a string and then it gets eval, much like SQL injection. And so, in short code injection is any code that you don’t want that you did not approve is now running.

Swapnil Bhartiya: Excellent for explaining that. Now, how to protect your site against that?

Archis Gore: So to solve this problem, there’s a, there’s a couple of different things that we as in the industry have looked at, right? The most prominent one would be code signing where you sign a bunch of code and you say, this is the code that I prove. And if you didn’t sign it, I’m not going to run it. For whatever reasons, for many reasons, technical reasons, code signing is not widely deployed or widely effective. And that’s, it’s just cumbersome, not impossible. It’s not wrong. It just… Is there pragmatically useful? Not today. What we do about it is we basically say, Hey, if we can just change the programming language entirely, right?

So, so I always like to use the example of a chef who is communicating their secret recipe to their franchisees, and you can communicate the recipe in English and then people can just modify it, steal it, whatever. But if you just use a new language every day, you use Italian and French and Swahili, and each day you’re using a different language to share that recipe.

Of course, you need highly educated chefs reading it, but you protect it. So we do the exact same thing for WordPress. Right before WordPress starts, we produce a brand new programming language that’s based on PHP, but it’s not PHP. And this new language can no longer understand the regular PHP. We then take all of your code that you say, “this is the approved code”. We transform all of that coordinate into a new language and then we run it. Now it has no performance impact. There’s no problem, right? Everything runs exactly as it should, but unwanted code, whether it’s through eval through an injection, through a file upload doesn’t matter. I don’t speak PHP anymore, right. And so that’s how you catch it, you trap it, you stop it just unilaterally.

Swapnil Bhartiya: What is Polyscripting for WordPress and how does it work?

Archis Gore: So Polyscripting is an overall technology that we developed and we’re patenting as we speak. And what it really does is it changes programming languages, dynamically. So all interpreted languages along with all code that speaks those languages. And the Holy grail for us is SQL obviously, but we’re a couple of years away from getting there. So as a technology, we do Polyscripting for AWS Lambdas and Node.js. And we’re even bringing it to the browser as we speak. And this is intended to prevent unwanted code from executing, by changing the language.

For WordPress specifically, it’s a package solution and so how it works is at the base layer we provide, it’s very simple, really, today we ship it as a Docker container. We can turn on the VM. We have some core infrastructure that can flip or change PHP. And then what happens is you just use WordPress as you do. And then when you’re ready to lock it down, you press a little button on the WordPress UI, and you say, “Polyscript, this”, and you press this button and everything behind the scenes gets transformed.

And now regular PHP is no longer valid. And if you want to make changes, updates, you just say, “un-Polyscript this”. And then it just goes backward 100%. Or you can re-Polyscript and you can say someone just stole one of my files. They probably know this new language over time, just go in and do it again. And that’s how it really works. And I don’t want to call out that your original PHP code is 100% untouched. There is no change to that. So, there is no loss of code. There is not… So if Polyscripting fails, if we screw up, nothing’s lost.

Swapnil Bhartiya: Who is your target audience here? Are these independent bloggers who run WordPress? Or are these companies, talk about that?

Archis Gore: Our ideal target audience is self-hosted WordPress people, right? Running very large websites that they self-host because they have to be large scale, highly available. I don’t know if you knew this, but about 28% of all internet transactions happen through WooCommerce, the WordPress internet-commerce plugin. Literally a quarter of the Internet’s online banking, not banking, but financial transactions happens on WordPress. It’s a big deal. And so for all of those people they are our primary audience to sort of kick out this attack vector just 100% and make sure that it’s no longer applicable. Our other audiences, also professional service providers who get asked constantly by their customers who say, “Hey, I’m going to get hacked. What can you do about this?” And customers don’t want to hear tolerance as fake. Customers don’t want to hear, like 98% of the time serve with one Sigma accuracy, whatever. Customers just want a paintbrush. And it’s painted over this and make it go away. And so that’s what we bring to those, to those professional service providers.

Swapnil Bhartiya: Okay. So does it also include those web hosting provider? Like Linode is one of them they also offer self-hosting versus they also offer WordPress as one of the… Is it for them also?

Archis Gore: Yes. Yes. It’s absolutely for 100% of the WordPress audience, just to be clear, but the hosting providers, we talked to them. And so what I mean by that is one of my personal core principles is consumers should never, ever worry about security. They should just get it.

Swapnil Bhartiya: So, No. The reason I was asking was that depending on who your target audience is. Like, if you’re talking about web hosting providers or the company service providers, they do have the capabilities. So it also depends on what kind of business model you have. How you are offering your service to the customer? Can you talk about that piece?

Archis Gore: So it’s very simple. We provide a licensed store technology and we just basically license it per site. And then of course for the large scale hosting, it would just be like a small flat fee that just applies to a whole domain or for hosting providers. It’s again like just B2B licensed where just pay, bring it to all of your people.

Swapnil Bhartiya: So let’s say I add on my site on WordPress, how do I get it?

Archis Gore: If you self host, then we basically just work with you to install it. It takes about five minutes. We change our… We installed some scripts, just some shell scripts. And all of this code is open by the way. And we share everything with you and we just installed those things a little bit. There’s a document that walks you through it, takes about 10 to 15 minutes. And then you install a plugin to enable and disable Polyscripting. And so that’s all entirely a WordPress console provider, but we do need to get on the underlying OS so that we can control the PHP and make sure. So, the key thing is not to just scramble the PHP, right? It’s to make sure that the old PHP interpreter cannot exist. If it exists, then you can run old PHP code.

Swapnil Bhartiya: Now if you look at WordPress. I mean, if you go to the WordPress market space, there are thousands, I wouldn’t say million, but thousands of plugin. So don’t you think there is already something similar already for WordPress security.

Archis Gore: So, no. And the reason is, I’ll go at it in two different ways, right? One is the data just doesn’t prove it, right? And by data I mean like let’s ask for insurance, right? If I wanted to say, “I don’t want any code injection ever working on my website, can I pay someone?” And can they basically say, “yeah”. Since you’ve installed my plugin I can assure you of that. And so not only does that data not prove it, but every single week we have a new code injection problem that shows up. What actually motivated us was the big Drupal problem from about a couple of years ago, I think, early 2018. And then the second part is just technical, right? Which is you because it’s PHP code, there is no way to look at a piece of code and say whether it’s approved or good code and unapproved or bad code. That’s just a queuing complete problem, we can’t solve it.

Swapnil Bhartiya: WordPress has been around for a long time, it has its own problem, it has been solving their problem. Why do you suddenly think that WordPress needs this solution? What changed, why you felt the need of bringing Polyscripting to WordPress?

Archis Gore: That’s a really good one because the company philosophy for us is, how we actually go about doing it is we look at, so our mission is to solve cybersecurity, right? It is to look at a problem and say, “What can someone just do?” And then make the problem not exist. Not kind of sort of reduce it, but just make it completely go away. And then we look at statistics every year and we look at like, Hey, what are the top attack vectors? Now, when we started memory-based problems for the top attack vector, right? So then we created Polymorphing for Linux. And we that’s the product line that’s going to be about two or three different product lines with extreme sophistication, for blind drop and Jetdrop and various other things, right?

Then we looked at, Hey, what’s the number two? And it was code injection. So we said, “Okay, we’re just going to go solve code injection.” And how can we come up with a systemic way that code injection, the problem not for WordPress, not for Lambda, not for Node.js, but what is that a uniform way of just taking it away from all of these? And so, thus came Polyscripting and to track that forward, the current top problem is XSS and it bypass memory protection, memory problems in 2019, at the end of 2019. And so, as you might imagine, all of our resources right now are going on to go tackle that.

Swapnil Bhartiya: Since you are trying to make all these problems go away, in terms of cybersecurity, you have tackled Linux, you have tackled WordPress, two big players in the web interface, that were. Are you going to move forward and offer it to Drupal, Joomla, and all of CMS? Plus there are a lot of headless CMSs. I mean, there are so many things. So the question that I have for you is, I know you may not be able to share your roadmap, from product announcement perspective, but is that what it looks like?

Archis Gore: That’s exactly what it looks like. So, Polyscripting for PHP basically does solve Drupal, right? But, as we spoke about with that experience, that packaging, that solution, we picked WordPress first. But if anyone who is watching and if they want to do this for Drupal, the code is ready, right? And it works. We just… That beautiful packaging. As everyone who’s written a program knows, right? The 90% is 10% effort, right? The documentation, the packaging, the screenshots, the working with people, the support, the help, the troubleshooting. All of that takes a lot of energy. And so for Drupal is going to be absolutely next. And then headless CMSs we’re going for solving Node.js. We’re solving Lambdas with Node.js as a first shot, because it’s simpler. It’s more packaged, more modern, but we do want to go after all the Node.js Websites and take away JavaScript code injections as well.

[/expander_maker]