https://www.wpwhitesecurity.com/interview-coderisk-free-source-code-analysis-wordpress-plugins/
Vulnerabilities in WordPress plugins have been the cause of more site hacks than vulnerabilities in WordPress core. One of the reasons why this is happening is lack of resources. Software will always have vulnerabilities, though the WordPress core code is vetted by thousands of people. Also, the foundation has resources allocated to ensure that the code is as secure as possible.
On the other hand, many plugin developers do not have the resources available to ensure that their plugins’ code is secure, especially if it is a small plugin. Though that is all going to change, as Hendrik Buchwald explains in this interview. Hendrik is software engineer, security researcher, and co-founder of RIPS Technologies.
What does RIPS Technologies do?
RIPS Technologies is a high-tech company based in Bochum, Germany. We deliver automated security analysis for PHP applications as local software installation or highly scalable cloud service. Our innovative code analysis algorithms, which are specifically dedicated to the PHP language, can identify complex security vulnerabilities in modern applications like no other solution. Our mission is to provide developers and security professionals with the most accurate and efficient security analysis possible.
What would you say is the most common security mistake developers do, and what are the top 3 vulnerabilities you see in WordPress plugins?
Unsurprisingly, the most common issues are cross-site scripting (XSS) vulnerabilities which occur whenever user input is printed without proper sanitization to the HTML response page. For one, these issues appear frequently because the output of data is the most common operation of PHP applications and thus more affected by security violations than other operations. And second, given the diversity of HTML contexts and its pitfalls in sanitization, these issues are easily introduced. Cross-site scripting (XSS) vulnerabilities are quite serious in WordPress because they can be used, for example, to inject PHP code through the template editor. Luckily, they do require interaction with an administrator though.
The second most common issues are SQL injection vulnerabilities. SQL Injections are more severe than cross-site scripting vulnerabilities because in the worst case they can be used to extract sensitive information from the database – for example passwords – without any user interaction at all. As a result they can be used for fully automated malicious attacks.
How good, or bad would you say is the overall security posture of the most popular / downloaded 1,000 plugins?
This is hard to answer because I have not looked at the 1,000 most popular plugins in detail. Such operations would take many months to complete, and by the time we are ready we would need to start again because some plugins are updated very frequently.
Hence why it is important to use an automated security service such as Code Risk. Though from the CodeRisk score, which is generated from the automated and non-verified source code scans we do on the repository, I can say that the code of most is not bad, though there are also plugins with bad score. Most of these plugins are very large though and have a lot of functionality. This automatically increases the chances of having a bug somewhere. From our manual tests we can also say that the big plugins often times have logical vulnerabilities.
Can you tell us a bit about what you are offering to WordPress plugin developers?
Our latest project CodeRisk helps developers and users assess the security risk of their plugin’s code for free. For now this is limited to WordPress plugins that are hosted in the official WordPress repository.
We are automatically fetching new plugins from the WordPress repository and scanning them with our PHP security scanner RIPS. The detailed results of RIPS are combined into an easy to understand risk value. The value takes into account the severity of successful exploitation, the quantity of found issues in relation to the code size, and the likelihood that an issue can be abused by a third-party.
Plugin developers can request the full detailed results for their own plugins through an automated system. They can use the information to fix possible vulnerabilities and to harden their code, thus making the WordPress ecosystem more secure. The idea behind CodeRisk is to empower plugin developers to find problems in their code on their own, even if they are not security savvy. While we do a lot of research regarding WordPress security, and report many vulnerabilities to developers, there are far too many plugins to analyze them all manually.
Are many plugin developers subscribing and using your free source code analysis service? How is the response from the WordPress community?
Currently there are a few dozen plugin developers that use CodeRisk to reduce the risk of security vulnerabilities in their plugins. We have received a lot of good feedback so far and CodeRisk has already helped to resolve hundreds of problems.
Automated scanners tend to report false positives and edge cases that might not be exploitable. Considering many developers are not security savvy, what are you doing to help them and avoid false alarms?
Our users should be aware that we highlight code that poses a security risk. Among unintended security vulnerabilities this also includes other findings, for example weak protections that may become a threat later on.
You do not have to know if and how an issue is exploitable to make sure that it will not become a security threat in the future. For example, if you print the return value of a function make sure to properly encode it to prevent cross-site scripting vulnerabilities. Even if the return value does not contain user input yet, this might not be the case in the future.
Where do you see this free WordPress project going? Do you have plans for it? Maybe offering a premium service to hand hold developers, help them understand the results and making the best of them?
The next release of CodeRisk will add support for WordPress themes since they are an integral part of most blogs, and often times contain vulnerabilities as well. At some point we would like to extend CodeRisk to other content management systems. There are currently no plans for a premium service but if there is enough demand for it this might change.
Can you give WordPress developers two or three secure development best practices to follow so they can write more secure code?
If you want to write more secure code never blindly trust the existing code. Always assume that functions might return user input and treat them as such. For general information on how to write secure PHP code check out The 2018 Guide to Building Secure PHP Software.
Visit the CodeRisk website for more information on the service. And if you are a WordPress plugin developer, and your plugin is on the WordPress plugin repository sign up for a free account to see what vulnerabilities your plugin might have.
The post Interview with CodeRisk – A Free Source Code Analysis Service For WordPress Plugins appeared first on WP White Security.
Source: Security Feed