All closed plugins are required to pass a security and guideline check before they may be reopened, in order to reduce the negative impact on users. This is especially true now that a few 'security firms' have taken it on themselves to zero-day and release all known vulnerabilities for any closed plugin, regardless of cause. We hope that requiring this will protect you from them.
You are required to do the following:
Perform a complete review of your entire plugin to ensure it's properly up to date
Correct all issues listed below
Ensure the 'tested up to' version in your readme is the latest release of WordPress (if you fail to do this, we cannot review nor reopen your plugin as doing so would cause your plugin to become unfindable in our search system)
Increase your plugin version (you only need to do this once - if you've already done so, you do not need to again)
Upload your corrected plugin to SVN (don't worry - even with a new version, no one will get updated until the plugin is reopened)
Reply to this email
If there is any reason you feel your plugin should be reopened in light of these issues, please let us know. There are always reasonable exceptions (like needing time to replace a library, or not being able to use curl or enqueues), and we are absolutely willing to hear them. Our goal is to prevent your reputation and your users from being hurt due to hostile security teams 0-daying you.
While we do not have any official scripts at this time, we do strongly recommend you use PHP Code Sniffer to scan your code, using the WordPress Coding Standards, in order to help determine the overall security and quality of your code.
While many of the issues that tool will list are not ones we would hold your plugin back for, we recommend you take the time to review and learn how to incorporate such a scan in your daily development practices. This will help you write safer, more stable code, and provide a better experience for your users.
Note: No tool can promise or deliver a 100% security check of your code. The information from the scan is provided to assist you in your ongoing education as a developer.
We will re-review your entire plugin again once we receive your email. Please remember that we cannot review an emailed zip. You must use SVN properly for us to proceed. We appreciate your patience and understanding in this process.
Here is your review:
## Unsafe SQL calls
When making database calls, it's highly important to protect your code from SQL injection vulnerabilities. You need to update your code to use wpdb calls and prepare() with your queries to protect them.
## Variables and options must be escaped when echo'd
Much related to sanitizing everything, all variables that are echoed need to be escaped when they're echoed, so it can't hijack users or (worse) admin screens. There are many esc_*() functions you can use to make sure you don't show people the wrong data, as well as some that will allow you to echo HTML safely.
At this time, we ask you escape all $-variables, options, and any sort of generated data when it is being echoed. That means you should not be escaping when you build a variable, but when you output it at the end. We call this 'escaping late.'
Besides protecting yourself from a possible XSS vulnerability, escaping late makes sure that you're keeping the future you safe. While today your code may be only outputted hardcoded content, that may not be true in the future. By taking the time to properly escape when you echo, you prevent a mistake in the future from becoming a critical security issue.
This remains true of options you've saved to the database. Even if you've properly sanitized when you saved, the tools for sanitizing and escaping aren't interchangeable. Sanitizing makes sure it's safe for processing and storing in the database. Escaping makes it safe to output.
Also keep in mind that sometimes a function is echoing when it should really be returning content instead. This is a common mistake when it comes to returning JSON encoded content. Very rarely is that actually something you should be echoing at all. Echoing is because it needs to be on the screen, read by a human. Returning (which is what you would do with an API) can be json encoded, though remember to sanitize when you save to that json object!
There are a number of options to secure all types of content (html, email, etc). Yes, even HTML needs to be properly escaped.
Remember: You must use the most appropriate functions for the context. There is pretty much an option for everything you could echo. Even echoing HTML safely.
## PHP Coding Standards
We strongly recommend you use PHP Code Sniffer to scan your code, using the WordPress Coding Standards, in order to help determine the overall security and quality of your code.
While many of the issues that tool will list are not ones we would hold your plugin back for, we recommend you take the time to review and learn how to incorporate such a scan in your daily development practices. This will help you write safer, more stable code, and provide a better experience for your users.
Note: No tool can promise or deliver a 100% security check of your code. The information from the scan is provided to assist you in your ongoing education as a developer.
linear[bot]
commented
5 months ago
https://wordpress.org/plugins/wp-bannerize-pro/
All closed plugins are required to pass a security and guideline check before they may be reopened, in order to reduce the negative impact on users. This is especially true now that a few 'security firms' have taken it on themselves to zero-day and release all known vulnerabilities for any closed plugin, regardless of cause. We hope that requiring this will protect you from them.
You are required to do the following:
If there is any reason you feel your plugin should be reopened in light of these issues, please let us know. There are always reasonable exceptions (like needing time to replace a library, or not being able to use curl or enqueues), and we are absolutely willing to hear them. Our goal is to prevent your reputation and your users from being hurt due to hostile security teams 0-daying you.
While we do not have any official scripts at this time, we do strongly recommend you use PHP Code Sniffer to scan your code, using the WordPress Coding Standards, in order to help determine the overall security and quality of your code.
While many of the issues that tool will list are not ones we would hold your plugin back for, we recommend you take the time to review and learn how to incorporate such a scan in your daily development practices. This will help you write safer, more stable code, and provide a better experience for your users.
Note: No tool can promise or deliver a 100% security check of your code. The information from the scan is provided to assist you in your ongoing education as a developer.
We will re-review your entire plugin again once we receive your email. Please remember that we cannot review an emailed zip. You must use SVN properly for us to proceed. We appreciate your patience and understanding in this process.
Here is your review:
## Unsafe SQL calls
When making database calls, it's highly important to protect your code from SQL injection vulnerabilities. You need to update your code to use wpdb calls and prepare() with your queries to protect them.
Please review the following:
Example(s) from your plugin: https://plugins.trac.wordpress.org/browser/wp-bannerize-pro/tags/1.6.11/plugin/Models/WPBannerizeClicks.php?marks=173,171,157,189#L155 https://plugins.trac.wordpress.org/browser/wp-bannerize-pro/tags/1.6.11/plugin/MetaBoxes/Summary.php?marks=161,167#L148 https://plugins.trac.wordpress.org/browser/wp-bannerize-pro/tags/1.6.11/plugin/MetaBoxes/Summary.php?marks=191,199#L178 https://plugins.trac.wordpress.org/browser/wp-bannerize-pro/tags/1.6.11/plugin/Models/WPBannerizeCTR.php?marks=114,84,83,112,95,138#L76 https://plugins.trac.wordpress.org/browser/wp-bannerize-pro/tags/1.6.11/plugin/Ajax/WPBannerizeAjax.php?marks=202,201,200,203#L187 https://plugins.trac.wordpress.org/browser/wp-bannerize-pro/tags/1.6.11/plugin/Models/WPBannerizeImpressions.php?marks=71,69,55,87#L32 https://plugins.trac.wordpress.org/browser/wp-bannerize-pro/tags/1.6.11/plugin/Http/Controllers/WPBannerizeImporterController.php?marks=254,252,249,248,247,263#L218
## Variables and options must be escaped when echo'd
Much related to sanitizing everything, all variables that are echoed need to be escaped when they're echoed, so it can't hijack users or (worse) admin screens. There are many esc_*() functions you can use to make sure you don't show people the wrong data, as well as some that will allow you to echo HTML safely.
At this time, we ask you escape all $-variables, options, and any sort of generated data when it is being echoed. That means you should not be escaping when you build a variable, but when you output it at the end. We call this 'escaping late.'
Besides protecting yourself from a possible XSS vulnerability, escaping late makes sure that you're keeping the future you safe. While today your code may be only outputted hardcoded content, that may not be true in the future. By taking the time to properly escape when you echo, you prevent a mistake in the future from becoming a critical security issue.
This remains true of options you've saved to the database. Even if you've properly sanitized when you saved, the tools for sanitizing and escaping aren't interchangeable. Sanitizing makes sure it's safe for processing and storing in the database. Escaping makes it safe to output.
Also keep in mind that sometimes a function is echoing when it should really be returning content instead. This is a common mistake when it comes to returning JSON encoded content. Very rarely is that actually something you should be echoing at all. Echoing is because it needs to be on the screen, read by a human. Returning (which is what you would do with an API) can be json encoded, though remember to sanitize when you save to that json object!
There are a number of options to secure all types of content (html, email, etc). Yes, even HTML needs to be properly escaped.
Remember: You must use the most appropriate functions for the context. There is pretty much an option for everything you could echo. Even echoing HTML safely.
Example(s) from your plugin: https://plugins.trac.wordpress.org/browser/wp-bannerize-pro/trunk/plugin/CustomPostTypes/WPBannerizeCustomPostType.php?marks=530,544,549,656,660,664,737
## PHP Coding Standards We strongly recommend you use PHP Code Sniffer to scan your code, using the WordPress Coding Standards, in order to help determine the overall security and quality of your code.
While many of the issues that tool will list are not ones we would hold your plugin back for, we recommend you take the time to review and learn how to incorporate such a scan in your daily development practices. This will help you write safer, more stable code, and provide a better experience for your users.
Note: No tool can promise or deliver a 100% security check of your code. The information from the scan is provided to assist you in your ongoing education as a developer.
-- WordPress Plugin Review Team | plugins@wordpress.org https://make.wordpress.org/plugins/ https://developer.wordpress.org/plugins/wordpress-org/detailed-plugin-guidelines/