For our eighth security review of a plugin based on the voting of our customers, we reviewed the plugin Contact Form by BestWebSoft.

If you are not yet a customer of the service you can currently try it free for your first month and then start suggesting and voting on plugins to get security reviews after your first payment for the service. For those already using the service that haven’t already suggested and voted for plugins you can start doing that here.

The review was done on version 4.0.5 of Contact Form by BestWebSoft. We checked for the following issues:

• Insecure file upload handling (this is the cause of the most exploited type of vulnerability, arbitrary file upload)
• Deserialization of untrusted data
• Security issues with functions accessible through WordPress’ AJAX functionality (those are a common source of disclosed vulnerabilities these days)
• Persistent cross-site scripting (XSS) vulnerabilities in publicly accessible portions of the plugin
• Cross-site request forgery (CSRF) vulnerabilities in the admin portion of plugins
• SQL injection vulnerabilities (the code that handles requests to the database)
• Reflected cross-site scripting (XSS) vulnerabilities
• Lack of protection against unintended direct access of PHP files

Results

We found three issues during our review and notified the developers of our finding a month ago. The most serious issue we found, a reflected cross-site scripting (XSS) vulnerability, was fixed in version 4.0.6 of the plugin. There has been no change made to plugin to deal with the other two so far.

Reflected Cross-Site Scripting (XSS) Vulnerability

As we previously disclosed, we found that in the file /bws_menu/bws_menu.php the value of GET input “category” was echo’d without any sanitized or escaped, leading to reflective cross-site scripting (XSS) vulnerability. We also found that the same vulnerability was at the time in 40 other plugins by the developer.

Possible Deserialization of Untrusted Data

In several locations in the plugin requests are made to URLs on the developer’s website using the function wp_remote_post() over HTTP. That opens up the possibility of a man in the middle attack. While that isn’t a big concern, the result of those requests in some instances is run through the function maybe_unserialize(), so there is the possibility of PHP object injection if that were exploited. Seeing as the website is accessible over HTTPS, it looks like they could make these request more securely quite easily. This occurs in the files /bws_menu/bws_menu.php, /bws_menu/class-bws-settings.php, and /bws_menu/deprecated.php.

Lack of Protection Against Direct Access to Files

The plugin’s .php files lack code at the beginning of the files to restrict direct access to them.  We didn’t see anything that could be exploited in the files without the restriction in place.