Joomla! Discussion Forums

Joe FYI

Usually refers to SSH or any command line communication with the server....Similar to FTP but with the ability to execute commands like chmode as well.


Apache's Mod_Security is one example of this. I'm sure there are a few apache mods out there that will extend the system and do a more comprehensive check.


This is done similar to the way you protect CGI-BIN type folders (not sure if your familiar with that concept) Basically what you are doing is placing the file into a protected area where only the admin can write and place an alias (think of it like a shortcut) to the protected file in the root folder where Joomla can find it.

CGI is done like this to stop people from writing to the CGI-BIN folder and executing a script. in fact this might not be such a bad idea to explore protecting admin and any other folders that we would want to protect. Not as important in PHP as it is for perl and CGI though...

Thanks Mike
I am doing some investigation about those topics (might feed back what I find if it looks interesting and understandable).
My "question" though was more relateds to "user who doesn't have technical knwoledge about these topics" (instead of "I")..

IC Joe...

Part of the problem is that many users (those who rent specifically) won't have any control over any of that. Shell access yes but they won't be in a position to install mod_security (nor any other) unless they have dedicated or complete control of the server.

There are whole volumes of information on how to lock down a system properly but hardly any of it actually relates to Joomla and hardly any of it is easily done by the average user.

And the other issue is many ISP or Server farms don't have the skills either to set up their system properly...
Every company has their own way of doing things and sometimes don't have the money to hire a really good security specialist.
And many users are at the mercy of these underpaid and under qualified techs.

I'm considering another list, this one highlighting issues that Joomla! users should verify with their ISP. It could be categorized by Shared Server, Virtual Server, Dedicated Server. Again, no attempt to answer questions in depth, just identify the issues and point people toward resources. Would this be useful?

Yes, if it at the same time could highlight who uses what (like: shared server - personal sites / virtual -.. / dedicated -..), it would be usefull so each knows what can be applied to their situation. Great idea.

Which is why it is so often true that you get what you pay for when you chose a host (of course there are excepetions).

It is for this reason that I dislike seeing comments such as shared hosting can only be used for a site of type X. Generalisations like that  are not helpful. What is ore helpful is finding if the host as experience of hosting Joomla sites and then soliciting recommendations etc from existing customers.

I agree that avoiding statements with "only", "always", and "never" is almost "always" better. Best to just show relative advantages and disadvantages for various situations.

True Brian...very true!!

You know shared servers can also be configured in farms where each user is in the same system but there are 50 servers to deal with their traffic via throttling and cascading...

It really does depend on who it is your buying from...

I use Globix for most of my clients when they want never down performance and Globox can even give you localized peering...but you pay a price for that kind of service...

Won't get that kind of stuff at GoDaddy! LOL

Hi rliskey,



I think this is NOT secure. Normal browsers will close the connection and follow the redirection. However, if a cracker uses some other tool than a browser to access your site, the script will keep running and executes the rest of the code. If you really want the redirection, you need to do both: header() and exit afterwards.

Ah! Thanks friesengeist . Will update ASAP.

Thank you for the list. As far as I could, I have followed it (set all permissions to 644/755, use .htacess, edited globals.php). I'm on a VPS, made a clean install and asked the provider to set Safe mode to on and register globals to off (I can't access php.ini myself).

HOWEVER: I can no longer install any components, as the safe-mode restrictions forbid it. As I see very litle mention of this problem, I must be doing something wrong? (Of course I temporarily changed the permissions for the installtion)

Any pointers?

This is as it is. With safe mode=on, you can't install any new components. This will be solved in 1.5, where you can install through your FTP account and still have safe mode=on.

Are there any steps I can take so I can install via ftp now? Like is there a list of what the installer file does, including changes to the database?

I run 10+ sites and I don't want to be insecure, but I'm not ready to live with no installers!
Thanks.

I'd just run with safe mode=off for the moment. The register globals is a much more important setting.

Ok, I have sites on servers I run (admin) in my day job and setting up symlinks is no problem. But, on sites I have setup for myself on shared hosting accounts elsewhere without shell access (much less the permissions to set symlinks), where in the Joomla files can I find these "path variables". I did a quick search on the forum, maybe I should be looking in another area of the Joomla web site? Any pointers to the right post/page is appreciated!

I guess it's important to note that some ideas on the list are much less practical than others. It's left up to individual admins to decide which techniques make sense given their particular setup and security concerns.

Given Joomla!'s design, finding and modifying all path statements is currently a relatively impractical method. I left the idea on the list because I think being able to set more of these values within Joomla! admin is important.

Moving critical files outside of Web root is standard practice for most Web applications, and I hope someday it will be for Joomla! as well. For example, I can see no reason why the path to /media/ couldn't be configured in the same way as the path to /cache/ is. This technique is also used by the better download extensions, such as Gallery2 and DOCMan.

Hi,

I think:-

should read:-

magic_quotes_gpc = 0

Regards,
Chris.

Woops! Fixed magic_quotes_gpc.

http://forum.joomla.org/index.php/topic ... #msg456838 :



recommended setting:

magic_quotes_gpc ON  (like in joomla! 1.0.11 warnings).

should be changed in the security guide.

Rliskey -

Having "talked" to Beat, can we get these changes made to your AMAZING guide?

Change:


To:


Change:


To:


I have ALWAYS found that first description VERY confusing. Since the end user community is not writing the code, that comment is really not relevant to them. Most of them do not know how to review code to see if queries are properly escaped. So, they need "defense" which is ON or 1. The description should simply state that and point more geeky learners to the "real" source, IMO.

Thanks for considering.
Amy 

I understand the push for this setting to be on but I don't think it is in agreement with a good security and application models.  Those that could be considered the "experts" like Chris Shiflett, the author of Essential PHP Security (see: www.phpsecurity.org) say that magic_quotes_gpc should be Off because it is breaking the data access model.  At the top of which you should have your raw totally unmessed with data and inside the application you should have your nice safe sanitized data.  But, you have no idea what every piece of software will do with that data so it should be available in raw form somewhere but with magic_quotes_gpc = on that is impossible.  I don't like us encroaching on what other developers may do or have setup and as such I think we should let this one slide.  For Joomla itself it isn't necessary and any extension that uses the J! framework should be safe as well.  Not to mention when you get into UTF-8 support and multibyte characters this kind of escaping mechanism (addslashes) is useless because it doesn't function properly on multibyte characters.  This is a well known weakness.

Oh yeah, it is also being deprecated so we should get it right, this time.

I totally agree WHEN YOU CONSIDER Shiflett is talking to DEVELOPERS. They need to understand that the RIGHT way is to sanitize input before using it in a query. When the world is pretty with flowers like that, you would set that parameter off and let the developers take care of it.

We are in a much different world where we are literally installing code that has not necessarily been reviewed by our (I am talking about my - the end user community's) eyeballs. In cases where you canNOT ensure Shiflett's standards are complied with, that is EXACTLY what the magic quotes compensate for.

PERHAPS we can agree to this:

Set to OFF - IF - you know that all data input entered by strangers on your website (or a robot) has been processed just like the MasterChief says here < http://dev.joomla.org/component/option, ... ,33/p,158/ >. (His approach is the newer one, BTW, not deprecated.)

If you really have no idea what the developers did with the input --> heading for a query --> heading for your database, then --> for gosh sakes --> set the dang thing to ON for protection!

Yes? ... Amy  :)

Well, we make an application framework.  We have to consider what developers are going to do with it and how it is going to be used. 

Yea, I think I see what you are saying Rob. Sorry! 

So, if we do say turn it on, we are adding slashes that the application MIGHT NOT be ready for or be able to process. Is that what you are saying?

Beat - are you saying that this decision has already been reached and that the v 1.0.11 RECOMMENDS turning it on? If that is so, Rob, maybe the last thing to do is just to make the explanation easier for people to understand what the consequences might be. I don't think we change now, right? eek!

If you agree, Rob, then the guide should change this to 1:

magic_gpc_quotes = 1

But what should the description say so that NON-technical people can EASILY understand your point and make an intelligent decision?



What about going with the "official" quote - and you working with the devs on the future -- especially given MasterChief's model? What do you think? Why is Beat not sleeping, BTW? Beat - what do you think?

Well, I just had a great big glass of very good California wine (eat your heart out France), and although I truly enjoyed reading this thread, I have no idea how that item should be edited.

I guess/think/hope the core problem is that we would like to provide absolutely clear, (yes/no), (1/0) advise (in true dualistic, reactionary, fundamentalist form), but the issues are not that black and white (to use a terrible metaphor).

I read one post and want to change it to 1. I read other and want to change it to 0. How about we punt on this issue, and tell 'em to set the damned thing to 46, after all, doesn't that explain everything in the Universe? Job done!

BTW: Amy: I love your posts! 

Do you mean the conversations I have with three people where no one else talks? lol....

Sincerely:

If the core has decided the answer (and this is not an easy question, I agree with Rob NOW) then: We have to go with it and document it easily.

If there are legitimate options, 0, 1 or 46, then, in layman's terms, what are we asking people to choose?

I understand Beat to be saying that the core and Rey/the dev's have gone with on - or 1 - and we should probably go with the official response:


Rob's call. (OK, I'll let you talk, Rob! After all, you are fun.)
me

Hi Rob,

You have some good points there to be discussed for Joomla 1.5 with UTF-8 support and a great new J! framework.

But for Joomla 1.0 and joomla 3pd components, I'm sure (talked with other core and WG members):

magic_quotes_gpc = 1

is way safer against SQL injections on Joomla 1.0 production servers (it even indeed protects from a lot of mistakes).

Thus developpers should indeed develop with setting 0 (so they see their mistakes) and test it also workd with setting 1 (so they check it works same and generates same outputs to database and html.

Talking about the J! 1.0 Framework: take a look at mosGetParam() : the most important thing it does is to check if magic_quotes_gpc is not set to 1, and in that case where it was OFF, to emulate that setting to be ON with adding slashes : the main use of mosGetParam() is that after using it you are sure to have an escaped string (obviously there are cases where you need to unescape them)

in includes/joomla.php:


Means the J! 1.0 Framework is escaping it allways (last time i checked 1.5 a few weeks back, it did same).

What magic_quotes_gpc=1 ensures is that variables not passed through mosGetParam() by ommission (all should be passed through there, right...) are also escaped, so that if they get used in SQL requests, they don't lead to SQL injection vulnerabilities.

You absolutely right that data-coherency needs to be kept, and double-escapings avoided in databases, to not break search functions. But well written code takes care of this whatever the magic_quotes are. Another very nice and clean implementation is the mosDbTable class. UTF-8 settings are also taken care correctly of in magic_quotes if in recent releases of php, php settings are correct. And these days, it's better to be up-to-date



rliskey,

LOL about your last post. 46 seems a little low, i would recommend a higher, rounded value between 0 and 1. 

It's really 1 which is way safer for production sites with Joomla 1.0 extensions (and also for previous versions of joomla btw). i've a list of vulnerabilities and proofs of exploits with it at 0...but will not publish it here. You can take a look at the 1.0.11 changelog: you are protected from most if not all the "potential injection vulnerabilites" of 1.0.10 by the magic_quotes_gpc=1 setting.

Amy has a very good post. Would really be great to interlink or merge somehow (by making them both shorter LOL) the two excellent guides into a new security chapter for Joomla.



Well, ladies and gentlemen, 3:00 am here, no need for a whisky to get asleep  , magic quote stories are all it needs. 

I don't mean to beat (no pun intended) a dead horse here but there is a difference between Joomla emulating the behavior of magic_quotes_gpc and it actually being on.  It goes back to the ability to access the raw data.  With magic_quotes off you can access totally unmessed with data but you get cleaner data automatically assuming you are using mosGetParam() because Joomla! emulates the behavior of magic_quotes_gpc.  On the other hand, with magic_quotes_gpc on you can never get to the pure unescaped data because PHP escapes it automatically.  I know that I am being very pedantic about this but I think it is an important note. 

BTW, I am not saying that we should change it... magic_quotes_gpc on for 1.0.x is fine but I don't think this is a behavior or mentality that we should carry into 1.5.  I am just trying to give the explanations why this should not be carried over now to get things like this on peoples mind because these security check type features are going to come up again and it is better that we talk about them and get used to the different positions and philosophies toward their settings as soon as possible before we have to make a real decision that will affect the rest of the life of Joomla. (I really didn't mean to sound too dramatic there, it is just the way it came out).

I also think recommending it to be off does a few things for us that work in our favor, such as, expecting higher standards of code from extension developers, weeding out the extensions/developers that refuse to or are unable to meet that standard because their extensions will repeatedly have security issues, it will also make joomla more forward compatible as magic_quotes_gpc is going away.  I think all of those are good things and we should keep them in mind when considering decisions like this one. 

I think I will leave it at that, both sides have presented their arguments very well and I think we have all gotten our points across.