4 ms·

This I don't understand. Why run WP where the server has ownership and write access to the code? With the frequency that WP sites get attacked, leaving a system

This I don't understand. Why run WP where the server has ownership and write access to the code? With the frequency that WP sites get attacked, leaving a system in place where an attacker that gets access and can write files that will be executed is just asking for problems. If you want an auto-update, why not do this with an automatic CI/CD type pipeline that's triggered on new WP versions?

CJefferson 10y ago
But in this case, an auto-updating install would be protected, while a non-updated version would now have the website over-written...
- lsaferite 10y ago
  My point is, a publicly facing web application should not have permissions to update it's own code. The possibility of the application being compromised and then having the application modified to support further system compromise it too great.
  - bigmanwalter 10y ago
    Well, that's how WP works so we're stuck with it. On the plus side, it makes for a great plugin experience for non-technical users.
    - lsaferite 10y ago
      Having done WP installs where the only web-user writable area was for uploads (and that is configured to not execute anything), I will have to dispute your assertion. The fact that the vast majority of WP sites are web-user writable is just inertia and/or bad security practices. You can disable the file write features of WP and remove the online application upgrade feature. This leaves you using your code repo and build system as the proper path to upgrading the code. This allows you to vet any code change to your site, which you should be doing anyway.
      - tyingq 10y ago
        Yes, you can do that, but you're fighting the way it is designed. You mentioned the uploads directory, but there are very common plugins that need write access to other files. Almost every caching plugin for wordpress, as one example. You also have to replicate the functionality to do upgrades for plugins, themes, and core WP, including ones that need database upgrades. It's just a risk management decision. In my case, all the hoops to make the filesystem read-only aren't worth it. Retaining the built-in upgrade functionality is of higher value. We have offsite backups and file integrity scanning, and will fall back if needed. If the sites were, say, e-commerce sites, I would have made a different decision.
        lsaferite 10y ago
        Upgrades can be a single "composer update" and then committing the composer.lock file. Mine are a bit more as I review changes between versions as well. I am very careful about what plugins I use for this very reason honestly. If it's not well-behaved enough and requires the ability to write outside of uploads then it's not used.
tyingq 10y ago
>With the frequency that WP sites get attacked, leaving a system in place where an attacker that gets access and can write files that will be executed is just asking for problems. I do see your point, but wordpress just isn't designed to work that way. And, if you did go through all the hoops to make wordpress okay without write access to files, it still has write access to the database. I do have other mitigations in place, and feel like the risk profile is fine for what these sites do (informational only). I'd be happier if the auto update was working as it should though.
pbowyer 10y ago
> If you want an auto-update, why not do this with an automatic CI/CD type pipeline that's triggered on new WP versions? One reason is because WP updates often need database upgrades too. I've been updating using `wp-cli` which can be run via cron -- but I've yet to sort what to do when WP/a plugin needs the 'Upgrade database tables' button clicked. A CI/CD pipeline would be nice, especially with a verification stage that confirmed the website hadn't changed post-update (yesterday, updating a plugin lost data. Sore point)

CJefferson 10y ago

But in this case, an auto-updating install would be protected, while a non-updated version would now have the website over-written...

lsaferite 10y ago
My point is, a publicly facing web application should not have permissions to update it's own code. The possibility of the application being compromised and then having the application modified to support further system compromise it too great.
- bigmanwalter 10y ago
  Well, that's how WP works so we're stuck with it. On the plus side, it makes for a great plugin experience for non-technical users.
  - lsaferite 10y ago
    Having done WP installs where the only web-user writable area was for uploads (and that is configured to not execute anything), I will have to dispute your assertion. The fact that the vast majority of WP sites are web-user writable is just inertia and/or bad security practices. You can disable the file write features of WP and remove the online application upgrade feature. This leaves you using your code repo and build system as the proper path to upgrading the code. This allows you to vet any code change to your site, which you should be doing anyway.
    - tyingq 10y ago
      Yes, you can do that, but you're fighting the way it is designed. You mentioned the uploads directory, but there are very common plugins that need write access to other files. Almost every caching plugin for wordpress, as one example. You also have to replicate the functionality to do upgrades for plugins, themes, and core WP, including ones that need database upgrades. It's just a risk management decision. In my case, all the hoops to make the filesystem read-only aren't worth it. Retaining the built-in upgrade functionality is of higher value. We have offsite backups and file integrity scanning, and will fall back if needed. If the sites were, say, e-commerce sites, I would have made a different decision.
      - lsaferite 10y ago
        Upgrades can be a single "composer update" and then committing the composer.lock file. Mine are a bit more as I review changes between versions as well. I am very careful about what plugins I use for this very reason honestly. If it's not well-behaved enough and requires the ability to write outside of uploads then it's not used.

tyingq 10y ago

>With the frequency that WP sites get attacked, leaving a system in place where an attacker that gets access and can write files that will be executed is just asking for problems. I do see your point, but wordpress just isn't designed to work that way. And, if you did go through all the hoops to make wordpress okay without write access to files, it still has write access to the database. I do have other mitigations in place, and feel like the risk profile is fine for what these sites do (informational only). I'd be happier if the auto update was working as it should though.

pbowyer 10y ago

> If you want an auto-update, why not do this with an automatic CI/CD type pipeline that's triggered on new WP versions? One reason is because WP updates often need database upgrades too. I've been updating using `wp-cli` which can be run via cron -- but I've yet to sort what to do when WP/a plugin needs the 'Upgrade database tables' button clicked. A CI/CD pipeline would be nice, especially with a verification stage that confirmed the website hadn't changed post-update (yesterday, updating a plugin lost data. Sore point)