ka215 / wp-ignitor Goto Github PK

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/plugins/security/securing-input/
https://developer.wordpress.org/plugins/security/securing-output/

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 esc_html(), 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:

wp-ignitor-1.0.0-beta.2/src/admin.php:98: $_page = (string)filter_var( $_REQUEST['page'] ?? '', FILTER_SANITIZE_STRING, FILTER_FLAG_STRIP_LOW | FILTER_FLAG_STRIP_BACKTICK | FILTER_FLAG_STRIP_HIGH );
wp-ignitor-1.0.0-beta.2/src/admin.php:488: 'current_tab' => (string)filter_var( $_REQUEST['tab'] ?? 'globals', FILTER_SANITIZE_STRING, FILTER_FLAG_STRIP_LOW | FILTER_FLAG_STRIP_BACKTICK | FILTER_FLAG_STRIP_HIGH ),

We ask you use the sanitize functions from WordPress rather than filter_var, as the former is built for use with WordPress specifically and can account for it's usecases.

WordPress comes with an extensive HTTP API that should be used instead of creating your own curl calls. It’s both faster and more extensive. It’ll fall back to curl if it has to, but it’ll use a lot of WordPress’ native functionality first.

https://developer.wordpress.org/plugins/http-api/

Please note: If you're using CURL in 3rd party vendor libraries, that's permitted. It's in your own code unique to this plugin (or any dedicated WordPress libraries) that we need it corrected.

Example(s) from your plugin:

wp-ignitor-1.0.0-beta.2/src/utils.php:198: $raw_html = curl_exec( $ch );

This is not actually going to work:

        $raw_html = wp_remote_retrieve_body( wp_remote_request( $get_uri ) );
        if ( ! $raw_html ) {
            if ( preg_match( '@^https://@', $get_uri ) == 1 ) {
                $options = stream_context_create([
                    'ssl' => [
                        'verify_peer' => false,
                        'verify_peer_name' => false,
                    ]
                ]);
                $raw_html = file_get_contents( $get_uri, false, $options );
            } else {
                $raw_html = file_get_contents( $get_uri, false );
            }

Many hosts block the use of file_get_contents on remote content. This is a security measure that we fully endorse.

The HTTP API you already included is far more reliable. You should remove those fallbacks.

Including wp-config.php, wp-blog-header.php, wp-load.php directly via an include is not permitted.

These calls are prone to failure as not all WordPress installs have the exact same file structure. In addition it opens your plugin to security issues, as WordPress can be easily tricked into running code in an unauthenticated manner.

Your code should always exist in functions and be called by action hooks. This is true even if you need code to exist outside of WordPress. Code should only be accessible to people who are logged in and authorized, if it needs that kind of access. Your plugin's pages should be called via the dashboard like all the other settings panels, and in that way, they'll always have access to WordPress functions.

https://developer.wordpress.org/plugins/hooks/

If you need to have a ‘page’ accessed directly by an external service, you should use query_vars and/or rewrite rules to create a virtual page which calls a function.

https://developer.wordpress.org/reference/hooks/query_vars/
https://codepen.io/the_ruther4d/post/custom-query-string-vars-in-wordpress

If you're trying to use AJAX, please read this:

https://developer.wordpress.org/plugins/javascript/ajax/

Example(s) from your plugin:

wp-ignitor-1.0.0-beta.2/views/entrance.php:24: require_once $core_files['wp-load.php'];