5 ms·

Can this solve the Wordpress security nightmare ? are we going to see hosting services built on PeachPie in the near future ?

by petra 8y ago

frankzander 8y ago
This can only be solved by a rewrite.
mgkimsal 8y ago
The bulk of WP security issues stem from the 'writable file system' defaults that many plugins (and, to some extent) core either expect or encourage. I can't say all, but the huge bulk of security issues I've seen revolve around some exploit which ends up writing a new file, or overwriting an existing file, which is then publicly accessible. If your file system is not writable, the large majority of WP exploits go away. However, you lose the "press here to upgrade your entire site and all the plugins in one easy step!" functionality, and the "upload files via the browser" ease-of-use. If you're truly modifying public media files on regular basis, a non-writeable file system kinda stinks (either make the FS writeable or use an external media host, which adds complexity and cost). MOST systems I run in to aren't doing this often - it's "put up the site and updates some pages every few months" (or, blogging, which is often just text). For these, I recommend turning off write permissions to the whole of the WP system, and periodically turning it back on to do updates, then turning it off again. Yes, this doesn't cover 100% of exploit cases, but nothing does, and I've found this to go a moderately long way to reduce the impact of various exploit attempts. So, to answer the question, I would say "it depends". If the .net hosted version also by default allows for writeable media that is also executable, then there would be problems. However, I don't expect a .net-based system would allow you to get a ".aspx" file in a publicly accessible URL and have it just execute when accessed (unless there's some deployment mode that would allow for that?)
- pchp 8y ago
  PeachPie doesn't allow this. We will enable the option once on-the-fly compilation will be implemented, but this is really really poor practice and we highly discourage the use of it.
  - mgkimsal 8y ago
    if there's a way you can enable writeable file sytem, but not compilation of anything executable, that may end up being the best of both worlds. WP could address some of this by requiring plugin media/js assets to be copied over to public folders during an 'init' process, while requiring the core PHP code to be outside of the document root/public area. But it would break on certain hosting platforms (I know that years ago, Plesk templates would enforce that nothing could live outside the document root - every upgrade they'd change all PHP permissions to only allow PHP execution inside the document root, perpetuating poor security practices for anyone who wanted to host on plesk-managed servers).
pchp 8y ago
Which nightmare? Maybe we can fix it. To answer your second question - yes, that's exactly what we're planning :)
partiallypro 8y ago
Saying Wordpress is a security nightmare is like saying Windows is a security nightmare. It has broad use, it has tons of people using it with outdated or unmanaged plugins on installs that haven't been updated in years...Some running near extinct PHP versions. If managed properly, put behind a firewall, etc it is quite safe. The hatred of Wordpress is laughable. It has its limits, but it meets most small-medium sized business needs when the project calls for minimal needs.
- krapp 8y ago
  As a product you're right - Wordpress serves the needs of small business and non-coder users perfectly well, arguably better than any alternative outside of hosted services like Wix (or, obviously, hosted Wordpress.) However, as software, Wordpress deserves the hate it gets. There is no real security or firewalling or permissions limiting of plugins, there is no hint of modern PHP practices like Composer integration, routing, or the use of a templating language (and no, PHP itself doesn't count) and the amount of cruft it carries with it for the sake of backwards compatibility makes it insanely complex and far more bloated than it needs to be. Wordpress in principle is a wonderful, useful product, and anyone trying to compete with it needs to closely study what it gets right (ease of deployment, ease of extension, ease of configuration, auto-updates, plugins, etc.) as well as what it gets wrong. Wordpress in practice, though, needs to be tossed into a pit and burned.
  - chiefalchemist 8y ago
    > "(ease of deployment, ease of extension, ease of configuration, auto-updates, plugins, etc.)" But those are The Right __and__ The Wrong. For example, adding Composer to the WP "stack" makes sense. But now you've eliminated 90% (?) of the WP "developers." That is, in the Universe of WordPress Composer is more friction, not less (i.e., ease of use). Long to short, for better or worse, WP is Justin Bieber. It will never be Radiohead.
    - krapp 8y ago
      >But now you've eliminated 90% (?) of the WP "developers." Maybe, but it wouldn't be impossible to rebuild plugins around Composer and PSR standards. And doing so would make them better organized, and make it easier to manage third party dependencies. If you were going to build Wordpress from scratch, today, that's probably what you would do - just make plugins a special case of Composer dependencies. The only question is, whether you would still have as robust an ecosystem with a more restrictive framework? Probably not, but the quality of plugins would probably be higher.
AmericanChopper 8y ago
Wordpress core has very secure coding practices, and if you can find an 0-day in it, then you've done very, very well. The problems with Wordpress are mostly: 1. WP installations are often not properly configured or maintained. 2. The plugin ecosystem is a mess of vulnerable and/or malicious code, or simply dead code that isn't maintained yet still deployed in the wild.
- stephenr 8y ago
  Writing your own userland implementation of prameterised queries is what you consider “very secure”? I’d hate to see what you think is terrible then.
  - AmericanChopper 8y ago
    What exactly is your criticism here? Do you know of some issue with prepare()? The quality of the core Wordpress code is quite high. You could argue that the plugin system is a footgun, but it’s kinda an essential element if you want extensibility.
    - stephenr 8y ago
      Parameterised queries done properly are sent to the database server specifically as a query with placeholders and values - the values are never evaluated as sql, there is no chance for a userland bug/attack to perform sql injection using them. What wordpress does is basically glorified printf, substituting values into a string. If you can’t see how this is a danger, you’re in no position to comment on the quality of the code.
      - AmericanChopper 8y ago
        Right, so you actually have absolutely nothing to say about the quality of wpdb. My point stands. The worst problems in Wordpress are the plugin ecosystem and poorly maintained instances.

Can this solve the Wordpress security nightmare ? are we going to see hosting services built on PeachPie in the near future ?

by petra 8y ago

Can this solve the Wordpress security nightmare ? are we going to see hosting services built on PeachPie in the near future ?

frankzander 8y ago

This can only be solved by a rewrite.

mgkimsal 8y ago

The bulk of WP security issues stem from the 'writable file system' defaults that many plugins (and, to some extent) core either expect or encourage. I can't say all, but the huge bulk of security issues I've seen revolve around some exploit which ends up writing a new file, or overwriting an existing file, which is then publicly accessible. If your file system is not writable, the large majority of WP exploits go away. However, you lose the "press here to upgrade your entire site and all the plugins in one easy step!" functionality, and the "upload files via the browser" ease-of-use. If you're truly modifying public media files on regular basis, a non-writeable file system kinda stinks (either make the FS writeable or use an external media host, which adds complexity and cost). MOST systems I run in to aren't doing this often - it's "put up the site and updates some pages every few months" (or, blogging, which is often just text). For these, I recommend turning off write permissions to the whole of the WP system, and periodically turning it back on to do updates, then turning it off again. Yes, this doesn't cover 100% of exploit cases, but nothing does, and I've found this to go a moderately long way to reduce the impact of various exploit attempts. So, to answer the question, I would say "it depends". If the .net hosted version also by default allows for writeable media that is also executable, then there would be problems. However, I don't expect a .net-based system would allow you to get a ".aspx" file in a publicly accessible URL and have it just execute when accessed (unless there's some deployment mode that would allow for that?)

pchp 8y ago
PeachPie doesn't allow this. We will enable the option once on-the-fly compilation will be implemented, but this is really really poor practice and we highly discourage the use of it.
- mgkimsal 8y ago
  if there's a way you can enable writeable file sytem, but not compilation of anything executable, that may end up being the best of both worlds. WP could address some of this by requiring plugin media/js assets to be copied over to public folders during an 'init' process, while requiring the core PHP code to be outside of the document root/public area. But it would break on certain hosting platforms (I know that years ago, Plesk templates would enforce that nothing could live outside the document root - every upgrade they'd change all PHP permissions to only allow PHP execution inside the document root, perpetuating poor security practices for anyone who wanted to host on plesk-managed servers).

pchp 8y ago

Which nightmare? Maybe we can fix it. To answer your second question - yes, that's exactly what we're planning :)

partiallypro 8y ago

Saying Wordpress is a security nightmare is like saying Windows is a security nightmare. It has broad use, it has tons of people using it with outdated or unmanaged plugins on installs that haven't been updated in years...Some running near extinct PHP versions. If managed properly, put behind a firewall, etc it is quite safe. The hatred of Wordpress is laughable. It has its limits, but it meets most small-medium sized business needs when the project calls for minimal needs.

krapp 8y ago
As a product you're right - Wordpress serves the needs of small business and non-coder users perfectly well, arguably better than any alternative outside of hosted services like Wix (or, obviously, hosted Wordpress.) However, as software, Wordpress deserves the hate it gets. There is no real security or firewalling or permissions limiting of plugins, there is no hint of modern PHP practices like Composer integration, routing, or the use of a templating language (and no, PHP itself doesn't count) and the amount of cruft it carries with it for the sake of backwards compatibility makes it insanely complex and far more bloated than it needs to be. Wordpress in principle is a wonderful, useful product, and anyone trying to compete with it needs to closely study what it gets right (ease of deployment, ease of extension, ease of configuration, auto-updates, plugins, etc.) as well as what it gets wrong. Wordpress in practice, though, needs to be tossed into a pit and burned.
- chiefalchemist 8y ago
  > "(ease of deployment, ease of extension, ease of configuration, auto-updates, plugins, etc.)" But those are The Right __and__ The Wrong. For example, adding Composer to the WP "stack" makes sense. But now you've eliminated 90% (?) of the WP "developers." That is, in the Universe of WordPress Composer is more friction, not less (i.e., ease of use). Long to short, for better or worse, WP is Justin Bieber. It will never be Radiohead.
  - krapp 8y ago
    >But now you've eliminated 90% (?) of the WP "developers." Maybe, but it wouldn't be impossible to rebuild plugins around Composer and PSR standards. And doing so would make them better organized, and make it easier to manage third party dependencies. If you were going to build Wordpress from scratch, today, that's probably what you would do - just make plugins a special case of Composer dependencies. The only question is, whether you would still have as robust an ecosystem with a more restrictive framework? Probably not, but the quality of plugins would probably be higher.

AmericanChopper 8y ago

Wordpress core has very secure coding practices, and if you can find an 0-day in it, then you've done very, very well. The problems with Wordpress are mostly: 1. WP installations are often not properly configured or maintained. 2. The plugin ecosystem is a mess of vulnerable and/or malicious code, or simply dead code that isn't maintained yet still deployed in the wild.

stephenr 8y ago
Writing your own userland implementation of prameterised queries is what you consider “very secure”? I’d hate to see what you think is terrible then.
- AmericanChopper 8y ago
  What exactly is your criticism here? Do you know of some issue with prepare()? The quality of the core Wordpress code is quite high. You could argue that the plugin system is a footgun, but it’s kinda an essential element if you want extensibility.
  - stephenr 8y ago
    Parameterised queries done properly are sent to the database server specifically as a query with placeholders and values - the values are never evaluated as sql, there is no chance for a userland bug/attack to perform sql injection using them. What wordpress does is basically glorified printf, substituting values into a string. If you can’t see how this is a danger, you’re in no position to comment on the quality of the code.
    - AmericanChopper 8y ago
      Right, so you actually have absolutely nothing to say about the quality of wpdb. My point stands. The worst problems in Wordpress are the plugin ecosystem and poorly maintained instances.