¿Cómo evitar ataques de hackers en una página web?

Ramón Saquete

Escrito por Ramón Saquete

hackingPara poder implementar Webs con un buen nivel de seguridad hay que saber cómo pueden atacarlas.  También hay que tener en cuenta que, aunque la Web sea totalmente segura, con el tiempo, pueden surgir ataques nuevos que puedan penetrar las defensas creadas. Lo mejor que podemos hacer para evitar estos ataques es tener siempre el código actualizado y disponer de medidas que permitan recuperarnos del ataque lo más rápido posible y si Google nos etiqueta como página atacante, pedirle una revisión  cuanto antes.

Cada tecnología tiene sus propios puntos débiles y las nuevas aportan nuevos puntos de ataque y, por este motivo,  voy a exponer los más conocidos:

Inyección de código:

La inyección de código trata de insertar código malicioso en la Web, ya sea código de cliente o de servidor. Así tenemos ataques que inyectan código HTML, CSS, Javascript, SQL, PHP, Comandos de la consola del servidor, etc.

Algunos programadores sólo filtran la inyección de código en campos que quedan a la vista al usuario, como la URL o los campos de formularios. Además, las herramientas automáticas para la detección de agujeros de seguridad, tampoco van mucho más allá. Sin embargo, los hackers pueden modificar cualquier parámetro que se envíe en la comunicación, ya esté en las cabeceras del protocolo HTTP, en las peticiones realizadas por AJAX o en campos ocultos de formularios. Esto se lleva a cabo con herramientas como WebScarab, Paros o Burp que actúan como proxy entre el navegador del hacker y el servidor, permitiendo ver todo el contenido de la comunicación y modificarlo al vuelo a gusto del atacante. Los hackers son muy pacientes: si quieren atacar un objetivo concreto, pueden pasar semanas o meses buscando vulnerabilidades de este tipo.

Seguidamente voy a exponer, muy por encima, los ataques de inyección de código más comunes y cómo prevenirlos:

SQL Injection

La inyección de código SQL puede usarse para ganar acceso al área privada de una Web, robar o borrar información, hacer modificaciones en la Web, o incluso, tomar el control total del servidor con todas las bases de datos y Webs que existan en éste. Habitualmente, estos ataques se llevan a cabo haciendo uso de la comilla simple, que cierra una cadena en SQL y de «- -» que se utiliza para poner comentarios. A continuación, un ejemplo original para ilustrar este tipo de ataques, traducido del Webcomic xkcd:

madre-hacker

La forma de prevenir estos ataques es utilizar, como mínimo, las funciones de filtrado que nos proporcionan los distintos frameworks de desarrollo y, procurar siempre establecer la codificación de la página ya que si acepta varias codificaciones, pueden saltarse el filtro introduciendo caracteres en UTF7.

XSS (Cross Site Scripting)

La inyección de Javascript proveniente de otros dominios puede usarse para capturar las pulsaciones del teclado, lanzar ataques de denegación de servicio, escanear la red interna del usuario, montar ataques de Phishing, obtener la geolocalización del usuario con Javascript de HTML5, etc. Aunque lo más común suele ser el robo de Cookies u otra información que podamos encontrar en las nuevas características de almacenamiento local de HTML5, muchas veces el ataque se realiza con el fin de entrar al área de administración del usuario.

La forma de realizarlos suele ser introduciendo código en campos que al enviarlos se ven reflejados en la Web. Este tipo de ataques pueden ser persistentes o no. Los persistentes lo son porque permanecen en la Web para todos los usuarios, después de realizar el ataque. Los no persistentes requieren algo de ingeniería social para engañar a un usuario concreto a que pinche en un enlace preparado con el ataque. El enlace puede ser una redirección que lleve a una URL que tenga el ataque en la Querystring o puede llevar a una Web, que al cargarse, haga automáticamente un envió de un formulario por POST con el ataque.

De nuevo, la forma de evitar este tipo de ataques es filtrar todas las entradas con los frameworks disponibles, aunque a veces se encuentran vulnerabilidades que afectan a estos frameworks y todas las Webs que los usan quedan expuestas, como por ejemplo el ataque <%etiqueta> de algunas versiones del framework de .NET. Además, los data URIs dan una nueva forma de saltarse estos filtros. En estos casos no queda más remedio que actualizar los frameworks o el código de la Web.
Por otro lado, para aumentar la seguridad de las Cookies que contienen información de sesión, se recomienda activar el flag HttpOnly y, en caso de usar HTTPS, activar también el flag Secure.

CSRF (Cross Site Request Forgery)

La falsificación de solicitudes cruzada consiste en conseguir que la víctima pinche en un enlace creado por el atacante, en el momento que la víctima tiene la sesión abierta en la Web, de forma que el enlace realice una acción en su área privada. Por ejemplo, si para añadir un amigo en Facebook, la URL fuera algo así http://www.facebook.com/addfriend.php?id=idusuario, el atacante Forever Alone, podría crear un enlace igual pero con su id de usuario y ponerlo en su perfil público de Facebook. Así si alguien que ha iniciado sesión pincha en el enlace lo agregará como amigo.

La forma de protegerse contra este tipo de ataques es añadir un hash, que sea difícil de calcular y sólo válido para la sesión actual, como parámetro necesario para las acciones que tiene disponible el usuario registrado. De esta forma otro usuario no puede construir una URL con ese parámetro ya que no puede conocer el hash.

camiseta-samy-is-my-hero

Con una mezcla de este tipo de ataque y del anterior, se hizo famoso, en 2005, el gusano.

Samy, un virus que fue introducido en la red social de MySpace y que se extendía a cada persona que visitaba el perfil de alguien infectado. Lo que hacía era añadir el perfil del autor Samy, en una sección de héroes. El virus se propagó a más de un millón de perfiles en 20 horas, obligando a Myspace a cerrar el servicio para poder solucionar el problema. El autor fue sentenciado a un castigo bastante cruel: estar tres años sin usar un ordenador. En su honor, tenemos la librería de programación Web AntiSamy, que forma parte del proyecto OWASP (Open Web Application Security Project). Esta permite ofrecer al usuario, la posibilidad de introducir algunas etiquetas de HTML, sin que éste pueda realizar ataques XSS.

Otros tipos de ataque

  • Recuperación de contraseñas por fuerza bruta: Un atacante puede obtener la contraseña de un usuario conocido a base de probar todas las contraseñas posibles o más habituales. La forma de evitarlo, es permitir un número máximo de intentos para introducir la contraseña correcta.
  • Robo de identificador de sesión: si el atacante consigue predecir el próximo id de sesión que dará la aplicación, podrá suplantar al próximo usuario que inicie sesión. Esto ha cobrado auge en 2012, al aparecer generadores de identificador de sesión de PHP para realizar ataques de fuerza bruta de este tipo. Si el identificador generado es fácilmente predecible, un hacker lo puede detectar usando una herramienta de análisis como la que trae Webscarab.
  • Información expuesta: pueden estar expuestos al ataque la propia base de datos o el código (debido al uso del sistema de control de versiones), y pueden ser recuperados desde Google con ataques del Google Hacking Data Base. También podemos encontrar comentarios en el código que delaten el funcionamiento interno.
  • Ataques al servidor o a su red: Conforman todo un mundo aparte. Los ataques a servidores pobremente protegidos pueden dar al atacante acceso a toda la Web o permitir que los ataques DoS (Denial of Service), tengan éxito. Los ataques DoS se suelen realizar a base de lanzar múltiples peticiones al servidor Web desde distintos sitios hasta que el servidor cae. El administrador de sistemas debe estar preparado con las herramientas adecuadas para filtrar este tipo de ataques, así como disponer de herramientas para detectar intrusiones a servicios como el FTP o SSH y procurar mantener actualizado el software del servidor.

Existen infinidad de ataques más que afectan a todo tipo tecnologías como Flash, SilverLight, directorios LDAP, componentes ActiveX, applets de Java, y muchos otros aplicables a varias tecnologías, como los ataques a CMS’s y plugins de éstos, ataques de buffer overflow, ataques SSRF, Spam bots que recolectan e-mails y rellenan formularios automáticamente, etc.
Sin embargo, el punto más débil no es el servidor ni la programación de la Web, es el usuario. Si el usuario es muy ingenuo podrá ser atacado independientemente de la seguridad que tengamos en nuestra Web. Pero si está prevenido respecto a los ataques de Phishing, se cuida de no coger virus, no usa redes Wifi abiertas o poco protegidas y tiene el navegador actualizado, entonces no debería tener problemas.

  •  | 
  • Modificado el
Ramón Saquete
Ramón Saquete
Desarrollador web y consultor SEO técnico en Human Level. Graduado en Ingeniería Informática e Ingeniería Técnica en Informática de Sistemas. También es Técnico Superior en Desarrollo de Aplicaciones Informáticas y posteriormente obtuvo la Certificación de Aptitud Pedagógica. Experto en WPO e indexabilidad.

6 comentarios

¿Y tú qué opinas? Deja un comentario

Por si acaso, tu email no se mostrará ;)

  1. Un artículo muy importante y que a más de uno nos ha venido de perlas eso seguro, tanto a webmasters de webs como a diseñadores y demás, me encanta la información y directo al grano, gran trabajo Ramón, espero que siga todo genial como hasta ahora.
    Un fuerte saludo, Sandra.

  2. Hola, el search console de google me dice que mi pagina fue pirateada con spam (inyección de url), pero por mas que he buscado donde pueda estar, no he podido encontrarlo, ya revise .htaccess, index, etc, etc, y simplemento no lo hallo. ¿algún consejo de como hacerle para encontrarlo?

    gracias.

    1. Hola Carlos,
      Busca la URL en todo el código con algún editor que lo permita como Sublime. Muchas veces los hackers añaden su código al principio del archivo con unos cuantos miles de tabuladores, para que no se vea su código editando los archivos a primera vista.
      Genera el script de creación de la base de datos y haz una búsqueda también aquí.
      Si usas un CMS como WordPress puede que hayan modificado los archivos del núcleo, aprovecha para actualizarlo.

      Saludos

  3. Sí, para proteger las contraseñas, además de lo que he comentado, en general es importante:
    – La política de seguridad implementada: me refiero a no permitir a los usuarios introducir contraseñas muy cortas, sin combinaciones de mayúsculas y minúsculas o números.
    – Que las contraseñas no se envíen por la red en texto claro. Lo ideal es que se envíen cifradas mediante HTTPS, pero si no hay más remedio la podemos cifrar con JavaScript (la clave de cifrado la podemos generar en el servidor para cada petición).
    – No guardar las contraseñas en texto claro en la base de datos, sólo un hash contra el que comparar la contraseña.
    – No guardar las contraseñas en las cookies o cualquier otro método de almacenamiento en el cliente.
    – Por último, registrar todos los inicios de sesión, recogiendo los patrones de uso (horas, sistema operativo, navegador y ubicación a partir de la IP), para poder detectar posibles accesos no autorizados que se salgan del patrón habitual.

    Saludos

  4. Muchas gracias por todos estos consejos, el robo de contraseña creo que es uno de los casos que más he padecido, tanto conocidos como yo mismo, a parte de poner un número limitado de intentos,¿ nos puedes dar alguna otra recomendación? Gracias

es