xoops versus nuke

You know, I have read and played with both xoops and phpNuke. One is object oriented, thus the OOP in xOOPs and the other is just staight forward scripting. Nuke has come under some fire recently with security issues, in fact one of the premier Theme authors for Nuke was hacked and is completely rebuilding his site and as a result dropping Nuke. The problem for me is I am just starting to play with these portol systems within the last month and I have come to a crossroad. Choose one, and choose wisely.

I like Nuke because, well I just like the layout and I have never had problems getting it up and running with the bulletin board and modules. It's also easy to make my own heavily personalized theme, which is a desire. Xoop seems a little more difficult and less supported but is also very powerful. I was wondering if anyone is really using xoops to its potential and is it worth directing my path that way. This is a personal question because anything I do will be my own personal fun. Like I have said I spent hours reading documentation on each.

There was recently a discussion on php security here on the front page, so what are the personal feelings? Both are based on php to my understanding.

Thanks in advance.

Your right, php-nuke does have security issues, but so will anything if you don't give it the proper amount of attention. Nuke and your php install can be secured much better then how it comes out of the box.

If you do the following with your php install, you can be reasonable assured that nuke won't compromise the entire system. Edit your php.ini file and disable the following functions

disable_functions = shell_exec,proc_open,system,exec,passthru,phpinfo,show_source

You can disable more things like filesystem functions and such. open_basedir will also help with making sure php doesn't access anything outside of your webroot.

As far as your nuke installation goes, theres quite a few things you can do. For one, password protect the admin directory using .htaccess file. This will prevent the usage of admin features regardless of if they try to use an sql injection to one of the admin files. If you are the only admin, then you'll probably want to disable the ability to add new admins or authors. Simply commenting out those functions will do it there. In addition to disabling the ability to create new admins/authors, you can always create a cron job to delete any author or admin id greater then your own.

Sql injection opportunities still exist in the standard files, so going thru the different locations where user input is supplied and verifiying the data you are excepting can definately help you out there.

I know there's probably alot of people who would bash php-nuke, but those are the same people who don't do anything to secure it. We already know that sql injections can and do exist in many, many applications. So don't knock nuke just for that.

PHP-nuke is a great open-source application, very flexible. If you want to see a decent nuke install take a look at www.pureehosting.com . Built on nuke, heavily modified. I can't really speak on behalf of xoops other then to say that I'm sure it is afflicted by many of the same security issues, so I wouldn't make that the only basis for your decision.

Good luck what ever your choice.


--PuRe

Quote:

---

Originally posted here by PuReExcTacy
Your right, php-nuke does have security issues, but so will anything if you don't give it the proper amount of attention. Nuke and your php install can be secured much better then how it comes out of the box.

---

Actually, PHPNuke can be broken in many ways, and the ways you describe in your post are just plain wrong in their approach. You should not be disabling language tools to protect yourself against one poorly written PHP app.
This line sums up about the only way you can make PHPNuke secure:

Quote:

---

Built on nuke, heavily modified.

---

Use it as a base and go in and fix it yourself is probably not the best approach.

Quote:

---

I can't really speak on behalf of xoops other then to say that I'm sure it is afflicted by many of the same security issues, so I wouldn't make that the only basis for your decision.

---

If you haven't used it or just plain don't know, don't make baseless assumptions like the above. There are many similar apps to PHPNuke that aren't subject to the same idiotic vulnerabilities.

What it comes down to is the quality of the development. If you have a team of decent developers, you will end up with decent relatively bug-free software. If you have a team of half-witted cavemen who will represent the shallower end of the gene pool, you'll end up with buggy insecure steaming piles of code.
Certain projects represent the former, certain represent the latter. Feel free to come to your own conclusions on which is which.

I agree that any web based application can be broken and will be. It's a risk, that's why I wanted some personal comments. As stated a already lean to Nuke for one reason. It was my first portal system outside of MS and I dug into it deeply. It's personal but I also like Xoops. It was funny that the day I posted this there was an article here about the worm taking down PhPBB sites.

I was thinking of a way to get out of the Nukes (I used POSTNuke) several months ago and I found what I was looking for. Drupal. Personally I love to approach to how content is managed in Drupal, but there are some things that still irk me about the design. Overall it is much better than a loosely tied together system relying on (but never following) standardized communications to manage how each module individually uses the database (in under-checked code) to create multiple points of failure and functionality. Basically, how PHP/POSTNuke uses PHPBB for the forums, something else for an Image Gallery, something else for...you get the idea.


Anyways, onto disabling stuff in PHP. If you can't think of a valid reason those functions should be performed by your server, disable them. It won't break any functionality that you originally intended (good thing), and it could save your butt if something does go wrong (good thing). Until there is a fail-safe way to ensure the PHP preprocessor won't let your bullitenboard delete your website, you might as well keep the software under control in the case that something goes wrong. It isn't an excuse to deliberately allow for the error conditions (unchecked input, etc) to exist though.


Anyways, Drupal has made me happy since I moved over to it a couple of months ago. More centralized, the content is treated as any type of (standardized) content that can be catagorized into comments, news posts, blogs, forums, polls, etc. I don't use the built-in file/disk management because I don't like it. I also have issues with the access logs and how you currently can't keep a running daily total of hits. But overall it is slick and sweet and is easy to use after moving it to parse BBCode (which I usually change to not auto-link typed URLs). I didn't use Xoops, but you can't pull me away from my Drupal now :p

As far as I've been able to tell, all the ones I've analysed are as bad as each other.

PHPNuke is the worst, with an amount of security holes so large it would make the MSIE development team jealous.

The others aren't much better - they probably have an equal number of holes, but fewer are discovered because they're less ubiquitous.

These are IMMENSELY complicated applications, written, it seems, by non-programmers who don't know the first thing about secure code.

Sure, if you really want, set safe_mode on, disable any function that's remotely dangerous etc, but it won't stop that application being compromised, only escalation to a host compromise.

One useful thing about PHP is that you can set safe mode on a per-directory basis using Apache's php_admin_flag

Slarty

What do you use slarty?

Not sure about it's security track record, but a friend recommended E107 to me.
It can be found at: http://www.e107.org/news.php

I've used e107 a couple of times, and other than it being pretty slow (at least compared to phpBB for example), it's a pretty nice board.

Hmm e107 and drupel both look interesting. All the e107 sites I toured did seem very slow.

Quote:

---

Originally posted here by chsh
You should not be disabling language tools to protect yourself

---

Actually, language functions are like a service on an operating system, if you aren't going to be using it, disable the feature. It's just common sense security. Almost anyone will tell you the same. There's nothing better then writting safe code from the beginning, but disabling things you aren't going to use is just plain old covering you butt. From a security standpoint, it just makes sense.

Chsh, you've read and posted on the newer thread concerning how my prior action of disabling certain functions helped protect my site. http://www.antionline.com/showthread...031#post819031

Do you still stand the same words I quoted you on?


PuRe