Support » Plugin: Fast Velocity Minify » Security problem!

  • Resolved cloudshift

    (@cloudshift)


    Hey,

    thanks for your great plugin but there might be a major security problem. In our website we use some js files as php files (.js.php). The reason is we’re using JS modules to easier maintain the site. in the main myfile.js.php file all js snippets are incuded via ‘require_once’. I we load the main file myfile.js.php it shows the whole js. Of course we’re also using the right http headers for js in php.

    If we activate your plugin it includes the js.php without parsing the php first. So all php parts are also visible. We also use php variables so this a major security thread. Is it possible to fix that?

    Thanks in advance!

    cheers, Julian

    The page I need help with: [log in to see the link]

Viewing 5 replies - 1 through 5 (of 5 total)
  • Plugin Author Raul P.

    (@alignak)

    Hi there,

    I’m sorry to let you know, but if you are creating the PHP file, you are the one creating the security issue. FVM is simply reading the files you have decided to enqueue “as” a js file.

    FVM will trust the developers of other plugins and theme modifications as long as they follow the standard hooks api method of enqueueing the files… so it’s your responsibility not to trick the system into serving a PHP file, when the system expects it to be a text file only.

    You must assume that any plugin will be able to read your js, css or html code directly (and not only plugins, but also malware exploits)… so you should never use php to generate js or css code and enqueue it.

    This is true, not only because of security but also performance. Generating code that is supposed to be static (js, css) on every page load is wrong, not good practice.

    If you must use that PHP file, you could run a cronjob calling that PHP file every few minutes (or call it manually once, when needed) and have it writing the generated output to a cache js file somewhere writable.

    You could then have a timestamp on the database, tracking the last time you updated something on that generated code. You would then compare it with the filemtime info for the cached js file, before rewriting it again (if newer).

    You would then enqueue that js file only, not the php file, and you should have now done it the proper way.

    Another alternative, would be to simply inline the code directly onto the html, by printing it inlined on the footer, instead of an external file.

    FVM only detects the files that are enqueued using the wordpress hooks method and it expects it to not be PHP.

    Therefore, it first tries to opens the js/css files directly because that is the fastest way to do it. If that fails, it will fallback to http… but as long as it can read the file, it will merge it.

    If you cannot do any changes to your PHP script, then your other option is to exclude it via the ignore list to exclude it (use a partial file path and it will exclude any matching pattern).
    https://wordpress.org/plugins/fast-velocity-minify/faq/

    cloudshift

    (@cloudshift)

    Thanks for the quick answer! You are correct. It’s bad practise but very helpfull if you use large script (or CSS) ;-).

    Using my file.js.php with the WP ‘wp_enqueue_script’ function works perfect so I thought it will work with FVM too. I understand that you access files directly and not over HTTP.

    Do you see tha chance to enhance FVM to access ‘js.php’ and maybe ‘ccc.php’ files which are enqued via http? Or give developers the chance to have a separate list for files that must be accessed via http. Then FVM can be the only cache and such a function would be very helpfull.

    Regardless of whether it is possible or not, I just donated something for you (Convecto). Thanks for your great work! Your plugin in by far the best in its field and we use it on every website we build!

    cloudshift

    (@cloudshift)

    css.php not ccc.php

    Plugin Author Raul P.

    (@alignak)

    @cloudshift I appreciate the donation and I pushed 2.7.4 which should now fallback to HTTP merging if it detects PHP code <?php inside JS or CSS files.

    Give it a try and let me know if it works for you.

    Thanks again

    cloudshift

    (@cloudshift)

    Hey Raul,

    you’re crazy :-). So fast!!??? Thank you so much!

    It works perfect! Now we can manage js better and still have all the advantages of your cache. Great work!

Viewing 5 replies - 1 through 5 (of 5 total)
  • You must be logged in to reply to this topic.