Seguridad PHP servidores web

En mi experiencia, la mayoría de las vulnerabilidades en una web basada en PHP sitio son el resultado de los pobres (el sitio) diseño, en lugar de defectos en PHP en sí.

Algunos consejos rápidos:

• Universalmente filtro de entrada, salida de fuga. Clarificaiton: filtro no significa escapar, que significa "si encuentro algo raro en esta entrada del usuario, la causa de la presentación de la falla y decirle al usuario que volver a formatear."
• En lugar de utilizar escapeshellcmd(), simplemente no permitir la entrada de usuario se pueden ejecutar en el shell. Eso es peligroso y probablemente nunca lo realmente necesario.
• No llamar a funciones como el phpinfo() en un sitio de producción (o si no, véase abajo*).
• A la hora de diseñar una aplicación web, siempre considere "es este un posible vector de ataque?" Decir, la inyección de SQL. Si la respuesta es "sí", conecte inmediatamente--no diga: "ok, voy a agregar que más adelante en el desarrollo como una característica." La seguridad nunca es una característica.
• Nunca la salida de crudo de los errores para el usuario; esto significa que la configuración de php.del ini display_errors = Off, log_errors = On. Trampa de errores en tiempo de ejecución y salida de algo bonito. Tomar de Twitter de la ballena como un ejemplo: no dar al usuario un nivel de depuración de la información, sólo dice que "woops, algo se rompió, por favor actualizar".

*También puede tomar un vistazo a un breve post que escribí llamado "Asegurar el phpinfo(), una especie de" y asegúrese de leer los comentarios http://egovsergo.com/2009/04/03/protecting-your-phpinfo/ fue una rápida idea que yo tenía (un poco) de proteger a phpinfo() si de alguna manera me olvidó quitarlo en un sitio en producción.

De una manera más general, algunos desarrolladores que escriben contenedores para funciones sensibles que comprobar si no el "lugar de producción" flag o no, y desactiva la función sensible en la producción.

Otros parámetros que deben ser modificadas para endurecer el PHP:

safe_mode = Off
register_globals = Off
expose_php = Off
allow_url_fopen = Off
allow_url_include = Off
log_errors = On
error_log = /var/log/phperror.log
display_errors = Off
enable_dl = Off
disable_functions="popen,exec,system,passthru,proc_open,shell_exec,show_source,phpinfo"

Almacenar todos los errores de PHP en el archivo /var/log/phperror.registro:

touch /var/log/phperror.log
chmod 666 /var/log/phperror.log

He añadido el dotdeb repositorios para mi /etc/apt/sources.lst

deb http://packages.dotdeb.org stable all
deb-src http://packages.dotdeb.org stable all

Como que el parche php / apache / mysql mucho más frecuentemente que los de Debian.

Considerar la posibilidad de establecer open_basedir "por el sitio". open_basedir es un php.configuración ini que evitará que las secuencias de comandos de acceso a archivos fuera de una definida la lista blanca. Si su servidor alberga varios sitios, que va a evitar que un sitio de la lectura de la configuración de base de datos desde otro sitio. Que también va a evitar que un script php de acceso/modificación de archivos de sistema de núcleo. Abierto basedir es fácil de instalar, sólo tiene que añadir la línea "php_admin_value open_basedir /my/list/of/folders:/as/a/colon/seperated/list" para cada uno de Apache vhost.

También considere la posibilidad de desactivar el script PHP motor para todos los sitios/carpetas que no contienen scripts de PHP (por ejemplo, las imágenes de la carpeta). De nuevo, esto es simple, agregar "php_admin_value motor" para cualquier Apache VirtualHosts sin necesidad de php. Para deshabilitar PHP en un directorio, poner la misma cosa en un Directorio de la etiqueta.

Ejecute el archivo de permisos de tan apretado como sea posible, evite el acceso de escritura a los scripts PHP para el usuario de Apache, esto impide que una secuencia de comandos en ejecución de la modificación de sí mismo o de otras secuencias de comandos en el mismo sitio/servidor. Evitar permisos 777, si es posible, averiguar los permisos mínimos necesarios para ejecutar la aplicación y uso de esas.

Si usted es anfitrión de varios sitios, cada uno con su propia base de datos, el uso de una nueva MySQL/Postgres de usuario para cada uno, y establecer los permisos de cada usuario, de tal manera que sólo se tiene acceso a las bases de datos pertinentes. De nuevo, esto evitará que un script malicioso de la manipulación con otra aplicación de la base de datos.

Suosin, HardenedPHP, mod_security y similares, todos son valiosos, pero el uso de ellas, además de un hermetismo de configuración, no en lugar de.