PHP "security" issues on hosts

hansBKK <aww01.100.hansbkk.RemoveThis@spamgourmet.com> wrote in news:euflgk$u5l$1
@aioe.org:

> OK I'll try this a different way - do please let me know if there's a
> more appropriate group (re website hosting) to post this to!

comp.lang.php would be most appropriate, but AWW does have a lot of
knowledgeable PHP types.

> I want to identify which hosts will give me the most flexibility; as a
> user I don't want to find there are popular/important scripts out there
> I can't use with my account. But I still want decent security - am I
> dreaming or is that possible?

If it is a big deal to you that you be able to greatly modify your system's
gonfiguration, then perhaps something like a VPS is in order.

Shared hosts will typically be the most restrictive in terms of things like
safe_mode, allow_url_fopen, and stuff like that. I don't find that there's
any "universal" set of configuration settings though, so you're better off
finding out what *you* actually need before searching for hosts.


> Out of the following variables (and others you might think of), are
> there any which I should NOT expect to be able to change via
> .htaccess/php.ini?

The short answer is that if you can even get to your php.ini, then you can
expect to be able to change it.
There are only a limited number of things that can be changed with
..htaccess or ini_set
http://www.php.net/ini_set





--
Karl Groves
http://www.thehotrodclassifieds.com
 >> Stay informed about: PHP "security" issues on hosts 

Erwin Moller wrote:
> A solid understanding of the OS and the language and its settings is what
> matters here.

Thanks, and I fully intend to learn as much as I can as quickly as I can.

But right now I need to choose a host, and I'm trying to figure out how
to differentiate between the different ways they have PHP configured -
and there IS a wide range.

I guess I have to say at this point, non-production system, I'd rather
have more flexibility, and I'm willing to sacrifice some security - I
don't even know what SQL injection is. . .

I guess my question is which approach to PHP security is least likely to
prevent me from running the most popular scripts?

Do I need to make a big list of all the apps I want to evaluate,
look at the installation pre-requisites and make up a master checklist
to compare all the hosting services I'm considering?

I certainly don't want to have to switch hosters every time I run into a
conflict with how each one runs PHP. . .

x runs as a module, no safe mode.
y runs as CGI with phpsuexec.

So for just this variable, am I better off with x?

Of course I don't have access to the "master" PHP nor httpd.conf (and
no, I'm not willing to rent a VPS just to get that!).
 >> Stay informed about: PHP "security" issues on hosts 

Sorry if I'm repeating myself, at first this post didn't show up on my
news server until long after it did in Google.

> comp.lang.php would be most appropriate, but AWW does have a lot of
> knowledgeable PHP types.

Thanks for the pointer

> If it is a big deal to you that you be able to greatly modify your
> system's gonfiguration, then perhaps something like a VPS is in order.

Actually, I'd love not to have to change a thing! But if host x doesn't
even allow me to have a custom php.ini/.htaccess and host y does, then
shouldn't I prefer y for the flexibility?

Right now I'm just playing, I think VPS would be overkill - plus I have
no clue about Linux/Apache serveradmin.
>
> Shared hosts will typically be the most restrictive in terms of things
> like safe_mode, allow_url_fopen, and stuff like that. I don't find
> that there's any "universal" set of configuration settings though, so
> you're better off finding out what *you* actually need before
> searching for hosts.

in fact there's a LOT of variability, but the problem is I have no idea
what scripts I'm going to ultimately choose - what I'm after is
flexibility

> There are only a limited number of things that can be changed with
> .htaccess or ini_set
> http://www.php.net/ini_set

That's very useful, thanks!

But my question remains - let's assume I want a host that allows for
maximum flexibility in using a wide range of canned scripts. Are any of
these setting valuable for security and don't break scripts?

Say I found a few hosts that ran as a module, no safe mode, allowed
custom .htaccess. Do I want the one that has open_basedir ON or OFF?

Or if running as a module is just plain stupid from a security POV,
should PHP be running with suphp or phpsuexec? SUhosin or suExec?

Or are these factors just not that much of an issue with mainstream
apps, am I just "thinking too much" here?
 >> Stay informed about: PHP "security" issues on hosts 

hansBKK <aww01.100.hansbkk.TakeThisOut@spamgourmet.com> wrote in
news:Xns9902D60BBB370hansbkk@194.177.96.26:


>> If it is a big deal to you that you be able to greatly modify your
>> system's gonfiguration, then perhaps something like a VPS is in order.
>
> Actually, I'd love not to have to change a thing! But if host x doesn't
> even allow me to have a custom php.ini/.htaccess and host y does, then
> shouldn't I prefer y for the flexibility?

Not unles you need the flexibility. I know it sounds repetitious of me to
say that, but its true. If you don't need the flexibility, why would it be
of concern for you?

Let's use a different example: I see hosts all the time who advertise
"Unlimited POP3s". Who cares? I mean, do you really need *unlimited* e-
mail addresses? I have 25 sites hosted on my VPS. The highest number of e-
mail addresses on any of the sites I host is 8. So who cares if it is
"unlimited" (which is a farce anyway, but that's another discussion).


> Right now I'm just playing, I think VPS would be overkill - plus I have
> no clue about Linux/Apache serveradmin.

You don't really need to.
I use www.powervps.com
They provide CPanel/WHM which should be enough for anything you need.
When it comes to custom stuff with php.ini, I have access to it and can
modify it as I see fit. In reality, I haven't really needed to except for
2 modifications: 1) Pointing to my browsecap.ini file and 2) modifying the
upload_max_filesize which was set to the default of 2M

>>
>> Shared hosts will typically be the most restrictive in terms of things
>> like safe_mode, allow_url_fopen, and stuff like that. I don't find
>> that there's any "universal" set of configuration settings though, so
>> you're better off finding out what *you* actually need before
>> searching for hosts.
>
> in fact there's a LOT of variability, but the problem is I have no idea
> what scripts I'm going to ultimately choose - what I'm after is
> flexibility
>
>> There are only a limited number of things that can be changed with
>> .htaccess or ini_set
>> http://www.php.net/ini_set
>
> That's very useful, thanks!
>
> But my question remains - let's assume I want a host that allows for
> maximum flexibility in using a wide range of canned scripts. Are any of
> these setting valuable for security and don't break scripts?
>
> Say I found a few hosts that ran as a module, no safe mode, allowed
> custom .htaccess. Do I want the one that has open_basedir ON or OFF?
>
> Or if running as a module is just plain stupid from a security POV,
> should PHP be running with suphp or phpsuexec? SUhosin or suExec?
>
> Or are these factors just not that much of an issue with mainstream
> apps, am I just "thinking too much" here?
>

These are probably questions you'll find a quicker answer to in
comp.lang.php

Generally speaking, a lot of the restrictions you're bound to run into will
be settings meant to keep things secure. An insecure PHP app is not just a
risk to you but may be a risk to other sites if you're in a shared
environment. This is especially true when it comes to safe_mode and
open_basedir. (Although safe_mode is going away in PHP 6.0.0)




--
Karl Groves
http://www.thehotrodclassifieds.com
http://www.grayscalecms.com
http://www.karlcore.com
 >> Stay informed about: PHP "security" issues on hosts 

On Mar 29, 1:18 am, hansBKK <aww01.100.hans... RemoveThis @spamgourmet.com> wrote:
> OK I'll try this a different way - do please let me know if there's a
> more appropriate group (re website hosting) to post this to!
>
> I'm just starting to learn PHP, but probably will be using 90% pre-coded
> applications - CMS, forums, mailing management. I'm looking for a good
> hosting company; I've got my "shortlist" list down to a dozen or so good
> ones with excellent reputations for reliability and support.
>
> I want to identify which hosts will give me the most flexibility; as a
> user I don't want to find there are popular/important scripts out there
> I can't use with my account. But I still want decent security - am I
> dreaming or is that possible?
>
> So (finally) the question: what configuration/style of running PHP
> should I be looking for in a hoster?
>
> Please forgive if my questions reveal my ignorance, and I'd be ever so
> grateful if you could help explain things to me.
>
> Safe mode should be OFF, correct?
>
> Should PHP be running as a module or CGI? If CGI, please rank these from
> best to worst: SUhosin, suExec, suphp, phpsuexec?
>
> Is it usual/OK for these disable_functions to be set: shell, exec,
> passthru - others I should watch out for?
>
> Out of the following variables (and others you might think of), are
> there any which I should NOT expect to be able to change via
> .htaccess/php.ini?
>
> open_basedir
> register_globals
> memory_limit
> magic_quotes
> file_uploads
> upload_tmp_dir
> upload_max_filesize
>
> Thanks in advance for your help!

In terms of hosts that offer PHP configuration flexibility, I would go
with either Bluehost or Jumpline. I love Blue host because you get
COMPLETE control over php.ini and can give certain subdirectories
customized php.ini definitions. They can also set you up on a PHP 4
or 5 box, whatever you prefer. Jumpline is cool because they offer
php5 and mysql5 as a nice package. You can alter the php.ini files as
well.

As for "security", that such a complicated subject that no one, two,
or three strategies will suffice. Its an ongoing battle. But you
need to know how your software handles many forms of user input, how
you plan to sanitize user input, how you plan to catch runtime errors,
and so on. There really isn't a magic formula.
 >> Stay informed about: PHP "security" issues on hosts 

Karl Groves <karl DeleteThis @NOSPAMkarlcore.com> wrote in
news:Xns990268AD0A71Fkarlkarlcorecom@199.45.49.11:
>> Actually, I'd love not to have to change a thing! But if host x
>> doesn't even allow me to have a custom php.ini/.htaccess and host y
>> does, then shouldn't I prefer y for the flexibility?
>
> Not unles you need the flexibility. I know it sounds repetitious of me
> to say that, but its true. If you don't need the flexibility, why
> would it be of concern for you?

But I do need the flexibility, given by the fact that I have only just
begun to check out what scripts I might want to use.

>> Right now I'm just playing, I think VPS would be overkill - plus I
>> have no clue about Linux/Apache serveradmin.
>
> You don't really need to.
> I use www.powervps.com
> They provide CPanel/WHM which should be enough for anything you need.

Thanks for the pointer, when I'm actually putting something into production
I'll then consider a VPS.


> Generally speaking, a lot of the restrictions you're bound to run into
> will be settings meant to keep things secure. An insecure PHP app is
> not just a risk to you but may be a risk to other sites if you're in a
> shared environment. This is especially true when it comes to safe_mode
> and open_basedir. (Although safe_mode is going away in PHP 6.0.0)

Seems to be a consensus among the php crowd that safe_mode is an abortion,
so I'll be avoiding those hosts.

> These are probably questions you'll find a quicker answer to in
> comp.lang.php

I'll do further research there, thanks for your help.
 >> Stay informed about: PHP "security" issues on hosts 

In <euflgk$u5l$1@aioe.org>,
hansBKK <aww01.100.hansbkk RemoveThis @spamgourmet.com> mentions:
>I'm just starting to learn PHP, but probably will be using 90% pre-coded
>applications - CMS, forums, mailing management. I'm looking for a good
>hosting company; I've got my "shortlist" list down to a dozen or so good
>ones with excellent reputations for reliability and support.
>
>I want to identify which hosts will give me the most flexibility; as a
>user I don't want to find there are popular/important scripts out there
>I can't use with my account. But I still want decent security - am I
>dreaming or is that possible?

It's mostly impossible with PHP.

While PHP itself is quite portable, it has "settings" (some can be
changed, others can't) this basically means every installation of
PHP is slightly different on each host. PHP itself is portable, php
scripts are not. (even on the same OS!)

The only way to get maximum flexibility (with php) is to find a provider that
allows you to access every feature of the PHP binary (including the compile
time flags and access to the libraries used by the PHP binary)

Having said that, if you're learning PHP there is a fair chance you'll
be able to tweak portions of some applications where a conflict occurs.
(for example, if the posix functions are disabled, you might write a fix
to get around whatever it was the posix functions were used for)

>So (finally) the question: what configuration/style of running PHP
>should I be looking for in a hoster?

One that you have absolute control of. (VPS or some sort of jailed environment
are examples, make sure you can access it via ssh and have a compiler)

>Safe mode should be OFF, correct?
>
>Should PHP be running as a module or CGI? If CGI, please rank these from
>best to worst: SUhosin, suExec, suphp, phpsuexec?

Far as I know, CGI is fairly good option when you have two scripts and
each of them need different PHP settings/compile flags. I've seen ISP's
support PHP5 side by side with PHP4 this way.

>Is it usual/OK for these disable_functions to be set: shell, exec,
>passthru - others I should watch out for?

PHP is a funny language that way, it seems to have been written in a way
that attempts to prevent insecure code. I suppose an ISP might see this
as a "good thing".

This is a rather backwards approach to security, the only way to code an
application securely is to write it secure in the first place, or, using
java as an example, design a sandbox model.

The trouble with a sandbox is that you won't be able to really do anything.
(and, php really doesn't do a sandbox, for example, there isn't a "security
manager" that you can grant selective permissions with)

Secure programming takes a bit of thought. No amount of language features can
address it, (FWIW, I think perl's "taint checking" can be a handy
lint style checker, it's still no silver bullet)

It's like driving, seatbelts won't prevent you from getting into
an accident.

Jamie
--
http://www.geniegate.com Custom web programming
Perl * Java * UNIX User Management Solutions
 >> Stay informed about: PHP "security" issues on hosts 

"chrisv" <nickadeemus2002 RemoveThis @gmail.com> wrote in
news:1175223862.302273.123320@d57g2000hsg.googlegroups.com:
> As for "security", that such a complicated subject that no one, two,
> or three strategies will suffice. Its an ongoing battle. But you
> need to know how your software handles many forms of user input, how
> you plan to sanitize user input, how you plan to catch runtime errors,
> and so on. There really isn't a magic formula.

I feel like I'm not being heard here:

*** I'm not concerned about security at this point ***

I'm just trying to figure out how to select a hosting service where the
environment will allow me to install just about any script and run it,
without my having to do troubleshooting or tweaking code. Or at least a
bare minimum.

One day I'll have a clue about "sanitizing user input" etc. but right
now I just want to install WordPress with a bunch of plug-ins and have
it work, check out Drupal and Joomla and Xoops and figure out which one
I want to get into learning, without banging my head against a wall (my
hosting environment) to get it to work.

I don't mind choosing a host that has a given security measure in place,
as long as that given option a) doesn't usually break scripts or b) I
can enable/disable the option in my own .htaccess or php.ini.

My problem is I don't understand the various options well enough to ask
the right questions. *** That's *** what I'm asking for help here on.

Lectures about why I should care about security, or tips on how to make
sure my environment is secure - those opinions are ** OT ** OK?

(whew, sorry about that, got it off my chest, I'm OK now <g>)

So, I'll try again:

I've already decided I'll avoid hosts that are running in safe mode.

I'm still on the fence about module vs CGI, but say I found a few good
hosts that ran as a module, no safe mode, allowed full custom .htaccess
options. Do I want the one that has open_basedir ON or OFF?

No one's addressed this yet:

> If CGI, please rank these from best to worst: SUhosin, suExec, suphp,
> phpsuexec?

> Is it usual/OK for these disable_functions to be set:
> shell, exec, passthru, eval and system

In other words - should I choose an environment where (any of/which
of)these are disabled? Or should I look for a host where these are all
left open.

I want to be able to switch magic_quotes and register_globals on/off,
right?

There are four specific questions there, I'd REALLY appreciate it if
someone could specifically address these. And thanks to all for your
patience with a peevish newbie <g>
 >> Stay informed about: PHP "security" issues on hosts 

nospam.RemoveThis@geniegate.com (Jamie) wrote in
news:Lc1175365480148230x8bacf5c@pong.podro.com:

> It's mostly impossible with PHP.
>
> While PHP itself is quite portable, it has "settings" (some can be
> changed, others can't) this basically means every installation of
> PHP is slightly different on each host. PHP itself is portable, php
> scripts are not. (even on the same OS!)

I've had people tell me well-written ones are, but I'm starting to
imagine they are the exception rather than the rule.

> The only way to get maximum flexibility (with php) is to find a
> provider that allows you to access every feature of the PHP binary
> (including the compile time flags and access to the libraries used by
> the PHP binary)

I haven't found that yet in a shared environment, and can't afford a VPS
to just play with canned scripts.

> Having said that, if you're learning PHP there is a fair chance you'll
> be able to tweak portions of some applications where a conflict
> occurs. (for example, if the posix functions are disabled, you might
> write a fix to get around whatever it was the posix functions were
> used for)

This is exactly what I'd like to avoid for this stage of my learning
process, I just want to install them and use them for now.

>>So (finally) the question: what configuration/style of running PHP
>>should I be looking for in a hoster?
>
> One that you have absolute control of. (VPS or some sort of jailed
> environment are examples, make sure you can access it via ssh and have
> a compiler)

Too pricey for me!

> Far as I know, CGI is fairly good option when you have two scripts and
> each of them need different PHP settings/compile flags. I've seen
> ISP's support PHP5 side by side with PHP4 this way.

Interesting, CGI being more flexible, I haven't come across that POV
yet. The three hosts on my lists that have dual version support are
running v4 as a module, 5 as CGI.

>>Is it usual/OK for these disable_functions to be set: shell, exec,
>>passthru - others I should watch out for?

I didn't see an answer to this, and by now can expand the question:
shell, exec, passthru, eval and system

Are these OK or not, from my user-not-concerned-about-security POV?

All of the below goes right over my head and seems to be based on the
assumption that I'm concerned about security at the moment, which I'm
not.

But thanks for replying Jamie, my understanding's growing (baby steps!)


> PHP is a funny language that way, it seems to have been written in a
> way that attempts to prevent insecure code. I suppose an ISP might see
> this as a "good thing".
>
> This is a rather backwards approach to security, the only way to code
> an application securely is to write it secure in the first place, or,
> using java as an example, design a sandbox model.
>
> The trouble with a sandbox is that you won't be able to really do
> anything. (and, php really doesn't do a sandbox, for example, there
> isn't a "security manager" that you can grant selective permissions
> with)
>
> Secure programming takes a bit of thought. No amount of language
> features can address it, (FWIW, I think perl's "taint checking" can be
> a handy lint style checker, it's still no silver bullet)
>
> It's like driving, seatbelts won't prevent you from getting into
> an accident.
>
> Jamie
 >> Stay informed about: PHP "security" issues on hosts 

On 2 Apr, 13:04, nos....TakeThisOut@geniegate.com (Jamie) wrote:

> For example, if I saw a PHP script attempt to parse an XML document w/out
> relying on PHP's optional xml support.. I'd run. That would not be a well
> written script.

I assume what you mean is that script authors shouldn't write XML
parsers, in whcih case I'd agree with you.

OTOH, why should the _PHP_authors_ write yet another XML parser?
That's not an appropriate thing for them to have stuck into that
bloated swiss-army-knife of a language (my apologies to Victorinox and
Wenger for the comparison). What's wrong with Xalan, Xerces et al?
There's no need to keep re-inventing this stuff, there's no need to
add it to the core language, and there's certainly no need to keep re-
doing things badly, inefficiently and insecurely.
 >> Stay informed about: PHP "security" issues on hosts 

OK Jamie, thanks for your well-considered reply

> For example, if I saw a PHP script attempt to parse an XML document
> w/out relying on PHP's optional xml support.. I'd run. That would not
> be a well written script.

I guess they meant well-written in the sense that they could handle
things like module vs. cgi, globals or safe mode being on or off etc.

> If you're just playing around, you might want to consider putting them
> on a personal machine. Get yourself a linux distribution that maybe
> runs in vmware or something and take it from there.

I've got XAMPP on my windoze box for playing, but my life is complicated
enough without having to learn vmware and linux as well right now <g>

> Ah, you're learning how to install them! I was under the impression
> you were trying to learn PHP.

I plan to learn to code php here and there as I have time - I've already
written a mailform script (and then decided to use one of the more
secure ones available online). My job is to manage a web site and I
currently only do static html, so I want to check out cms, wordpress,
maybe set up a forum.

Once I feel comfortable enough with it, I'll want to put it into
production on my company's site, and at that point I'd be concerned
about security.

> The trouble is, you can't have two identical modules installed on
> apache (at least, as far as I know) one way around this is via CGI,
> the other way is via some sort of proxy arrangement.

So if php 4 is running as a module and 5 is cgi, then maybe I'd use a
more open v4 environment for playing/testing, and then migrate to cgi
mode before putting it into production?

> Security is in the php script/application itself. All the shell-exec,
> passthru stuff is irrelevant. You'll always want them enabled, if they
> aren't, some PHP scripts may not function.

Excellent, thanks for a clear answer. I'll look for hosts that don't
disable any of these.
 >> Stay informed about: PHP "security" issues on hosts 

In <1175609511.331912.111950 RemoveThis @p77g2000hsh.googlegroups.com>,
"Andy Dingley" <dingbat RemoveThis @codesmiths.com> mentions:
>On 2 Apr, 13:04, nos... RemoveThis @geniegate.com (Jamie) wrote:
>
>> For example, if I saw a PHP script attempt to parse an XML document w/out
>> relying on PHP's optional xml support.. I'd run. That would not be a well
>> written script.
>
>I assume what you mean is that script authors shouldn't write XML
>parsers, in whcih case I'd agree with you.
>
>OTOH, why should the _PHP_authors_ write yet another XML parser?
>That's not an appropriate thing for them to have stuck into that
>bloated swiss-army-knife of a language (my apologies to Victorinox and
>Wenger for the comparison). What's wrong with Xalan, Xerces et al?
>There's no need to keep re-inventing this stuff, there's no need to
>add it to the core language, and there's certainly no need to keep re-
>doing things badly, inefficiently and insecurely.

That's kind of what I meant, if a PHP script attempted to overcome
a php binary that was compiled w/out XML support by parsing the XML
themselves... I'd run.

As I understand it, folks are working in this.. but.. from what I've
seen, PHP is a monolithic sort of thing, everything has to be compiled
in. I know there is some means of installing a DLL/so, but.. I've never
seen it actually work, certainly not as a normal user. (I can understand
why, particularly in mod_php, but.. it's still an issue)

Jamie
--
http://www.geniegate.com Custom web programming
Perl * Java * UNIX User Management Solutions
 >> Stay informed about: PHP "security" issues on hosts 

ol'softy <contact_info.RemoveThis@sig_line.clickit> wrote in
news:tm7813ljthqlgm02nf646u0f9d713olhjo@4ax.com:

>>So (finally) the question: what configuration/style of running PHP
>>should I be looking for in a hoster?
>
> You should not, in my opinion; that is not how I think a hosting
> service should be chosen. In my opinion your primary consideration
> should be reliability and speed, and for those you probably do need to
<snip>
> hosting). Your second consideration should be support -- can you

From my OP
>>I've got my "shortlist" list down to a dozen or so good ones with
excellent reputations for reliability and support.
And price is a <5% significant factor, speed to be confirmed

So right now I'm focussing on the PHP variables. . .

> You're going to find that there are basically three different types of
> server that hosting services offer. The cheapest and most common is
> the shared server. With a shared server, you're probably better off

I'm definitely going with shared for this stage, and many on my shortlist
have safe mode off, so I reckon that's best

> Figuring out what you need is nontrivial.

No kidding <g>


>>Should PHP be running as a module or CGI? If CGI, please rank these from
>>best to worst: SUhosin, suExec, suphp, phpsuexec?
>>
>>Is it usual/OK for these disable_functions to be set: shell, exec,
>>passthru - others I should watch out for?
>>
>>Out of the following variables (and others you might think of), are
>>there any which I should NOT expect to be able to change via
>>.htaccess/php.ini?
>>
>> open_basedir
>> register_globals
>> memory_limit
>> magic_quotes
>> file_uploads
>> upload_tmp_dir
>> upload_max_filesize
>>
>>Thanks in advance for your help!
>
> Questions like the above are questions you ought to be able to ask
> your hosting support person. They'll know where and how they've
> tweaked their Linux installation if it's Linux and they've tweaked it,

What I'm doing *here* is trying to figure out what pre-sales questions are
most important to ask the hosts on my shortlist. If e.g open_basedir being
on is usually not something that breaks mainstream scripts, then I won't
worry about whether its switchable by .htaccess or not. But apparently
register_globals and magic_quotes should be switchable, as I've seen people
complaining about their applications breaking when the host changed the
setting without warning.

Like that.


> Most of it boils down to time and money, in whatever your situation is

I've got enough of both, but my time on this planet is fixed - easy enough
to make more money <g>

> Here's a suggestion. I don't host with godaddy but I've heard it
> rumored that you can actually get hold of someone at tech support

All of the hosters in my short list have stellar reputations for excellent
support, and at the current stage of my research I've been amazed at their
responsiveness. At more than half of them I'm dealing directly with the
owner, and 90% of the time when I send a list of a dozen or more detailed
tech questions, I get a response back within a couple of hours - often
within ten minutes, even at 3am.

The challenge is weeding them down, and identifying the key things to look
for to give me maximum flexibility for now is what I'm looking for here.

The nice thing about flexibility is that I can always tighten up the
security settings myself once I've decided to use a particular script in
production mode.

I wouldn't touch a huge overselling hosting service like godaddy, but
that's just me, some people think hosting with a company where the owner's
actually hands-on with customers is a bad thing!
 >> Stay informed about: PHP "security" issues on hosts