<?xml version="1.0" encoding="utf-8"?>

<chapter xml:id="security.apache" xmlns="http://docbook.org/ns/docbook">

<title>Instalado como módulo de Apache</title>

<simpara>

Cuando <acronym>PHP</acronym> es usado como un módulo de Apache, hereda los

permisos del usuario de Apache (generalmente los del usuario

"nobody"). Este hecho representa varios impactos sobre la

seguridad y las autorizaciones. Por ejemplo, si se está usando

<acronym>PHP</acronym> para acceder a una base de datos, a menos que tal base de

datos disponga de un control de acceso propio, se tendrá

que hacer que la base de datos sea asequible por el usuario

"nobody". Esto quiere decir que un script malicioso podría

tener acceso y modificar la base de datos, incluso sin un nombre

de usuario y contraseña. Es completamente posible que una

araña web (bot) pudiera toparse con la página web de administración de

una base de datos, y eliminar todo de la base de datos. Una

protección ante este tipo de situaciones es mediante el uso del

mecanismo de autorización de Apache, o con modelos de acceso

de diseño propio usando LDAP, archivos &htaccess;, etc. e

incluir ese código como parte de los scripts <acronym>PHP</acronym>.

</simpara>

<simpara>

Con frecuencia, una vez la seguridad se ha establecido en un punto

en donde el usuario de <acronym>PHP</acronym> (en este caso, el usuario de apache)

tiene asociada muy poco riesgo, se descubre que

<acronym>PHP</acronym> se encuentra ahora imposibilitado de escribir archivos en los

directorios de los usuarios. O quizás se le haya

desprovisto de la capacidad de acceder o modificar bases de

datos. Se ha prevenido que pudiera escribir tanto

archivos buenos como malos, o que pudiera realizar transacciones

buenas o malas en la base de datos.

</simpara>

<simpara>

Un error de seguridad cometido con frecuencia en este punto es

darle permisos de administrador (root) a apache, o incrementar las

habilidades del usuario de apache de alguna otra forma.

</simpara>

<simpara>

Incrementar los permisos del usuario de Apache hasta el nivel de

administrador es extremadamente peligroso y puede comprometer al

sistema entero, así que el uso de entornos sudo, chroot, o

cualquier otro mecanismo que sea ejecutado como root no

debería ser considerado como una opción por aquellos que no

son profesionales en seguridad.

</simpara>

<simpara>

Existen otras soluciones más simples. Mediante el uso

de <link linkend="ini.open-basedir">open_basedir</link> se

puede controlar y restringir qué directorios

pueden ser usados por <acronym>PHP</acronym>. También se pueden definir

áreas solo-Apache, para restringir todas las actividades

basadas en web a archivos que no son de usuarios o del sistema.

</simpara>

</chapter>