For our sixteenth security review of a WordPress plugin based on the voting of our customers, we reviewed the plugin Amazon Web Services.

If you are not yet a customer of the service you can currently sign up for the service for half off and then start suggesting and voting on plugins to get security reviews. For those already using the service that haven’t already suggested and voted for plugins to receive a review, you can start doing that here. You can use our new tool for doing limited automated security checks of plugins to see if plugins you are using have possible issues that would make them good candidates to get a review. You can also order a review of a plugin separately from our service.

The review was done on version 1.0.4 of Amazon Web Services. We checked for the following issues during this review:

• 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
• Security issues with functions accessible through any of the plugin’s shortcodes
• Security issues with functions accessible through the admin_action action
• Security issues with functions accessible through the admin_init action
• Security issues with import/export functionality
• Security issues with usage of is_admin()
• Host header injection vulnerabilities
• Lack of protection against unintended direct access of PHP files
• Insecure and unwarranted requests to third-party websites

Results

During the review we only found one minor issue:

Lack of Protection Against Direct Access to Files

Numerous .php files that look like they are not intended to be accessed directly are lacking code at the beginning of the file to restrict direct access to the files. Most of the files only define classes, so there is nothing exploitable if they are accessed and adding a restriction has limited value. Other files though generate parts of admin pages and code will run when those are accessed. While in this case there was nothing that looks like a security issue due to that, in recent times we have added new vulnerabilities to our date set that were caused by files of that type where limiting access would have lessened the risk of the vulnerabilities.