7 ms·

I don't care about performance, show me if security has improved! (which in the case of Wordpress can't be that hard)

by pawadu 10y ago

deckiedan 10y ago
WordPress security is complex. The core code is OK, security wise. Comparible to similar projects, I guess. The two major issues are that typically PHP runs with permission to modify the WordPress directory, which is useful for automatic upgrades, but means any exploit in any plugin, theme, etc. instantly becomes, "can replace WordPress". The other is that all themes and plugins are completely unsandboxed, and the quality is extremely variable. The permissions thing can be fixed, by running a very stripped down wp-php user with only read access to the code, and only write access to wp-contents/uploads (and a logging dir). Then you do automatic upgrades with wp-cli and (real) cron from a user with write access. The quality of plugins and themes is not easily fixed. The API for writing plugins and themes doesn't help. It's archaic, spaghetti, and doesn't have any kind of coherenc. Global functions like wp_is_home(), the_loop(), get_sitename(), etc. I've come across themes which bundle joomla inside them as they're really joomla themes with a shim.
- stephenr 10y ago
  > OK, security wise Since when is implementing your own home-grown shitty replacement for parameterised queries "OK"?
  - debacle 10y ago
    Since you need to support versions of PHP that don't support the extensions that have parameterized queries.
    - floatboth 10y ago
      Except… you don't? > WordPress also works with PHP 5.2.4+ and MySQL 5.0+, but these versions have reached official End Of Life and as such may expose your site to security vulnerabilities > PDO ships with PHP 5.1, and is available as a PECL extension for PHP 5.0 Unless you mean "hosts that disabled PDO"… I think they can safely be ignored.
      - debacle 10y ago
        PDO is disabled by default, and was even on default installs of 5.6 last I checked.
        floatboth 10y ago
        What "default"? Compiled from source? Debian package? Just checked, seems enabled by default on FreeBSD. (Commented out in php.ini doesn't mean disabled — here it's enabled in separate files like /usr/local/etc/php/ext-30-pdo_mysql.ini) MODX Revolution uses PDO exclusively, never had problems with it on any hosting service.
        debacle 10y ago
        I don't really understand your point. WordPress is ubiquitous. Until today I've never heard of MODX Revolution. Commented out in php.ini does mean disabled - as in not enabled. PDO isn't enabled by default in FreeBSD you still need to install a separate package for PDO.
        stephenr 10y ago
        His/Her point was that if someone is still using shared hosting (where they can't change the extensions available) it would be very rare to find one that doesn't have PDO enabled. > Commented out in php.ini does mean disabled - as in not enabled. Not necessarily, as I explained here: https://news.ycombinator.com/item?id=13761550 https://news.ycombinator.com/item?id=13761550
        stephenr 10y ago
        Most Linux/BSD distributions seem to separate out "core" PHP extensions (those that are distributed with php source, not via peel) into individual packages. So while PDO may not be installed by a plain `apt-get install php5` or similar, I doubt the now deprecated `mysql` extension is installed by "default" in those scenarios either. Edit: this approach also means that the PDO extension in php.ini will be commented, because its loaded by a package specific ini file e.g. /etc/php/7.0/fpm/conf.d/* which are generally symlinks to /etc/php/7.0/mods-available/
    - stephenr 10y ago
      Which version of PHP does WordPress support that doesn't support parameterised queries? Here's a hint: Wordpress since v3.3 needs PHP 5.2+. MySQLi was added in PHP 5.0, PDO in 5.1 WordPress v3.3 was released in 2011.
- pawadu 10y ago
  > WordPress security is complex. This must be an oxymoron since complexity is the enemy of security. I think what you meant to say was > WordPress security is at best ad-hoc, and mostly non-existing
  - deckiedan 10y ago
    I was replying to > show me if security is improved! > (which for Wordpress can't be that hard) that is, to say that the concept of 'WordPress Security' isn't a single simple thing to 'improve'. Unfortunately. If you wrote a set of 10 jillion tests and proved that wordpress core has no possible security vulnerabilities (humour me), that still would not fix 'WordPress Security'. From a theoretical point of view, you're absolutely right, and I agree with you. From a practical point of view, WordPress is often 'good enough', and 'works well enough', and has 'few enough security issues', for many people. Improving security is great, but it's a complex, perhaps impossible problem.
josefresco 10y ago
You're seriously out of touch if you think the WP Core is not secure. You must realize they have a very competent team (https://automattic.com/ https://automattic.com/), not to mention thousands of OSS developers that continually contribute. Does your company, or does this small team of techs even come close? https://wordpress.org/about/security/ https://wordpress.org/about/security/
- pawadu 10y ago
  not even have a very competent team can put enough lipstick on this pig: http://www.cvedetails.com/vulnerability-list/vendor_id-2337/year-2017/opec-1/Wordpress.html http://www.cvedetails.com/vulnerability-list/vendor_id-2337/...
  - josefresco 10y ago
    What you're missing is that these security exploits are discovered, patched and disclosed. The same can't be said about most tech services / products. Security through obscurity is not a viable strategy.
    - mtberatwork 10y ago
      Perhaps, but WP also has a large user base from which to pull from so I would hope vulnerabilities get discovered and patched quickly. However, I think it's quite telling that such a popular project still has issues with SQL injection even with so much active development apparently going on.
    - pawadu 10y ago
      What has this to do with security through obscurity?? WP security is like Whac-A-Mole, you patch one serious issue and two more pop up. It has been like this for years which shows that the developers don't have the correct mindset to write internet facing code. I pointed you to a SQL injection / remote execution vulnerability in the WP core, in 2017 for gods sake.
busterarm 10y ago
I'll do you one better. We're hosting a private-facing WordPress with several custom post types and some custom fields using ACF Pro. Then we pull directly out of the database with some not-too-complex and fast SQL queries and build a static site with Jekyll. The whole thing is about 200 lines of Ruby + a bunch of configuration for each post type. I'm working on making this a little more generic, because this thing really smokes. In migrating to this, I'm doing a similar process with our previous mess of a WordPress site by pulling from the DB and writing JSON. WP All Import + ACF plugin takes care of the rest. All uploads are now served out of S3 buckets and our editors write Kramdown now instead of HTML and inline CSS. We can easily A/B test or Multi-Armed Bandit now too. It would have been a lot easier if the Wordpress REST API weren't a piece of junk. SQL is consistent at least.
- mtberatwork 10y ago
  How are you handling all the rendering that WP needs to do on a post (e.g. shortcodes, special HTML formatting, etc)? ... or are you just forcing your users to write Kramdown and leaving out things like shortcodes? IMO, the worst parts about Wordpress are: 1) complete coupling of data to PHP and 2) the absurdly terrible DB schema.
  - busterarm 10y ago
    I disabled the default toolbar with shortcodes and replaced it with my own with Kramdown versions. I hooked the Add Media button to output Kramdown instead of HTML as well. Also we're having our editors write Kramdown. Lastly, when pulling all the data, I determine if the post is HTML or Kramdown and use the Kramdown library to parse the HTML. Everything migrated from the old site was automatically converted to Kramdown this same way and had to have some minor cleanup work done on each post. Not a small task on our main WordPress site with 7000+ posts/pages. The interesting part was that wp_autop() happens at render time, so to get Kramdown to parse the HTML correctly, you actually have to RegExp replace '\n\n' with '<br /><br />' first to preserve paragraphs.
- rmccue 10y ago
  I'd love to hear what problems you've had with the WP REST API. Always looking at ways to make it better.

I don't care about performance, show me if security has improved! (which in the case of Wordpress can't be that hard)

by pawadu 10y ago

I don't care about performance, show me if security has improved! (which in the case of Wordpress can't be that hard)

WordPress security is complex. The core code is OK, security wise. Comparible to similar projects, I guess. The two major issues are that typically PHP runs with permission to modify the WordPress directory, which is useful for automatic upgrades, but means any exploit in any plugin, theme, etc. instantly becomes, "can replace WordPress". The other is that all themes and plugins are completely unsandboxed, and the quality is extremely variable. The permissions thing can be fixed, by running a very stripped down wp-php user with only read access to the code, and only write access to wp-contents/uploads (and a logging dir). Then you do automatic upgrades with wp-cli and (real) cron from a user with write access. The quality of plugins and themes is not easily fixed. The API for writing plugins and themes doesn't help. It's archaic, spaghetti, and doesn't have any kind of coherenc. Global functions like wp_is_home(), the_loop(), get_sitename(), etc. I've come across themes which bundle joomla inside them as they're really joomla themes with a shim.

stephenr 10y ago
> OK, security wise Since when is implementing your own home-grown shitty replacement for parameterised queries "OK"?
- debacle 10y ago
  Since you need to support versions of PHP that don't support the extensions that have parameterized queries.
  - floatboth 10y ago
    Except… you don't? > WordPress also works with PHP 5.2.4+ and MySQL 5.0+, but these versions have reached official End Of Life and as such may expose your site to security vulnerabilities > PDO ships with PHP 5.1, and is available as a PECL extension for PHP 5.0 Unless you mean "hosts that disabled PDO"… I think they can safely be ignored.
    - debacle 10y ago
      PDO is disabled by default, and was even on default installs of 5.6 last I checked.
      - floatboth 10y ago
        What "default"? Compiled from source? Debian package? Just checked, seems enabled by default on FreeBSD. (Commented out in php.ini doesn't mean disabled — here it's enabled in separate files like /usr/local/etc/php/ext-30-pdo_mysql.ini) MODX Revolution uses PDO exclusively, never had problems with it on any hosting service.
        debacle 10y ago
        I don't really understand your point. WordPress is ubiquitous. Until today I've never heard of MODX Revolution. Commented out in php.ini does mean disabled - as in not enabled. PDO isn't enabled by default in FreeBSD you still need to install a separate package for PDO.
        stephenr 10y ago
        His/Her point was that if someone is still using shared hosting (where they can't change the extensions available) it would be very rare to find one that doesn't have PDO enabled. > Commented out in php.ini does mean disabled - as in not enabled. Not necessarily, as I explained here: https://news.ycombinator.com/item?id=13761550 https://news.ycombinator.com/item?id=13761550
      - stephenr 10y ago
        Most Linux/BSD distributions seem to separate out "core" PHP extensions (those that are distributed with php source, not via peel) into individual packages. So while PDO may not be installed by a plain `apt-get install php5` or similar, I doubt the now deprecated `mysql` extension is installed by "default" in those scenarios either. Edit: this approach also means that the PDO extension in php.ini will be commented, because its loaded by a package specific ini file e.g. /etc/php/7.0/fpm/conf.d/* which are generally symlinks to /etc/php/7.0/mods-available/
  - stephenr 10y ago
    Which version of PHP does WordPress support that doesn't support parameterised queries? Here's a hint: Wordpress since v3.3 needs PHP 5.2+. MySQLi was added in PHP 5.0, PDO in 5.1 WordPress v3.3 was released in 2011.
pawadu 10y ago
> WordPress security is complex. This must be an oxymoron since complexity is the enemy of security. I think what you meant to say was > WordPress security is at best ad-hoc, and mostly non-existing
- deckiedan 10y ago
  I was replying to > show me if security is improved! > (which for Wordpress can't be that hard) that is, to say that the concept of 'WordPress Security' isn't a single simple thing to 'improve'. Unfortunately. If you wrote a set of 10 jillion tests and proved that wordpress core has no possible security vulnerabilities (humour me), that still would not fix 'WordPress Security'. From a theoretical point of view, you're absolutely right, and I agree with you. From a practical point of view, WordPress is often 'good enough', and 'works well enough', and has 'few enough security issues', for many people. Improving security is great, but it's a complex, perhaps impossible problem.

josefresco 10y ago

You're seriously out of touch if you think the WP Core is not secure. You must realize they have a very competent team (https://automattic.com/ https://automattic.com/), not to mention thousands of OSS developers that continually contribute. Does your company, or does this small team of techs even come close? https://wordpress.org/about/security/ https://wordpress.org/about/security/

pawadu 10y ago
not even have a very competent team can put enough lipstick on this pig: http://www.cvedetails.com/vulnerability-list/vendor_id-2337/year-2017/opec-1/Wordpress.html http://www.cvedetails.com/vulnerability-list/vendor_id-2337/...
- josefresco 10y ago
  What you're missing is that these security exploits are discovered, patched and disclosed. The same can't be said about most tech services / products. Security through obscurity is not a viable strategy.
  - mtberatwork 10y ago
    Perhaps, but WP also has a large user base from which to pull from so I would hope vulnerabilities get discovered and patched quickly. However, I think it's quite telling that such a popular project still has issues with SQL injection even with so much active development apparently going on.
  - pawadu 10y ago
    What has this to do with security through obscurity?? WP security is like Whac-A-Mole, you patch one serious issue and two more pop up. It has been like this for years which shows that the developers don't have the correct mindset to write internet facing code. I pointed you to a SQL injection / remote execution vulnerability in the WP core, in 2017 for gods sake.

busterarm 10y ago

I'll do you one better. We're hosting a private-facing WordPress with several custom post types and some custom fields using ACF Pro. Then we pull directly out of the database with some not-too-complex and fast SQL queries and build a static site with Jekyll. The whole thing is about 200 lines of Ruby + a bunch of configuration for each post type. I'm working on making this a little more generic, because this thing really smokes. In migrating to this, I'm doing a similar process with our previous mess of a WordPress site by pulling from the DB and writing JSON. WP All Import + ACF plugin takes care of the rest. All uploads are now served out of S3 buckets and our editors write Kramdown now instead of HTML and inline CSS. We can easily A/B test or Multi-Armed Bandit now too. It would have been a lot easier if the Wordpress REST API weren't a piece of junk. SQL is consistent at least.

mtberatwork 10y ago
How are you handling all the rendering that WP needs to do on a post (e.g. shortcodes, special HTML formatting, etc)? ... or are you just forcing your users to write Kramdown and leaving out things like shortcodes? IMO, the worst parts about Wordpress are: 1) complete coupling of data to PHP and 2) the absurdly terrible DB schema.
- busterarm 10y ago
  I disabled the default toolbar with shortcodes and replaced it with my own with Kramdown versions. I hooked the Add Media button to output Kramdown instead of HTML as well. Also we're having our editors write Kramdown. Lastly, when pulling all the data, I determine if the post is HTML or Kramdown and use the Kramdown library to parse the HTML. Everything migrated from the old site was automatically converted to Kramdown this same way and had to have some minor cleanup work done on each post. Not a small task on our main WordPress site with 7000+ posts/pages. The interesting part was that wp_autop() happens at render time, so to get Kramdown to parse the HTML correctly, you actually have to RegExp replace '\n\n' with '<br /><br />' first to preserve paragraphs.
rmccue 10y ago
I'd love to hear what problems you've had with the WP REST API. Always looking at ways to make it better.