8 ms·

This is not the first time that WP Fastest Cache has had a SQL injection vulnerability discovered. Here’s a report on 0.8.4.8: https://www.acunetix.com/vulner

by hluska 5y ago

This is not the first time that WP Fastest Cache has had a SQL injection vulnerability discovered. Here’s a report on 0.8.4.8: https://www.acunetix.com/vulnerabilities/web/wordpress-plugin-wp-fastest-cache-sql-injection-0-8-4-8/ https://www.acunetix.com/vulnerabilities/web/wordpress-plugi... Here’s a report on 0.8.7.4: https://www.acunetix.com/vulnerabilities/web/wordpress-plugin-wp-fastest-cache-sql-injection-0-8-7-4/ https://www.acunetix.com/vulnerabilities/web/wordpress-plugi... I could go on (all night) but I trust you all get the point. I have two questions. First, at what point can we say “Emre, you’re really bad at writing code. There are lots of other jobs. Find another.” Second and more importantly for the future of the web, how can we as an industry protect innocent users from projects like this?? This monstrosity has over 1 million active installs and the chuckle head doesn’t have a fucking clue how to write SQL.

loyukfai 5y ago
Any similar caching plugin would you recommend instead?
- spurgu 5y ago
  Personally I always go with Cache Enabler (by KeyCDN) with nginx. Simple and rock solid. Creates static HTML. For optimum performance (bypassing PHP altogether) configure nginx to try_files (or equivalent in Apache) in the wp-content/cache directory. Edit: I've also used WP Super Cache and W3 Total Cache quite extensively, both both of these have on some sites had a tendency to randomly clear the cache and I've never managed to figure out why. Cache Enabler has never done this.
- BarryMilo 5y ago
  I don't understand why people are trusting random WP contrib developers with cache anyhow? Is nginx no longer a thing?
  - judge2020 5y ago
    Configurablity and ease of use. Many people run Wordpress on cheap, shared hosting and would only have the option of a cache plugin. A lot of WP admins likewise have no command-line experience and couldn’t install nginx without resorting to Google.
  - innocenat 5y ago
    Caching plugin for wordpress still has benefit that nginx cannot provide like providing object caching, etc.
  - chillfox 5y ago
    Because a lot of people who run successful WordPress sites have zero systems admin or developer skills at all. They are usually good writers instead.
  - spurgu 5y ago
    WP admins don't have much control (granularity) over the nginx cache. The options I've seen simply have a single "Purge" button.
- dazc 5y ago
  https://www.cloudflare.com/en-gb/automatic-platform-optimization/wordpress/ https://www.cloudflare.com/en-gb/automatic-platform-optimiza... The closest thing you'll get to serverless wordpress in one click. There is no wordpress caching plug-in I am aware of that will get you anywhere near.
- dpacmittal 5y ago
  WP Rocket is pretty nice but it's a paid plugin
  - johnxie 5y ago
    Can vouch for WP Rocket. We've tried multiple plugins for our blog[1] and it is by far the most reliable. 1: https://www.taskade.com/blog https://www.taskade.com/blog
- fogihujy 5y ago
  W3 Total Cache if you're on shared hosting.
- hannob 5y ago
  My first recommendation would be to question whether you even need a caching plugin. I'd recommend a benchmark. PHP today is much faster than it used to be, and in many cases caching plugins have been written with old, slow PHP in mind. Pro tip: If you have trouble measuring the effect of your caching plugin, it probably means its effect is neglegible. If you really feel you need a caching plugin, WP Super Cache is written by the company that also writes Wordpress. I'd consider that the most trustworthy.
  - spurgu 5y ago
    > My first recommendation would be to question whether you even need a caching plugin. My first question to you would be "Why wouldn't you bypass PHP and MySQL if you can?". For some really basic site sure, you can go without caching, but for any reasonable degree of complexity not using caching is a foolish waste of hardware and end-user patience since we can be talking TTFB of 100-200 ms vs up to seconds.
  - fogihujy 5y ago
    Yeah, if you're on cheap shared hosting (which many, many WordPress sites are), then you're going to hit various limits and have your site disabled the day Ahrefs and Majestic 12 both decide to crawl your site the same day. A properly set up caching plugin basically saves the pages as plain HTML and serve them with mod_rewrite instead of invoking PHP every time. The speed difference for an individual page load might not be that much for a properly optimized site, but the overall resource usage will be much lower.
    - hannob 5y ago
      > The speed difference for an individual page load might not be that much for a properly optimized site, but the overall resource usage will be much lower. Is that what you believe or do you have benchmark results?
      - fogihujy 5y ago
        I work helping people set up things like caching. On the three sites I looked at today, caching plugins had an immediate and positive effect. That serving static files use less resources than firing up PHP should hardly be surprising. Sure, mod_lsapi and FastCGI are fast, and opcache is a godsend, but static files are still going to be faster than doing multiple MySQL queries, triggering plugins, rendering the HTML, doing whatever post-processing the plugins do, and then serving the result.
- prox 5y ago
  Hummingbird
- linedash 5y ago
  wp-supercache - it's been taken over by automaticc themselves these days, which is an added bonus.
Deukhoofd 5y ago
I was mostly shocked by the following sentence: > The authors were initially reluctant to acknowledge the CSRF issue, but after obtaining a second opinion from the WordPress plugin team, they fixed it in version 0.9.5. In what world do you get notified there's a possibility for SQL injection in your code, and then not immediately fix it? This statement shows such arrogance, and little regard for the security of users.
- hluska 5y ago
  Yeah…the poor researcher had to make a video to show off the CSRF attack. First off, that researcher really should never pay for another beverage again. Second, the arrogance, holy shit the arrogance. Dude here managed to consistently write SQLi vulnerabilities over multiple releases - he’s really not in the place to argue.
- Doctor_Fegg 5y ago
  Not defending this at all, but "CSRF issue" != SQL injection.
CJefferson 5y ago
No, Emre gets to do what they like. The fundamental problem here is people and companies have got used to the idea they can get huge amounts of software for free, and expect it to be high quality and well maintained.
- hluska 5y ago
  If Fastest Cache was only a free plugin, I’d give the dude a bit of credit. But it’s not free - his commercial versions are dramatically overpriced considering that he seems to write a new SQLi every odd numbered release. This is overpriced, garbage software and dude can go fuck himself. At this point, I’d happily call this level of negligence criminal.
  - CR007 5y ago
    > At this point, I’d happily call this level of negligence criminal. I'm missing WordPress responsability here. The amount of crap listed in the plugin store without any standar needs to be stopped.
    - zelon88 5y ago
      This isn't a smartphone. It is a server that other people (that you specifically get to target) have to use. It is your responsibility to verify your supply chain. If you can't do that, maybe you shouldn't operate a website that collects user information. At least before cloud you would have to set up bare metal services which gave people an idea of what they were actually assembling. The fancy control panels and one click installs have created a group of overly entitled administrators who can't admin and won't take any responsibility for running shit, misconfigured, off the shelf services from companies they didn't even vet.
      - CR007 5y ago
        You are missing the point. This is a freemium plugin listed in the WordPress plugin directory. They (WordPress) are being negligent by exposing users to that kind of code without any warning, enabling users to install this directly from they WP Admin area. One should expect at least a red flag, but as always they just care about numbers.
antihero 5y ago
Why on earth are people using string concatenation? Surely $wpdb->get_results should be deprecated in favour of something that accepts parameterised queries? Why in the hell are people still injecting strings into queries? In 2021??!
- fabian2k 5y ago
  There is no excuse to concatenate the id into the query string, but the first parameter, the table prefix is not something you can do with parametrized queries. There are probably better ways to abstract this, but in the end if you need to dynamically determine the tables or columns you have to concatenate that stuff into your SQL query string.
- claudiulodro 5y ago
  You're supposed to build the string with $wpdb::prepare[1] before running it through get_results. This will prevent SQLi. It's been available and recommended for like a decade, and any WP code linter will yell at you if you're just building queries out of random concatenated strings. [1] https://developer.wordpress.org/reference/classes/wpdb/prepare/ https://developer.wordpress.org/reference/classes/wpdb/prepa...
Faelian2 5y ago
I see a lot of people angry because how trivial the injection is supposed to be. But static::id is set with the following line : static::$id = esc_sql($_GET["post"]); And yeah, esc_sql() don't work in all cases (see here : https://developer.wordpress.org/reference/functions/esc_sql/#more-information https://developer.wordpress.org/reference/functions/esc_sql/...) and in this case it's vulnerable. But the author did try to prevent SQL injections, and misuse of functions happens sometime ¯\_(ツ)_/¯. It's not that trivial when reading the code. A Stored XSS Via CSRF is also far from trivial. In conclusion, we all write bugs. Some are tricky. Don't be so angry !

by hluska 5y ago

loyukfai 5y ago

Any similar caching plugin would you recommend instead?

spurgu 5y ago
Personally I always go with Cache Enabler (by KeyCDN) with nginx. Simple and rock solid. Creates static HTML. For optimum performance (bypassing PHP altogether) configure nginx to try_files (or equivalent in Apache) in the wp-content/cache directory. Edit: I've also used WP Super Cache and W3 Total Cache quite extensively, both both of these have on some sites had a tendency to randomly clear the cache and I've never managed to figure out why. Cache Enabler has never done this.
BarryMilo 5y ago
I don't understand why people are trusting random WP contrib developers with cache anyhow? Is nginx no longer a thing?
- judge2020 5y ago
  Configurablity and ease of use. Many people run Wordpress on cheap, shared hosting and would only have the option of a cache plugin. A lot of WP admins likewise have no command-line experience and couldn’t install nginx without resorting to Google.
- innocenat 5y ago
  Caching plugin for wordpress still has benefit that nginx cannot provide like providing object caching, etc.
- chillfox 5y ago
  Because a lot of people who run successful WordPress sites have zero systems admin or developer skills at all. They are usually good writers instead.
- spurgu 5y ago
  WP admins don't have much control (granularity) over the nginx cache. The options I've seen simply have a single "Purge" button.
dazc 5y ago
https://www.cloudflare.com/en-gb/automatic-platform-optimization/wordpress/ https://www.cloudflare.com/en-gb/automatic-platform-optimiza... The closest thing you'll get to serverless wordpress in one click. There is no wordpress caching plug-in I am aware of that will get you anywhere near.
dpacmittal 5y ago
WP Rocket is pretty nice but it's a paid plugin
- johnxie 5y ago
  Can vouch for WP Rocket. We've tried multiple plugins for our blog[1] and it is by far the most reliable. 1: https://www.taskade.com/blog https://www.taskade.com/blog
fogihujy 5y ago
W3 Total Cache if you're on shared hosting.
hannob 5y ago
My first recommendation would be to question whether you even need a caching plugin. I'd recommend a benchmark. PHP today is much faster than it used to be, and in many cases caching plugins have been written with old, slow PHP in mind. Pro tip: If you have trouble measuring the effect of your caching plugin, it probably means its effect is neglegible. If you really feel you need a caching plugin, WP Super Cache is written by the company that also writes Wordpress. I'd consider that the most trustworthy.
- spurgu 5y ago
  > My first recommendation would be to question whether you even need a caching plugin. My first question to you would be "Why wouldn't you bypass PHP and MySQL if you can?". For some really basic site sure, you can go without caching, but for any reasonable degree of complexity not using caching is a foolish waste of hardware and end-user patience since we can be talking TTFB of 100-200 ms vs up to seconds.
- fogihujy 5y ago
  Yeah, if you're on cheap shared hosting (which many, many WordPress sites are), then you're going to hit various limits and have your site disabled the day Ahrefs and Majestic 12 both decide to crawl your site the same day. A properly set up caching plugin basically saves the pages as plain HTML and serve them with mod_rewrite instead of invoking PHP every time. The speed difference for an individual page load might not be that much for a properly optimized site, but the overall resource usage will be much lower.
  - hannob 5y ago
    > The speed difference for an individual page load might not be that much for a properly optimized site, but the overall resource usage will be much lower. Is that what you believe or do you have benchmark results?
    - fogihujy 5y ago
      I work helping people set up things like caching. On the three sites I looked at today, caching plugins had an immediate and positive effect. That serving static files use less resources than firing up PHP should hardly be surprising. Sure, mod_lsapi and FastCGI are fast, and opcache is a godsend, but static files are still going to be faster than doing multiple MySQL queries, triggering plugins, rendering the HTML, doing whatever post-processing the plugins do, and then serving the result.
prox 5y ago
Hummingbird
linedash 5y ago
wp-supercache - it's been taken over by automaticc themselves these days, which is an added bonus.

Deukhoofd 5y ago

I was mostly shocked by the following sentence: > The authors were initially reluctant to acknowledge the CSRF issue, but after obtaining a second opinion from the WordPress plugin team, they fixed it in version 0.9.5. In what world do you get notified there's a possibility for SQL injection in your code, and then not immediately fix it? This statement shows such arrogance, and little regard for the security of users.

hluska 5y ago
Yeah…the poor researcher had to make a video to show off the CSRF attack. First off, that researcher really should never pay for another beverage again. Second, the arrogance, holy shit the arrogance. Dude here managed to consistently write SQLi vulnerabilities over multiple releases - he’s really not in the place to argue.
Doctor_Fegg 5y ago
Not defending this at all, but "CSRF issue" != SQL injection.

CJefferson 5y ago

No, Emre gets to do what they like. The fundamental problem here is people and companies have got used to the idea they can get huge amounts of software for free, and expect it to be high quality and well maintained.

hluska 5y ago
If Fastest Cache was only a free plugin, I’d give the dude a bit of credit. But it’s not free - his commercial versions are dramatically overpriced considering that he seems to write a new SQLi every odd numbered release. This is overpriced, garbage software and dude can go fuck himself. At this point, I’d happily call this level of negligence criminal.
- CR007 5y ago
  > At this point, I’d happily call this level of negligence criminal. I'm missing WordPress responsability here. The amount of crap listed in the plugin store without any standar needs to be stopped.
  - zelon88 5y ago
    This isn't a smartphone. It is a server that other people (that you specifically get to target) have to use. It is your responsibility to verify your supply chain. If you can't do that, maybe you shouldn't operate a website that collects user information. At least before cloud you would have to set up bare metal services which gave people an idea of what they were actually assembling. The fancy control panels and one click installs have created a group of overly entitled administrators who can't admin and won't take any responsibility for running shit, misconfigured, off the shelf services from companies they didn't even vet.
    - CR007 5y ago
      You are missing the point. This is a freemium plugin listed in the WordPress plugin directory. They (WordPress) are being negligent by exposing users to that kind of code without any warning, enabling users to install this directly from they WP Admin area. One should expect at least a red flag, but as always they just care about numbers.

antihero 5y ago

Why on earth are people using string concatenation? Surely $wpdb->get_results should be deprecated in favour of something that accepts parameterised queries? Why in the hell are people still injecting strings into queries? In 2021??!

fabian2k 5y ago
There is no excuse to concatenate the id into the query string, but the first parameter, the table prefix is not something you can do with parametrized queries. There are probably better ways to abstract this, but in the end if you need to dynamically determine the tables or columns you have to concatenate that stuff into your SQL query string.
claudiulodro 5y ago
You're supposed to build the string with $wpdb::prepare[1] before running it through get_results. This will prevent SQLi. It's been available and recommended for like a decade, and any WP code linter will yell at you if you're just building queries out of random concatenated strings. [1] https://developer.wordpress.org/reference/classes/wpdb/prepare/ https://developer.wordpress.org/reference/classes/wpdb/prepa...

Faelian2 5y ago

I see a lot of people angry because how trivial the injection is supposed to be. But static::id is set with the following line : static::$id = esc_sql($_GET["post"]); And yeah, esc_sql() don't work in all cases (see here : https://developer.wordpress.org/reference/functions/esc_sql/#more-information https://developer.wordpress.org/reference/functions/esc_sql/...) and in this case it's vulnerable. But the author did try to prevent SQL injections, and misuse of functions happens sometime ¯\_(ツ)_/¯. It's not that trivial when reading the code. A Stored XSS Via CSRF is also far from trivial. In conclusion, we all write bugs. Some are tricky. Don't be so angry !