Los 10 errores de seguridad de los Webmasters

La siguiente es una lista representativa de los errores más comunes respecto a seguridad en sitios webs que he encontrado a lo largo de innumerables "investigaciones". Hay algo que todos los errores tienen en común: son sencillos de evitar. Es de esperar que esta lista la aprovechen para compararla con sus propios sitios web y puedan tomar las medidas necesarias.
Errores
1.- Dejar respaldos de configuraciones importantes en directorios Web: Muchos administradores y webmasters se confían y suben respaldos de las configuraciones a directorios accesibles desde Internet lo cual es un error GRAVISIMO, ya que si alguien logra descargar estos respaldos, puede obtener contraseñas de bases de datos, conocer la estructura del sitio, etc.
2.- Dejar contraseñas por defecto: No son pocos los sitios que he visto con /phpmyadmin/ sin ningún password. Es recomendable NO usar phpmyadmin, pero si lo va a hacer al menos póngale clave de root a MySQL y una doble clave con .htaccess al directorio /phpmyadmin/.
3.- Claves de acceso fáciles de adivinar : Normalmente en los formularios de acceso a sitios o generalmente en las plataformas de administración ( /admin/) utilizan claves muy fáciles de romper por adivinanza, como el nombre del dominio o la misma clave que el nombre de usuario. Grave error. Además, hay que recalcar que aunque nadie pueda tener nuestras claves, éstas generalmente quedan almacenadas en bases de datos cifradas con el algortimo md5 y tienen un aspecto similar a esto: 098f6bcd4621d373cade4e832627b4f6. Si la clave en sí es MUY simple, no sirve de mucho que vaya cifrada ya que mediante un ataque de diccionario se puede obtener el password, o si no vean http://www.md5encryption.com/?mod=decrypt y descifren 098f6bcd4621d373cade4e832627b4f6.
4.- No actualizar los softwares web: Muchos instalan Joomla o Dokeos y se olvidan de que existieron, se olvidan de las actualizaciones y al final terminan siendo el blanco de los script-kiddies que corren exploits como locos. Es importante actualizar los software web y sus componentes 3d Party.
5.-Creer que nadie los ataca: Desde que se instala un servidor nuevo con una IP nueva, está probado que en promedio pasan 5 horas antes de recibir los primeros escaneos desde algún lugar del mundo. No es buena práctica creer que nadie está pensando en destruirlos. Creo que este mismo sitio web ya tiene a varios nerds "sedientos" de hacerle algo.
6.-No realizarse autoataques. El hecho de autoatacarse y probar exploits y técnicas de hacking contra nuestros propios servidores ayuda a tener una visión más clara de los puntos débiles y por ende, se pueden fortalecer. Claro, esto depende netamente de la habilidad de cada uno, pero al menos si se le pone empeño se puede dejar fuera a varios lammers.
7.- Usar las mismas contraseñas de las bases de datos que usuarios del sistema: Hay muchas personas que tienen la mala costumbre de utilizar la misma clave de root de MySQL que la de root del sistema. Grave error, porque no es muy dificil aplicar técnicas de inclusión remota de archivos para mostrar el contenido de los scripts de configuración con los datos de las bases de datos (¿a alguien le suena config.php?). Una vez que se tienen los datos tipo: $username=root y $password=omaigad basta probar con una sesión SSH al servidor utilizando los mismos datos y... voilá!
8.-No usar https:// para formularios de login: Lo ideal es que cada vez que hayan formularios de login se utilicen sesiones cifradas con SSL (https), para evitar problemas de sniffing. Muchas veces es inviable hacerlo pero el error de los Webmasters está en que cuando se puede perfectamente, no lo implementan.
9.-Permitir que se liste el contenido de directorios: A veces ponemos www.sitioweb.com/scripts/ y el resultado es una lista interminable de scripts que muchas veces no funcionan y al tratar de ejecutarlos terminan arrojando errores que indican la ruta donde está instalada la página web dentro del sistema. Muchos usan el formato /home/usuario/, lo cual le dá al atacante un indicio del nombre de la cuenta de usuario bajo la cual corre la página web. Solución: de partida se puede crear un index.html en blanco en todos los directorios web para que no listen el contenido. Otra solución un poco más compleja pero efectiva es activar la opción -Indexes (con guión) en las directivas de Apache para el virtualhost en cuestión.
10.-No habilitar la seguridad de PHP: Quienes trabajan con PHP, en un 99% de los casos no habilitan las opciones de seguridad de php.ini. Hay dos variables interesantes que habilitar en php.ini: php_expose=off y safe_mode=on. Esta última opción evita que usando PHP se ejecuten instrucciones de sistema en la máquina. Por ejemplo en el caso de un ataque de inclusión remota, se puede crear un script con la intrucción system("cat /etc/shadow");, lo cual devolvería eventualmente el contenido de las contraseñas de sistemas cifradas. Si las passwords escogidas fueron simples, John The Ripper no demorará mucho en devolverlas. Solución, habiliten estas opciones en PHP.INI.
Y por último, pero no menos importante, casi siempre quedan disponibles scripts en las rutas www que tienen la función phpinfo(); la cual muestra mucha información del sistema. No es bueno tenerla activada (menos bajo un nombre tan común como info.php). Pueden eliminarla para evitar problemas.