Hacker News new | ask | show | jobs
by mgkimsal 2913 days 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?)

1 comments

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.
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).