Fallo criptográfico en PHP

Sigo recopilando fallos del mundo real que siempre nos vienen bien para darnos cuenta de que estas cosas son complicadas. Y que los proyectos del perfil más alto (no desde el punto de vista de la seguridad, que a veces también, sino de uso y extensión) cometen también errores. En este caso, Serious Crypto Bug Found in PHP 5.3.7:

“If crypt() is executed with MD5 salts, the return value conists of the salt only. DES and BLOWFISH salts work as expected. I tested with php from openSUSE PHP5 repository,” the report said. Several other users reproduce the problem on various other platforms.

Más detalles en Bug #55439 crypt() returns only the salt for MD5.

Fortalecimiento de PHP

Algunas generalidades sobre la configuración de PHP (siempre que podamos tocarla) en Hardening PHP mediante php.ini. Los lenguajes van ofreciendo estas medidas para remediar fallos detectados a un nivel más profundo. No es la panacea (e, insisto, a lo mejor ni siquiera podemos tocarlo, o los programas no funcionan) pero puede ser una buena idea echar un vistazo.

Denegación de servicio en Java

En Java Denial of Service Vulnerability (Double Trouble) se comenta sobre un fallo de Java y algunas versiones de PHP que entraban en un bucle infinito al convertir la cadena “2.2250738585072012e-308″ en un valor de punto flotante de doble precisión. Esto podría provocar un ataque de denegación de servicio y, más allá de los detalles del problema y de cómo evitarlos, se comenta:

This bug is an excellent example of the evolving software security landscape. Until this problem came along, calling parseDouble() looked like an ideal way to validate input. Now parseDouble() is yet another weak point to protect. And so it goes. When you ship software, you have to make sure it’s protected against the risks we know about today. But when you wake up tomorrow, new risks may well have emerged during the night. Building secure systems means more than just avoiding foreseeable mistakes. It means preparing for the unforeseeable too. That means being ready to respond when new vulnerabilities emerge

Aparecen nuevos puntos débiles contínuamente, de manera que tenemos que estar preparados no sólo para evitar los desastres que ya conocemos, sino los que puedan aparecer en el futuro y, en particular, repsonder a los que puedan ir surgiendo y nos afecten.

Bibliotecas para evitar problemas en PHP

Ya hablamos en Dos grandes errores en las aplicaciones web y consejos para evitarlos del API que preparaba la gente de OWASP, ESAPI con el objetivo de simplificar las cuestiones relativas a la seguridad para desarrolladores en Java. También parece que se preocupan de otros lenguajes, como PHP, Python, Ruby …

Sin embargo en esta entrada me quería centrar en dos entradas veraniegas sobre el particular: Librería PHP para evitar SQL injection y XSS, donde se nos habla de Genius Open Source Libraries y Prevenir ataques XSS con PHP donde se comenta sobre el PHP Input Filter.

No las he visto en detalle pero es bueno que vayan surgiendo este tipo de iniciativas y que los programadores dispongan de estas herramientas para aligerar su trabajo.

PHP y la seguridad

En State of the Art Post Exploitation in Hardened PHP Environments se habla del trabajo de Stefan Esser sobre fallos de seguridad y ataques realizados en instalaciones de PHP previamente fortalecidas. Es bastante técnico (al menos para mi) pero me pareció interesante la primera parte, donde hace un repaso de las medidas de protección disponibles en el lenguaje actualmente (y sus defectos y debilidades).

Asegurando PHP

PHP es un lenguaje muy popular y con un historial extenso en cuanto a problemas de seguridad. Recientemente descubrí la serie de conferencias Web 2.0 Security & Privacy y en la edición de 2007 SStanislav Malyshev da un repaso a las distintas aproximaciones seguidas a lo largo del tiempo en la mejora de los aspectos de seguridad: Securing PHP – Approaches to Web Application Security (pdf), con su balance de aspectos positivos y negativos en cada caso.