Errores de programación (VI)

Viendo las estadísticas de las páginas web que administro, descubrí que en una de ellas se hacía referencia a un servidor brasileño, puesto como argumento de un parámetro pasado por GET. Hace meses, pasó lo propio con uno ruso y nunca le había prestado atención hasta ahora. Algún lector ya sabrá lo que está pasando, pero, para los demás, voy a seguir con el suspense.

Me pongo a indagar y descubro que están intentando redireccionar a un archivo que es un código en PhP bastante elaborado. Me cuesta muy poco tiempo descubrir que es cosa de "hackers" (Nota para hackers: los denomino "hackers" porque no han causado ningún daño en mis páginas... en otro caso, los llamaría "crackers"; que no se me enfade nadie). Bueno, el caso es que lo que he sufrido han sido ataques (o intentos, que ya digo que no he observado nada raro en mis páginas) de "deface". Esto del "deface" es, básicamente, entrar en un servidor de un tercero y manipular sus páginas. Por ejemplo, introducir una firma en la página principal, cambiar una imagen por otra... Es relativamente simple de hacer en cualquier página programada en PhP o ASP y, supongo, los daños que puedan hacer en el servidor dependerán de la configuración de seguridad del mismo.

Pues bien... Revisando el código de PhP de las páginas que administro, descubrí un error en una de ellas que las hacía vulnerables a uno de los tipos más simples de ataque de "deface". Tres líneas estúpidas que me dejé olvidadas después de copiar y pegar y que permitían incrustar código. Por eso lo considero error de programación.

Las páginas son obra de mi hermano, que es el que sabe PhP. Yo me limito a retocar el código, porque sé muy poco de ese lenguaje. Resulta que una regla básica de seguridad es no incorporar al código HTML que devuelve el PhP ninguna cadena que se haya introducido por POST o por GET. En caso contrario, basta con que el "hacker" copie y pegue el código que desea ejecutar en el formulario inseguro, o que cambie la URL interna para incrustar un fichero alojado en otra parte. Lo primero no es problema, lo segundo, mi hermano lo había mirado. De hecho, ahora es muy difícil que ese método vuelva a funcionar.

No quiero dar detalles para no dar pistas. El caso es que las diferentes secciones de la página se cargan de forma dinámica, usando una variable que pasamos por GET que se gestiona de manera que sólo pueda tomar una serie de valores. Si alguien cambia la URL en el navegador, o bien se produce un error, o bien se muestra una página prefijada, salvo en un sitio concreto, en que, por defecto, reenviaba a una página donde se incluía el valor de la variable. De todos modos, creo que lo que nos ha salvado es que la inclusión no era directa, de manera que las URLs formadas desde un servidor externo serían erróneas.

Ya está corregido, de manera que esa vulnerabilidad ha dejado de existir, aunque seguiremos estudiando el código por si acaso. Cuidado si, en vuestras estadísticas, descubrís algo como inurl:"index.php?var=*.php", porque es una de las formas en que se busca a las "víctimas".