WordPress December follow up

[pwired]

WordPress december follow up:
Malware turns wordpress sites and blogs into hack tools.
Google blocked already around 11.000 domains to prevent further outbreak.

http://blog.sucuri.net/2014/12/revslider-vulnerability-leads-to-massive-wordpress-soaksoak-compromise.html

Last september:
http://blog.sucuri.net/2014/09/slider-revolution-plugin-critical-vulnerability-being-exploited.html

Next one who is going to ask me:
"Can't you do it in WordPress"
I am going to show 2014 breakdowns.

[adrian]

To be fair to WP, this is not a vulnerability with the core code, but rather an issue with a 3rd party plugin: http://codecanyon.net/item/slider-revolution-responsive-wordpress-plugin/2751380

I haven't read the details of the issue, so perhaps some stronger core code might have prevented this, but it doesn't matter how good the core code is, a plugin/module can be a vector for security issues in even the most secure core code.

[owzim]

adrian, yeah, but the massive amount of plugins to do great stuff out of the box is one of the key points pro-WP-people make. If you can't trust them plugins, there are not many pro arguments left.

[kixe]

What about modules in processwire? Everything safe? Maybe we need a tag [security-checked] given by an accredited team of PW developers.

[pwired]

What about modules in processwire? Everything safe? Maybe we need a tag [security-checked] given by an accredited team of PW developers.

There are already some posts about this. I remember Soma did some good recommendations.

I also remember something about approval. Something to let a module go through some kind

of approval check before it becomes downloadable.

I will look for those posts later on.

Let's stick our coding heads together and make Processwire Modules the safest on the planet.

[qtguru]

It's not a bad idea, but at some point PW would get bigger and a large amount of plugins could be sent for review, that could be the downside of approval. sadly i have no recommendation on how to achieve this. 

[dazzyweb]

I am not sure if all modules or plugins will ever be completely 100% secure. Someone correct me if I am wrong as I am not an authority on security.

Can we really say that the vulnerabilities found out in some Wordpress plugins won't be found in Processwire sometime in the future with or without checks when Processwire becomes more of a target like Wordpress currently is?

The plugin in question for Wordpress is a big plugin with 100 thousand plus installations and I am sure that as many checks as possible were made with it(but obviously not enough).

The way I see it is that bugs happen and mistakes will always happen as long as humans run the show.

[Joss]

The thing with Processwire, for the security conscious, is that you can create a huge variety of sites and address many different types of content WITHOUT touching any plugins other than what comes from Ryan's safe hands.

You can add all the seo stuff you would ever need, add connections to social websites with links and opengraph or whatever, add caching and so on, without ever having to move outside the box - you just stick them in your template files and feed them from a field somewhere.

And if you want singing and dancing with JQuery plugins, again, you just use them raw - you don't have to set up new database connections or anything else clever to make them Pw compliant - you only use the trusted API and keep the two well and truly apart.

With WP, on the other hand, if you want anything more than the simplest of blogs, you are already on a plugin-fest from hell before you ever get going.

Noting all that, I think it is VITAL that this principle is sustained with processwire with the vast majority of modules being about admin functionality (and vetted first as much as possible) and front end functionality left to the site development where the developers can make reasoned choices.

If you want a completely plug-n-play CMS, unfortunately that will ALWAYS come with plug-n-play security issues ....   

[Joss]

The way I see it is that bugs happen and mistakes will always happen as long as humans run the show.

I wonder if bugs were running the show, would they suffer from malicious humans?

[teppo]

[...] you don't have to set up new database connections or anything else clever to make them Pw compliant - you only use the trusted API and keep the two well and truly apart.

This is the key point here: API. It improves the security a lot compared to having to rely on plain SQL, which is always more or less prone to human error, leading to injection vulnerabilities, etc. Another thing is that most modules seem to avoid potentially harmful methods like exec, shell_exec, passthru, etc. Not sure if that's really anything specific to ProcessWire, though

Anyway, one can still easily write a ProcessWire module that trusts user input too much, or trusts input from wrong users, or simply displays too much to unauthorised users. This is why some sort of security audit process would be most welcome, though perhaps as an addition, not something that automatically applies to every module submitted to the modules directory.

[apeisa]

To make the audit process easy enough, there probably should be something automatic code analysis going. Like sensio insight.

[teppo]

@apeisa: definitely.

I've been test-driving a few locally-hosted solutions, with mixed results (some were "kind of useful", but none really convinced me). Sensio Insight seems interesting alternative, though so far it seems to think that my code is safe, which is a huge red flag to me

.. oh, and for the record: programmatic vulnerability scanning is helpful, but I'm always a bit worried that people could trust it too much. There are too many logical issues for it to be "perfect", and thus it might give some users false feeling of safety.

[Joss]

True enough, Teppo - but like anything automated, it is a good way of starting the analysis. So you have 50 submitted modules to check, start by something automated and those that fail go straight in the bin.

Those that pass, then go onto further scrutiny.

It all fails when automated systems are the LAST stop rather than the first

[pwired]

To make the audit process easy enough, there probably should be something automatic code analysis going. Like sensio insight.

I think this is very well possible. Penetration tests can be automated for a number of well known ways

hackers are using. I am sure that this is something that doesn't exist for wordpress. By the way

wordpress is not suffering from the human factor but from supposed functionality.

It was never designed for full blown websites.

[Macrura]

i've had too much wordpress in the last 6 months.

130 hours building an ecommerce site using woocommerce;

now 10 hrs restoring a hacked site for a friend who didn't backup.

My message to anyone reading this who might try and Wordpress: Don't Do It!

[Pete]

I think at the moment ryan approves all modules before they appear in the list so I assume he is looking at the code before approving them.

The problem is, as a play on what Joss says above, you can do just as much damage without modules on your own. You can open up security vulnerabilities in any CMS with a little effort (I believe both MODx and WP allow you to write pure PHP in templates/snippets as well as PW of course), so even leaving modules aside it's possible to create your own issues in very few lines of code and be totally oblivious to the dangers.

My point is, modules or not, a lack of knowledge is the enemy here. Not everyone has the knowledge necessary (myself included) to understand the more complex modules out there so the recommendation that I would love to give of "don't use a module if you've not investigated its code" doesn't even work for me

I guess the best thing moving forward is to have a few more people checking out the modules submitted to the Modules page and recommend that nobody downloads modules that haven't been posted there. That might seem harsh as I know there are many good modules only on Github, but if nothing else it will encourage people to submit their modules to the directory - let's face it, it doesn't take much time at all.

[Joss]

I suppose this is an inevitable result of open source.

If the company is solely responsible for all code, then they can put in tough QC measures in at source. Even then, they can get caught out by their own mistakes, but at least they know where to look.

Having said that, you then might have security problems with the server, the OS or the language (PHP has had the odd issue...)

The lower down the food chain you are and the more reliant you are on third party input, the more vulnerable you are. Or at least if feels like that from my one man band perspective.

[Pete]

I dunno, I like the idea of me being the weakest link in my work

[teppo]

To make the audit process easy enough, there probably should be something automatic code analysis going. Like sensio insight.

Antti: I've been looking into this particular tool, and so far I'm liking it a lot. Just wondering if you've had the chance to run it against any real projects, and if you found it useful? Did it spot any real issues, etc.?

I'll have to go through the rest of my own projects to see if it can spot anything really suspicious, but so far only issues have been a README file not ending properly in a newline character (!) and a module file having a bunch of @todo comments (makes sense to flag these as potential risk, though in this case they were ideas for future enhancements/additions, so not really relevant at all). 

[teppo]

I guess the best thing moving forward is to have a few more people checking out the modules submitted to the Modules page and recommend that nobody downloads modules that haven't been posted there. That might seem harsh as I know there are many good modules only on Github, but if nothing else it will encourage people to submit their modules to the directory - let's face it, it doesn't take much time at all.

Agreed. The modules directory is the only guarantee we have of a module being of good quality. I don't find it harsh at all to say that don't trust modules not submitted/approved to the modules directory (I've been stating that already on many occasions), and when it comes to security, it's always better to be too harsh than too lenient

In my opinion a module not being submitted to the modules directory is a sign of the author a) not knowing much of the ProcessWire environment / ecosystem (which can be a bad thing), b) not considering the module ready enough for the directory (in which case it definitely isn't ready for production use), or c) the author being too lazy or busy to submit the module (which means that the support will most likely be lacking too).

[apeisa]

Teppo, no real experience of insight, at least not yet.

[lisandi]

sensio insight is a good tool and used by Drupal8 a lot since they are on symphony.

Security is quite important and most important is actually a lively reporting community!!! Which means the mor people are using processwire the more vulnerabilities probably also get discovered and reported.

1. I would start using PHP 5.5 ONLY and no more provide backwards compatibility. This will increase security a lot already. Simply make a cut and release a new version which is only compatible with PHP 5.5 and higher. TYPO3 7.0 was just doing that step and it is a huge speed (it is really fast!) and a huge security improvement already! OK some modules/extensions are not working but this is a very useful cleaning processes which forces developers to review and probably adjust and upgrade their modules.DON'T hang on those people which still want to use versions lower 5.5 and their arguments. Qualified and Serious Developers keep their stuff up to date and use also hosting surroundings which would allow deploying a Processwire Version which uses only 5.5 and is no more backwards compatible to lower PHP Versions.
AND it will bring you more customers this is exactly what just happens since TYPO3 7.0 has been released. People like it so much that they like to switch even it has not all the modules which are working in right now. They like the new backend the new look and most of all they like the great speed increasement and SPEED is very important - I would say even more important than Keywords and all this other SEO stuff! And not seldom they also reduce the chance of vulnerabilities of your site!
 

Check your site with http://gtmetrix.com and think about some improvements - most of the Processwire sites we checked meanwhile could still have HUGE improvements! Check the Success Story sites! The values should be at least 95% each!

Concerning Speed and Optimization only a short example: (all done without Pro Cache and without AIOM - guess what it could be with them!)

start with:
http://gtmetrix.com/reports/processwire.com/ioLMvKpI (the demo site on processwire.com) - Pagespeed: 92% YSlow: 80% - 3.47s - 514kb - 49 requests

http://gtmetrix.com/reports/p11.thaipo3.com/WMmGEAD7 (the demo site on a server running Ubuntu 14.04 with PHP 5.5)
You can see here already a huge improvement - the core had been downloaded from git and the profile too!
http://gtmetrix.com/reports/p11.thaipo3.com/SP97JaY6 - Pagespeed: 98% YSlow: 98% - 0.79s - 198kb - 13 requests
(no Procache or AIOM or .htaccess improvement used until that point - only PHP 5.5 and proper server settings with proper caching! and use of freely available resources! i.e. cloudflare) simply by using proper server and caching settings and combining scripts and improving images but still place for further improvement!

In image optimization you can save a lot: Saved 761.5KB out of 15MB. 7.5% per file on average (up to 22.8%) - i.e. at the demo skyscraper site!
with the proper tools of course even installed and made on your server - for those on MAC ImageOptim is a good deal. https://imageoptim.com/

2. Security is very important criteria for customers, especially from bigger companies and smaller ones actually most likely follow the "wind" - which means as soon as they will pick up a vulnerability from whatever it is WordPress, TYPO3, Drupal, ... at least if it gets published they will use it and question if Processwire is weak and vulnerable too. What is said here about Microsoft is probably also valid for many other great systems http://secunia.com/vulnerability-review/vendor_update.html
The biggest enemy is the Third Party!

3. "In my opinion a module not being submitted to the modules directory is a sign of the author a) not knowing much of the ProcessWire environment / ecosystem (which can be a bad thing), b) not considering the module ready enough for the directory (in which case it definitely isn't ready for production use), or c) the author being too lazy or busy to submit the module (which means that the support will most likely be lacking too)."
Teppo well said - but have a look to reality and you will realize that many great modules are missing but they are working. Therefore another review process should be implemented. One would be to mark modules "alpha" "beta" "stable" "obsolete" instead and having the ability to review also an alpha or beta module.

4. Right now there are only a few modules which are easily to review by one person i.e. RYAN. But when Processwire will grow there probably will be 10 times as much modules and I guess RYANs main job won't be to review all those modules. Therefore I suggest in setting up a security team, to which module developers can submit there modules for review and of course those leaks which get discovered would get reported immediately.

5. Very important is IMHO Transparency! There should be a publishing process to make vulnerabilities public as soon as they had been discovered. If the security team is working successfully they usually would be able to send a fix right the way! Yes it has to be fast - very fast actually. Which means the security team needs to communicate with the module developer - take the module off for the time the vulnerability is existing - and publishing the warning so that everyone running a site with processwire and that specific module gets informed. A Dashboard which presents that information in the Processwire backend to the customer/user would help a lot, beside this secunia is a great resource. As an example here those from other CMSs:
http://typo3.org/news/security-bulletins/
https://www.drupal.org/security

Publish you Policy:
i.e.:
http://typo3.org/teams/security/extension-security-policy/
https://www.drupal.org/security-advisory-policy
and actually very good and even more important - The Security Team and review procedures:

https://www.drupal.org/node/1424708

and some education to learn from:
http://typo3.org/teams/security/resources/

6. Publish vulnerabilities on secunia: - Don't hesitate and show transparency! If Processwire is secure and gets fixed right the way there is absolutely nothing to hide.

http://secunia.com/community/advisories/report_vulnerability/

Please send an email to vuln@secunia.com to send us your research.

Information in your report should include:

• Affected operating system/software, including full version details
• How the vulnerability can be reproduced
• What impact the vulnerability has on the vulnerable system
• Any additional details that might help in the verification process

--

Check out:
http://secunia.com/community/advisories/search/?search=Processwire (0) - Probably because nobody is reporting vulnerabilities!
http://secunia.com/community/advisories/search/?search=modx (22) - Probably not many people are reporting or they have no one reviewing the code! no transparency

http://secunia.com/community/advisories/search/?search=typo3 (202)
http://secunia.com/community/advisories/search/?search=joomla (604)
http://secunia.com/community/advisories/search/?search=drupal (782)
http://secunia.com/community/advisories/search/?search=wordpress (1038)

most important is how fast actually those vulnerabilities get fixed and how the fix is available. Often in Joomla and Wordpress you will read "edit the source etc." In more mature CMS they will provide an updatedVersion to an extension or module right the way! Compare also how many vulnerabilities have not been fixed!!! - keep some ofthose infos for your "customers" they are good arguments for marketing your solution and preferred CMS!

We give our customers access to those resources mentioned above and it creates work as they want to keep their sites updated and secure! And most likely they can't do it themselves - they will realize this very fast! that this is an ongoing job which will never end!

8. Keep ALL modules also those in alpha, beta, stable and even idea state available in a centralized repository and developing space. The more people will be able to use those modules BEFORE they go into production the more testing will be done and the more feedback the developer will get, the better the module will be. This is very helpfull for developers if their modules are much easier to find and it also enables other developers to HELP and get interested. Beside that it is a nice place for checking which developers are having great coding style and which not. It would make reviews of code much much easier - and translations too.

i.e.
https://forge.typo3.org/
 

---

[pwired]

Good posting lisandi, didn't know about secunia, following those links now.

thanks.

[Pete]

The links are of mixed usefulness actually - the majority of the Wordpress ones are for plugins so not the fault of the Wordpress core or a useful comment on it's suitability as a system - just a highlight of buggy third-party modules (same with Joomla too). It would be better split out into core bugs (far fewer) and then alphabetic by plugin really so you can see it more clearly. They're actually pretty skewed results as Wordpress clearly has more plugins than any other system (1,425 in their plugin directory just for the search term "gallery") so has the most security issues listed as a result.

So I don't think it's fair to blame those numbers on the systems in question. Feel free to blame it on not assessing the plugins/modules and use it as a case when telling customers "yes, you could use Wordpress, but are you sure the plugins you are going to use are safe?". It's a bit of a minefield to say the least.

The reason zero security vulnerabilities have been reported in ProcessWire is because, at the moment, I am not aware of anyone finding any (anyone else?). There is nothing that ryan etc are hiding - it is just incredibly stable and the way the API abstracts things away from SQL queries removes one of the biggest pitfalls - no chance of SQL injections! The only things I have seen "fixed" over the years are a few bugs (not security related) and areas where performance has be increased.

I would definitely agree that anyone finding a vulnerability should report it - probably via the contact page is fine - so that there is time to fix it and issue a patch. I'm sure we would welcome that as well as them appearing on Secunia, but I don't think there are zero reported security issues on Secunia because nobody is bothering to report them - simply that nobody has found any yet to my knowledge. I am equally happy if someone finds a security issue or two and reports it in a responsible manner, but I'm being a "glass half full" guy rather than assuming a lack of transparency.

Could it be that ProcessWire is just incredibly well-written? I'd like to think so, but I am sure time will tell either way Certainly if the quality of modules continues and they go through a proper approval process then we can avoid some of those high numbers on the links above, but we will never get to those high numbers I think - I can't imagine a time when we would ever have 1,425 gallery modules even if ProcessWire grew to be more popular than Wordpress - there really must only be so many ways you can put together a gallery so there will never be as many modules (of any type) and therefore no real chance of having that high number of vulnerabilities. At least I hope not

[dazzyweb]

ooops Wordpress has done it again...actually yoast..

Yoast WordPress SEO Plugin Vulnerable To Hackers