Policy on Web Applications

[David Johnson]

Where can I find information on web application policy for Debian? We are
deploying a web based application on Debian that uses PHP and Apache.



Thanks in advance!



--

David

[Alexis Sukrieh]

Post by David Johnson
Where can I find information on web application policy for Debian? We are
deploying a web based application on Debian that uses PHP and Apache.

The webapps policy is not yet finished, we only have a draft. You can
read it, it contains best practices even if not complete.

http://webapps-common.alioth.debian.org/draft/html/

Regards,
--
Alexis Sukrieh <***@sukria.net>
0x1EE5DD34
Debian http://www.debian.org
Backup Manager http://www.backup-manager.org

[David Johnson]

Excellent! Thank you!

-----Original Message-----
Sent: Tuesday, February 28, 2006 9:15 AM
Subject: Re: Policy on Web Applications

Post by David Johnson
Where can I find information on web application policy for Debian? We

are

Post by David Johnson
deploying a web based application on Debian that uses PHP and Apache.

The webapps policy is not yet finished, we only have a draft. You can
read it, it contains best practices even if not complete.
http://webapps-common.alioth.debian.org/draft/html/
Regards,
--
0x1EE5DD34
Debian http://www.debian.org
Backup Manager http://www.backup-manager.org
--
with a subject of "unsubscribe". Trouble? Contact

[David Johnson]

The policy document looks great and carefully thought out. We have not
finished our package development and released it yet, so we're not certain.
One question is in regards to PHP configuration. For example our
application requires "register_global" to be turned on in PHP (which has
sufficient security structure in place where this is not a problem for us).
What approach should we take here?

[Thijs Kinkhorst]

Post by David Johnson
The policy document looks great and carefully thought out. We have not
finished our package development and released it yet, so we're not certain.
One question is in regards to PHP configuration. For example our
application requires "register_global" to be turned on in PHP (which has
sufficient security structure in place where this is not a problem for us).
What approach should we take here?

There are ways to turn register_globals off for specific paths or
locations on your webserver, at least in Apache. You could advise the
users of your package to do that, and be sure to mention that they
should not turn it on site-wide.

I'm wondering however why your application requires it; I see no need
for any modern application to use that setting since there are good
alternatives available that are safe by design.


bye,
Thijs

[David Johnson]

When we developed our application we did not know that in PHP it was
possible to turn off register_globals. It was obvious to us that while
advantageous for quick development, globals were a big security issue, so we
designed our entire app using classes, and explicity stating where we want
to use globals and verifying them accordingly.

We could re-code to not use globals, but we're focusing our recoding in
other technologies instead of PHP.

I did not know we could turn on PHP global in an Apache virtual host
directive. This is great for this version of the package. Thanks for the
feedback.

[Gareth Ardron]

Post by David Johnson
The policy document looks great and carefully thought out. We have not
finished our package development and released it yet, so we're not certain.
One question is in regards to PHP configuration. For example our
application requires "register_global" to be turned on in PHP (which has
sufficient security structure in place where this is not a problem for us).
What approach should we take here?

I'd suggest probably:
php_value register_globals = "On"

in the apache virtualhost config, because the last thing that wants to
happen is for security issues with other apps to be created/exposed by a
global change to php.ini.

[sean finney]

hi david,

Post by David Johnson
The policy document looks great and carefully thought out. We have not
finished our package development and released it yet, so we're not certain.
One question is in regards to PHP configuration. For example our
application requires "register_global" to be turned on in PHP (which has
sufficient security structure in place where this is not a problem for us).
What approach should we take here?

i agree with gareth's suggestion that you make sure that your settings
are how you need them by overriding them "locally" (in a <Directory> block
or in the application itself).


sean