go hard with wp

[pwired]

couldn't help my self from posting this, please forgive

http://blog.sucuri.net/2014/07/remote-file-upload-vulnerability-on-mailpoet-wysija-newsletters.html

http://www.binarymoon.co.uk/2014/06/new-timthumb-exploit-found/

[Joss]

I really must get round to converting two blogs of mine to PW from WP.

Trouble is I haven't worked out how to do it.

[teppo]

I'm the last person to stand up for WP (seriously), but still have to point out that neither of these are really issues with WP itself. In fact most of WP problems I've seen have been related to 3rd party plugins/modules.

I'm not saying that it's not the fault of the system in some way, as they really should provide a safe platform for 3rd party extensions to build on (and clearly that's not always true in the case of WP), but they (WP core developers) can't be held responsible for whatever crappy code people implement on top of the good parts of that platform.

.. oh, and my main point is that this should really serve as a warning for us too: it's entirely possible, if not exactly easy, to create modules with vulnerabilities on top of ProcessWire. As the amount of modules grows, issues like this become more likely and thus we (module authors and users alike) really need to take an active role on preventing them.

IMHO.

[totoff]

Trouble is I haven't worked out how to do it.

PageListMigrator together with Nico's WP-importer maybe? Worked perfectly fine for me.

[Joss]

Yeah, I noticed those later  - I might have a look. My main issue is that a huge amount of the posts have WP galleries attached. 

[adrian]

Yeah, I noticed those later  - I might have a look. My main issue is that a huge amount of the posts have WP galleries attached. 

Joss - this is something we should be able to handle with the Wordpress migrator - how are your galleries set up? A particular plugin? At present it handles images embedded into the WP RTE - these get imported to a PW images field and embedded back into the post.

Anyway, let us know how your galleries are set up and we'll see what needs to be done to make the migrator work.

[Nico Knoll]

Maybe you could use ryan's csv import after exporting the database as csv. Then you could easily add some special stuff into the while-loop

[pwired]

it's entirely possible, if not exactly easy, to create modules with vulnerabilities on top of ProcessWire.

Makes me wonder: if you make a module for processwire,

how do you guys check if it can be hacked ?

[Soma]

I'm the last person to stand up for WP (seriously), but still have to point out that neither of these are really issues with WP itself. In fact most of WP problems I've seen have been related to 3rd party plugins/modules.

I'm not saying that it's not the fault of the system in some way, as they really should provide a safe platform for 3rd party extensions to build on (and clearly that's not always true in the case of WP), but they (WP core developers) can't be held responsible for whatever crappy code people implement on top of the good parts of that platform.

.. oh, and my main point is that this should really serve as a warning for us too: it's entirely possible, if not exactly easy, to create modules with vulnerabilities on top of ProcessWire. As the amount of modules grows, issues like this become more likely and thus we (module authors and users alike) really need to take an active role on preventing them.

IMHO.

Very wise words. ProcessWire have to be careful to not become a module hell. It can easily get out of hand.

[Joss]

Nico

They are just the normal WP grid - I try and avoid extra plugins other than a lightbox, but that is a template/jquery issue.

I often have one image at the head of the article, then the rest at the end as a grid:

http://www.foodloversdiary.com/allotment-diary/weeding-in-the-rain/

The way WP handles these has changed a bit over the years - in the old system you would have all your page uploaded images appear as a gallery, unless you hand wrote exclusions into the hanna code, for instance if you did not want to repeat any images in the rest of the article. I am not sure how the new system works. Of course, my blog is old enough to have both!

Very wise words. ProcessWire have to be careful to not become a module hell. It can easily get out of hand.

This is why I think that any modules that are available via the PW website, need to be ones that have been checked first, especially for security issues. Same with things like profiles and so on.

[apeisa]

I think there are two separate issues regarding 3rd party plugins/modules and their safety:

1. How good and well documented platform is to others to plug into? This "protip" from other of the articles was pretty confusing for me: 

Pro-tip: If you are a developer, never use admin_init() (or is_admin()) as an authentication method.

Whaaat? is_admin() sounds like a function I could use to check if it's admin user... It of course could mean something else, like "is this page admin page" and then page like login could be admin page too... but none the less, it's confusing for sure.

2. Is there any kind of "approval" seal from official or credible party? It doesn't necessarily need to be "official", but if there is some company that I trust saying "this plugin is well coded and we didn't find any security holes from it - or the ones we found are already fixed" - then that of course adds confident towards that plugin.

The first one is handled brilliantly in ProcessWire - documentation could always be more coherent, but I think most module developers get the basics pretty easily and source code is very well written and commented. And I haven't seen a module/hooking system anywhere that is better than ProcessWire's - and the API is very clean and coherent.

Second one is more problematic, since security reviews require lots of time and high skills, that not many have. Currently I only use modules that I fully understand what they do and how they work. Module that does something with file uploads, logins or UA in general are of course most critical in this regard.

[adrian]

They are just the normal WP grid - I try and avoid extra plugins other than a lightbox, but that is a template/jquery issue.

I often have one image at the head of the article, then the rest at the end as a grid:

Joss, I think MigratorWordpress is pretty close to handling this out of the box - I will need to add a function that scans links from embedded thumbnails to large images and have those added to the PW page as well as the thumbnails which should already work. Then you'd just need to make sure the gallery classes and lightbox scripts are available on your PW site so that the the RTE embedded thumbnails are styled correctly.

[Joss]

I wonder if it is worth putting together a WP migrator profile that has everything installed ready, the right fields in place and a really, really basic template that is heavily commented?

Obviously, it cannot have everything, but if it has a category layout, tags, images sorted out, a WP style pages system (as opposed to the posts) the common hanna code bits and things like fb and twitter tags all ready, the it might be very useful for those who want to get away from WP as a blog. 

Also needs to take into account read more and mutipage articles.

[Pete]

It's actually really easy to make a non-secure module for Processwire - just skip any sanitization or erode a few permissions accidentally for example.

That's the problem - it doesn't matter how good or bad the underlying system is, any system with a plugins/module system wants you to be free to build what you like so it's down to the module author and some sort of checking process to make sure that modules that end up in the directory aren't creating vulnerabilities.

The scary question is: how do we keep on top of that as plugins become more prolific over time? At the moment to my knowledge ryan looks over each one before approving them. Even then, that doesn't help you with plugins that aren't in the directory - you're on your own there!

[teppo]

Even then, that doesn't help you with plugins that aren't in the directory - you're on your own there!

As harsh as it may sound, I'd say that this isn't something we can affect, and thus not something we should worry about. The best we could do in this regard would probably be adding some sort of indicator to admin whether a specific module is found from the modules directory or not, just to make it obvious that you really are on your own there

[Nico Knoll]

What about certificated modules? Like every module in the modules section should be checked and afterwards gain a link containing a code. If you cick on it the certificate is shown containing module version release date and source and the md5 key to check if something is modified. Something like this. So you would know if you're using a safe module (with serialization, etc.)

[Joss]

I agree - it is really worth the time making sure that everything that is available via the ProcessWire website is, as much as is practicable, checked to be safe to use, but not trying to affect anything outside of that system.

However, this also needs to be made clear - especially for downloads on the forum; those should always be flagged up as Not Approved. 

One thing that does help here is that since PW in its native form is NOT like Drumalpress, as in it does need work to get it going for a website, doesn't have themes, and so on, it is not really ripe for a million and one plugins that introduce possibly insecure third party scripting.

The most famous example of that over the years has been the old perl mail script (a php version was also made) that was adopted as an installable script by just about every hosting company and was also used as the core of many plugins for countless early CMSs. Until, that is, it was found to have a basic, really bad security hole that affected everyone.

I think as part of this it is worth limiting the number of modules available and making sure dated ones are flagged up or removed (like my old Bootstrap profile - this makes it more manageable. Nico's idea of certification might be worth looking at eventually, but that can put Ryan in an awkward legal position if something goes wrong; if he is certifying modules, he then legally becomes responsible for them....

[LostKobrakai]

I think as part of this it is worth limiting the number of modules available and making sure dated ones are flagged up or removed (like my old Bootstrap profile - this makes it more manageable.

That's one of the backdraws I found while using wordpress. There's so much old and halfbacked stuff available as plugins, that you easily get outdated / insecure php code in your project. Also, I've seen clients try to install functionality like a member-only part of a page on their own by installing a bunch of plugins, with only a bunch of html/css knowledge.

[pwired]

Still going hard - - -

http://blog.sucuri.net/2014/07/mailpoet-vulnerability-exploited-in-the-wild-breaking-thousands-of-wordpress-sites.html

I need to know now - - -

[Pete]

Going back to the idea of some sort of badge for modules in the directory, maybe instead of saying "certified" it could say "approved" instead, which gets around the issue Joss mentioned in the last paragraph of his post.

I think as long as there is some clear wording accompanying this then it would be fine.

I like the idea of something like this to say it has had some sort of check anyway, as well as something to distinguish "approved" modules in the admin. It would also lead people to post to the modules section more as there are some modules that only end up linked from the forums which is a shame.

@pwired: they have 32,411 plugins for Wordpress - I suspect if we did then we might encounter the same problem (though I hate the idea that we might have 1,327 of those with the word "gallery" in the title like WP do - lots of duplication there!).

[pwired]

For processwire: what about a review process for approving new modules ?

Or a module that scans for vulnerabilities and inform when it finds vulnarable code ?

=============================================

It is not just the number of available plugins going around but certainly also about lazy webmasters.

There is a lot that webmasters can do to reduce hacks and plugin exploits

1.

Change a default table prefix into something like bhsug479_

and it will make sql injection less easy.

2.

prevent script injection, and unwanted modification of _request and or globals:

# protect from sql injection
Options +FollowSymLinks
RewriteEngine On
RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
RewriteRule ^(.*)$ index.php [F,L]

3.

Reduce ip access to the admin to a static ip or a limited ip range

# deny access to admin
order deny,allow
allow from xx.xx.xx.xx # static IP or limited IP range
deny from all

4.

Limit Access to important directories

Order deny,allow
Deny from all
<Files ~ “.(xml|css|jpeg|png|gif|js)$”>
Allow from all
</Files>

5.

Protect config.php files

# protect config.php
<files config.php>
Order deny,allow
Deny from all
</files>

6.

# disable directory browsing
Options All -Indexes

use empty index.html files

Hide a plugin folder with an empty index.html
 

7.

# protect your .htacces files

<Files ~ "^.*\.([Hh][Tt][Aa])">
order allow,deny
deny from all
satisfy all
</Files>
 

8.

Prevent the admin section from being indexed.

9.

Set a .htaccess password on the admin directory

10.
Choose safe chmod permissions depending on the user-id of the running server and your hosting type.

http://phpsec.org/projects/guide/

11.

Change the admin url into something cryptic and prevent it

from being site browsable

12.

Create a new administrator account with a name that is hard to guess

Then delete the default administrator account

13.

Restrict the number of failed logins in a limited time window.

Do not echo wrong login error messages as this is feedback to a hacker

14.

Move important files and directories one level above your site root on the server.

[teppo]

@pwired: they have 32,411 plugins for Wordpress - I suspect if we did then we might encounter the same problem (though I hate the idea that we might have 1,327 of those with the word "gallery" in the title like WP do - lots of duplication there!).

The problem especially with any markup-generating modules -- there's an unlimited amount of possibilities. Unless the thing you're trying to achieve is relatively simple ("list tweets from this user account") or implements very extensive markup configuration options, you'll end up with a ton of modules doing just about the same but with slightly different markup

Definitely something to consider for us too: as a general guideline, if there's a module that does just about the same already, it would be awesome if module authors would seriously consider working together instead of posting near-duplicates just to address some minor difference of opinions.

Just saying -- I know it's not easy in real world use cases. Still I've seen that happen many times over on our modules, which is great 

[teppo]

For processwire: what about a review process for approving new modules ?

Or a module that scans for vulnerabilities and inform when it finds vulnarable code ?

Clearly defined review process is a good thing to have, +1 for that. I've found this essential in larger projects, but it's not very easy to get right level of specificity. You do want to make sure that all the important things are checked yet you don't want to limit too much (and a process that's defined but not used and/or followed is worse than not having a process at all, as it only gives you false confidence.)

Something that scans for vulnerabilities would be very interesting to see in action. It should not be relied upon, but could definitely be used to spot the most obvious sources of potential issues. The main problem is that it can't really distinguish between valid use cases of those "potentially problematic" things:

• SQL queries can be an issue, except that some modules really need those (and even Ryan has suggested using them a few times on the forum).
• Calls to system(), exec() and/or shell_exec() can be very dangerous, but some modules can and do use them appropriately.
• preg_replace() with 'e' modifier is dangerous, but again far less dangerous if used properly (not letting user input affect it etc.)
• External libraries (and thus any call to include(), require() etc.) are always sources of potential security issues.
• Any user input is a potential issue, unless properly handled (nearly impossible to distinguish by static analysis.)
• Anything related to handling files yourself is potentially dangerous.

.. and then there are a ton of very real security issues that would be next to impossible to spot just by programmatically analysing code. Anyway, I'm definitely not against such a scanner (and have, in fact, been evaluating a few code analysis tools lately) as long as it's not thought to be some sort of miracle cure. It's not.

RIPS is one of the options for doing this kind of thing without writing a ton of code yourself, but it seems that the project is kind of dead right now. No idea when that happened or at what state the existing code base is in, but I wouldn't count too much on that either.

I'm not going to comment on the rest of your post except by mentioning that this doesn't have much to do with ProcessWire

[pwired]

@Teppo: I think the points you mentioned there are a good guide to use with a review process.

I'm not going to comment on the rest of your post except by mentioning that this doesn't have much to do with ProcessWire

You are right about that. I think that for the rest of my post I correctly referred to lazy webmasters,

and not to processwire. Reducing hacks and exploits is not only about getting your code right,

but significantly also about webmasters doing their job right at the root.

[teppo]

You are right about that. I think that for the rest of my post I correctly referred to lazy webmasters,

and not to processwire. Reducing hacks and exploits is not only about getting your code right,

but also about webmasters doing their job right at the root.

Perhaps we're talking about same thing here, but what I meant is that these are just about all handled by ProcessWire out of the box, in one way or another. Probably the most important things webmasters can do are a) avoiding shared hosting like the plague (there are a few examples where this is done right, but usually it's broken and/or a compromise between security and usability) and b) handling server-level permissions properly.

I tend to stick with pretty strict permission model and, for an example, won't ever give ProcessWire itself (i.e. the Apache user) permission to write anywhere it strictly speaking doesn't need to write. IMHO making things like .htaccess writable for Apache is not such a good idea, but perhaps that's just me being paranoid.

In your post you said that "Set 777 permissions on important content", which seems kind of backwards to me. 777 isn't really harmful in controlled environments, but it's very rarely needed either, unless your permissions, groups etc. are configured in a really weird way. Sometimes it's easier to use that if you don't know what sort of permissions, users and groups the server will have, but that's just about all it's ever good for in this context.