5 patrones de diseño comunes para PHP

La gente de developerworks (IBM), nos regala este fantástico artículo donde nos introducen con ejemplos los 5 patrones de diseño en PHP más extendidos (solo PHP5):

  • Factory
  • Singleton
  • Observer
  • Chain-of-command
  • Strategy

Hace poco, tambien surgió una interesante iniciativa para crear un wiki con los patrones de diseño más usados, incluyendo tambien su equivalente en PHP4:
http://blog.quantum-star.com/exit.php?url_id=432&entry_id=223

Muy interante en mi opinión el artículo, para aprender y avanzar en el desarrollo “profesional” de aplicaciones en PHP. Cada vez más y más razones nos empujan a desarrollar completamente en PHP5. Y es que quitando el inconveniente de que pocas empresas de alojamiento lo ofrecen, las ventajas que nos ofrece son tan interesantes que merece la pena tomarlo como base en nuestros nuevos proyectos. Yo ya lo hago y desde hace tiempo, usando como base el Zend Framework.

Los 5 puntos debiles de PHP en 2005

owasp

El OWASP ha publicado un estudio con las 5 categorías de vulnerabilidades más frecuentes en PHP en el año 2005. En resumen:

Ejecución remota de código
Este ha sido el mayor problema de seguridad desde Julio de 2004, principalmente a trav&eacue;s de llamadas a comandos del sistema operativo.
Las causas principales son:

  • No validar suficientemente la información que proporciona el usuario (formularios, url, etc.) antes de realizar llamadas al sistema (como include, require o fopen).
  • Tener activado allow_url_fopen y PHP wrappers (necesario para muchas aplicaciones) por defecto.
  • Pobre o nula política de permisos y planes de seguridad en la mayoria de las empresas de alojamiento web, permitiendo excesivos privilegios por defecto.
cross-site scripting (ejecución de scripts no pertenecientes al sitio).
El Cross-site scripting (tambien conocido como inyección HTML o “user agent injection”) es posible en PHP en sus tres modos: reflected, persistent y DOM injection.

  • Reflected: El atacante provee un link o similar con contenido malicioso, que la aplicación muestra inmediatamente a la víctima. Esta es la principal forma de “phishing” por email (suplantacion de webs de entidades bancarias, de eBay, etc.)
  • Persistent: El atacante consigue que guardemos su codigo malicioso en nuestra base de datos (via un formulario de comentarios, por ejemplo), que luego se mostrará a sus víctimas. Esta es la forma más común de cross-site scripting que podemos encontrar sobre todo en foros y apliaciones de webmail.
  • DOM: El atacante usa el codigo javascript del sitio víctima para realizar cross-site scripting del primer tipo (reflected). Esta técnica no es muy usada hasta el momento , pero es tan peligrosa como las otras.

PHP no tiene ningun mecanismo por defecto para protegernos del cross-site scripting de forma automática, asi que si el programador no lo controla en el código, nuestro site será vulnerable por defecto.

Inyección de SQL
La inyección de código SQL es uno de los ataques más antiguos y conocidos en las aplicaciones web. Y gracias a este conocimiento, existen numerosas técnicas para protegerse de el:

  • Validar la información antes de usarla en consultas SQL dinámicas.
  • Siempre elegir validación positiva antes que negativa (black listing).
  • Usar PDO (disponible via PECL para PHP 5.0 y disponible en PHP 5.1 y posteriores).
  • Usar las sentencias parametrizadas de MySQLi o de la PEAR::DB.
  • Como mínimo usar funciones como mysql_real_escape_string(). Todas las interfaces de base de datos tienen funciones básicas de correccion de SQL.
Configuración de PHP
La configuración de PHP tiene una influencia directa en la gravedad de los ataques. Malas opciones de configuración, maximizan las posibilidades del atacante y el daño que es posible causar a estos sistemas. Y lo que es aún peor, muchas de las opciones de seguridad de PHP son configuradas de forma incorrecta, produciendo un falso sentido de seguridad en el administrador.

Es realmente sorprendente que no exista un acuerdo en la configuración de PHP segura y es tambien sorprendente que la configuración por defecto sea tan poco segura.
Existen argumentos a favor y en contra de las opciones m&aacue;s comunes de seguridad:

  • register_globals (off por defecto en las versiones más modernas de PHP, debe estar off)
  • allow_url_fopen (habilitada por defecto, debería estar deshabilitada)
  • magic_quotes_gpc (habilitada por defecto en versiones modernas, debería estar deshabilitada)
  • magic_quotes_runtime (deshabilitada por defecto en versiones modernas, debería estar deshabilitada)
  • safe_mode and open_basedir (deshabilitada por defecto, debería estar habilitada y bien configurada. Se debe tener en cuenta que si el safe_mode realmente no es en si “seguro” y que puede ser más peligroso si no está correctamente configurado).

Debido a los desacuerdos en cual es la mejor configuración, y a la preferencia en los proyectos PHP de habilitar más fuciones frente a tener mayor seguridad, la mayoría de las instalaciones de PHP son poco seguras

Ataques al sistema de ficheros
Los desarrolladores de PHP tienen muchas formas de saltarse la seguridad presente en los alojamientos compartidos:

  • Inclusión de ficheros locales (como el fichero de contraseñs;as)
  • Manipulación de las sesiones locales (normalmente en /tmp)
  • Inyección de ficheros locales en las subidas de archivos (normalmente como parte del manejo de imagenes adjuntas)

Como la mayoría de los alojamientos compartidos ejecutan PHP con el mismo usuario que apache (normalmente “nobody”), todos los usuarios del sistema son vulnerables a estos problemas.

Muy interesante estudio para todos aquellos que nos dedicamos al desarrollo sobre esta plataforma y que queremos conseguir que nuestras aplicaciones sean seguras. Incluye diversos tests para comprobar si somos vulnerables a estos problemas.