pronamic / pronamic-pay-with-mollie-for-ninja-forms

This WordPress plugin connects your Ninja Forms forms to payment provider Mollie via the Pronamic Pay plugin built by Pronamic.

Home Page:https://wordpress.org/plugins/pronamic-pay-with-mollie-for-ninja-forms/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

[WordPress Plugin Directory] Review in Progress: Pronamic Pay with Mollie for Ninja Forms 🔁 2️⃣

remcotolsma opened this issue · comments

Review 🔁 2️⃣:


Hello,

There are issues with your plugin code preventing it from being approved immediately. We have pended your submission in order to help you correct all issues so that it may be approved and published.

We ask you read this email in its entirety, address all listed issues, and reply to this email with your corrected code attached (or linked). You have three (3) months to make all corrections, before your plugin will be rejected. Even so, as long as you reply to this email, we will be able to continue with your review and eventually publish your code.

Remember in addition to code quality, security and functionality, we require all plugins adhere to our guidelines. If you have not yet, please read them:

https://developer.wordpress.org/plugins/wordpress-org/detailed-plugin-guidelines/

We know it can be long, but you must follow the directions at the end as not doing so will result in your review being delayed. It is required for you to read and reply to these emails, and failure to do so will result in significant delays with your plugin being accepted.

Finally, should you at any time wish to alter your permalink (aka the plugin slug), you must explicitly tell us what you want it to be. Just changing the display name is not sufficient, and we require to you clearly state your desired permalink. Remember, permalinks cannot be altered after approval.

Be aware that you will not be able to submit another plugin while this one is being reviewed.

## Data Must be Sanitized, Escaped, and Validated

When you include POST/GET/REQUEST/FILE calls in your plugin, it's important to sanitize, validate, and escape them. The goal here is to prevent a user from accidentally sending trash data through the system, as well as protecting them from potential security issues.

SANITIZE: Data that is input (either by a user or automatically) must be sanitized as soon as possible. This lessens the possibility of XSS vulnerabilities and MITM attacks where posted data is subverted.

VALIDATE: All data should be validated, no matter what. Even when you sanitize, remember that you don’t want someone putting in ‘dog’ when the only valid values are numbers.

ESCAPE: Data that is output must be escaped properly when it is echo'd, so it can't hijack admin screens. There are many esc_*() functions you can use to make sure you don't show people the wrong data.

To help you with this, WordPress comes with a number of sanitization and escaping functions. You can read about those here:

https://developer.wordpress.org/apis/security/sanitizing/
https://developer.wordpress.org/apis/security/escaping/

Remember: You must use the most appropriate functions for the context. If you’re sanitizing email, use sanitize_email(), if you’re outputting HTML, use wp_kses_post(), and so on.

An easy mantra here is this:

Sanitize early
Escape Late
Always Validate

Clean everything, check everything, escape everything, and never trust the users to always have input sane data. After all, users come from all walks of life.

Example(s) from your plugin:

pronamic-pay-with-mollie-for-ninja-forms/packages/woocommerce/action-scheduler/classes/abstracts/ActionScheduler_Abstract_ListTable.php:720 foreach ( $_GET as $key => $value ) { // phpcs:ignore WordPress.Security.NonceVerification.Recommended
if ( '_' === $key[0] || 'paged' === $key || 'ID' === $key ) {
continue;
}
echo '<input type="hidden" name="' . esc_attr( $key ) . '" value="' . esc_attr( $value ) . '" />';
}
pronamic-pay-with-mollie-for-ninja-forms/packages/woocommerce/action-scheduler/lib/WP_Async_Request.php:154 'cookies'   => $_COOKIE,

## Processing the whole input

We strongly recommend you never attempt to process the whole $_POST/$_REQUEST/$_GET stack. This makes your plugin slower as you're needlessly cycling through data you don't need. Instead, you should only be attempting to process the items within that are required for your plugin to function.

Example(s) from your plugin:

pronamic-pay-with-mollie-for-ninja-forms/packages/woocommerce/action-scheduler/lib/WP_Async_Request.php:154 'cookies'   => $_COOKIE,
pronamic-pay-with-mollie-for-ninja-forms/packages/woocommerce/action-scheduler/classes/abstracts/ActionScheduler_Abstract_ListTable.php:720 foreach ( $_GET as $key => $value ) { // phpcs:ignore WordPress.Security.NonceVerification.Recommended
if ( '_' === $key[0] || 'paged' === $key || 'ID' === $key ) {
continue;
}
echo '<input type="hidden" name="' . esc_attr( $key ) . '" value="' . esc_attr( $value ) . '" />';
}

## 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.

https://developer.wordpress.org/apis/security/escaping/

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:

pronamic-pay-with-mollie-for-ninja-forms/packages/woocommerce/action-scheduler/classes/abstracts/ActionScheduler_Abstract_ListTable.php:727 echo $this->search_box( $this->get_search_box_button_text(), 'plugin' ); // phpcs:ignore WordPress.Security.EscapeOutput.OutputNotEscaped
pronamic-pay-with-mollie-for-ninja-forms/packages/woocommerce/action-scheduler/classes/ActionScheduler_AdminView.php:195 _n(
// translators: 1) is the number of affected actions, 2) is a link to an admin screen.
'<strong>Action Scheduler:</strong> %1$d <a href="%2$s">past-due action</a> found; something may be wrong. <a href="https://actionscheduler.org/faq/#my-site-has-past-due-actions-what-can-i-do" target="_blank">Read documentation &raquo;</a>',
'<strong>Action Scheduler:</strong> %1$d <a href="%2$s">past-due actions</a> found; something may be wrong. <a href="https://actionscheduler.org/faq/#my-site-has-past-due-actions-what-can-i-do" target="_blank">Read documentation &raquo;</a>',
$num_pastdue_actions,
'pronamic-pay-with-mollie-for-ninja-forms'
),
pronamic-pay-with-mollie-for-ninja-forms/packages/wp-pay/core/views/meta-box-payment-info.php:712 echo nl2br( esc_html( (string) $address ) );
pronamic-pay-with-mollie-for-ninja-forms/packages/woocommerce/action-scheduler/classes/abstracts/ActionScheduler_Abstract_ListTable.php:708 echo implode( " | \n", $status_list_items ); // phpcs:ignore WordPress.Security.EscapeOutput.OutputNotEscaped
 -----> echo implode(" | \n", $status_list_items);
pronamic-pay-with-mollie-for-ninja-forms/packages/wp-pay/core/views/meta-box-payment-info.php:693 echo nl2br( esc_html( (string) $address ) );

## Allowing Direct File Access to plugin files

Direct file access is when someone directly queries your file. This can be done by simply entering the complete path to the file in the URL bar of the browser but can also be done by doing a POST request directly to the file. For files that only contain a PHP class the risk of something funky happening when directly accessed is pretty small. For files that contain procedural code, functions and function calls, the chance of security risks is a lot bigger.

You can avoid this by putting this code at the top of all PHP files that could potentially execute code if accessed directly :

        if ( ! defined( 'ABSPATH' ) ) exit; // Exit if accessed directly

Example(s) from your plugin:

pronamic-pay-with-mollie-for-ninja-forms/pronamic-pay-with-mollie-for-ninja-forms.php:32 
pronamic-pay-with-mollie-for-ninja-forms/packages/wp-pay-extensions/ninjaforms/pronamic-pay-ninja-forms.php:30 

Please note that due to the significant backlog the Plugin Review team is facing, we have only done a basic review of your plugin. Once the issues we shared above are fixed, we will do a more in-depth review that might surface other issues. In order to prevent further delays, we strongly urge you to review the guidelines again before you resubmit it.

If the corrections we requested in this initial review are not completed within 3 months (90 days), we will reject this submission in order to keep our queue manageable and you will need to resubmit the plugin from scratch.

Your next steps are:

  1. Make all the corrections related to the issues we listed.
  2. Review your entire code following the guidelines to ensure there are no other related concerns.
  3. Attach your corrected plugin as a zip file OR provide a link to a public location (Dropbox, GitHub, etc) from where we can download the code. A direct link to the zip is best.
    Please do not send it using services where the download expires after a short period of time (such as WeTransfer-Free).
    Once we receive your updated code, we will re-review it from top down.

Be aware that if your zip contains JavaScript files, you may not be able to email it as many hosts block that in the interests of security. Keep in mind, all version control directories (like GitHub) will auto-generate a zip for you, so you do not need to upload a zip file to their systems. You can just link to the repository.

We again remind you that should you wish to alter your permalink (not the display name, the plugin slug), you must explicitly tell us what you want it to be. We require to you clearly state in the body of your email what your desired permalink is. Permalinks cannot be altered after approval, and we generally do not accept requests to rename should you fail to inform us during the review.

If you previously asked for a permalink change and got a reply that is has been processed, you’re all good! While these emails will still use the original display name, you don’t need to panic. If you did not get a reply that we processed the permalink, let us know immediately. While we have tried to make this review as exhaustive as possible we, like you, are humans and may have missed things. As such, we will re-review the entire plugin when you send it back to us. We appreciate your patience and understanding.

If you have questions, concerns, or need clarification, please reply to this email and just ask us.

--
WordPress Plugin Review Team | plugins@wordpress.org
https://make.wordpress.org/plugins/
https://developer.wordpress.org/plugins/wordpress-org/detailed-plugin-guidelines/

I have informed the "Action Scheduler" developers about the issues/warnings in:

Hello WordPress Plugin Review Team,

A number of issues again appear to originate from the "Action Scheduler" plugin/library. We have also reported this to the developers of this plugin: woocommerce/action-scheduler#1027. We have also previously worked to resolve an issue: woocommerce/action-scheduler#1011. Luke Carbis from your team had already left a comment on this issue. Is it possible that we ignore the "Action Scheduler" issues for a moment to speed up this review? If these issues are viewed manually, it can be concluded that they are not real problems. Additionally, these issues are also present in https://wordpress.org/plugins/woocommerce/, https://wordpress.org/plugins/action-scheduler/ and possibly many other plugins. We have resolved the warnings found in our own codebase:

## Variables and options must be escaped when echo'd

pronamic-pay-with-mollie-for-ninja-forms/packages/wp-pay/core/views/meta-box-payment-info.php:712 echo nl2br( esc_html( (string) $address ) );
pronamic-pay-with-mollie-for-ninja-forms/packages/wp-pay/core/views/meta-box-payment-info.php:693 echo nl2br( esc_html( (string) $address ) );

## Allowing Direct File Access to plugin files

pronamic-pay-with-mollie-for-ninja-forms/pronamic-pay-with-mollie-for-ninja-forms.php:32
pronamic-pay-with-mollie-for-ninja-forms/packages/wp-pay-extensions/ninjaforms/pronamic-pay-ninja-forms.php:30 

New version of the plugin is available via: https://github.com/pronamic/pronamic-pay-with-mollie-for-ninja-forms/releases/tag/v1.0.0-rc.3.

We hope this is enough to get the green light to add this plugin. Thanks again.

PS can the checks you carry out also be carried out by us? Is it correct that many of your checks are not yet in https://wordpress.org/plugins/plugin-check/?

Remco Tolsma
Pronamic