Recently four of Smackcoders plugins were to found by Rahul Pratap Singh to have reflective cross-site scripting (XSS) vulnerabilities. This type of vulnerability is not something we really see being exploited, probably due in large part due to the fact that all of the major web browsers other than Firefox have filtering that should prevent it from being successful in most cases. But the presence of it does indicate that the developer is not too concerned about security as properly handling user input data is really a basic piece of programming in a secure fashion.

Also of concern was how long it took the developer to respond after the issues were discovered. Here are the timelines given by discoverer of the vulnerabilities for how long it took for the the vulnerabilities to be fixed

WP Ultimate CSV Importer:

• January 14, 2016 – Bug discovered, initial report to Vendor
• January 14, 2016 – Vendor acknowledged and scheduled a fix
• January 18, 2016 – Reported to wordpress
• January 19, 2016 – WordPress Response, plugin taken down
• January 26, 2016 – Vendor Deployed a Patch

WP Advanced Importer Plugin:

• January 30, 2016 – Bug discovered, initial report to WordPress
• February 1, 2016 – WordPress response, plugin taken down
• February 23, 2016 – Vendor Deployed a Patch

WP Ultimate Exporter:

• January 30, 2016 – Bug discovered, initial report to WordPress
• February 1, 2016 – WordPress response, plugin taken down
• February 24, 2016 – Plugin up with same version

Import Woocommerce:

• January 30, 2016 – Bug discovered, initial report to WordPress
• February 1, 2016 – WordPress response, plugin taken down
• February 24, 2016 – Vendor Deployed a Patch

If there were larger issue found you obviously don’t want to have the plugin remaining vulnerable for weeks.

Larger Issues

It turns out that the reflected XSS vulnerabilities was not the end of their issues in properly handling user input. After seeing the report of the issue in WP Ultimate Exporter Henri Salo noticed that the plugin was also vulnerable to SQL injection, due to a failure to use prepared statements. This would be more an issue than the reflected XSS vulnerabilities, but for you average website probably not a major one.

When we reviewed that report we noticed an even larger issue, the export function of the plugin does not do any check to make sure that the request for export is properly authenticated. That means without being logged in anyone can get a copy of the data the plugin can export, which includes custom posts, pages, and posts. In many cases that wouldn’t matter since all the pages and posts on the website are publicly available, but if some are not supposed to be accessible to the general public they would be through this issue.

We contacted the developer last Monday and informed of these two issues. We received an automated reply that they would be getting back to us, “usually within 24 hours”. But by Friday we had not received any response, so we went ahead and notified the people running the Plugin Directory. On Monday the plugin was removed from the directory and so far it has not been fixed.