Seguridad de Sitios Web para Webmasters

Jueves, 12 de mayo de 2011

A los usuarios se les enseña a protegerse de programas maliciosos instalando software antivirus sofisticado, pero a menudo también pueden confiar su información privada a sitios web como el suyo, en cuyo caso es importante proteger sus datos. También es muy importante proteger sus propios datos; si tiene una tienda online, no querrá que le roben.

A lo largo de los años, las empresas y los webmasters han aprendido —a menudo por las malas— que la seguridad de las aplicaciones web no es una broma; hemos visto contraseñas de usuarios filtradas debido a
SQL injection
ataques, cookies robadas con
XSS, y sitios web tomado por hackers debido a una validación de entradas negligente.

Hoy les mostraremos algunos ejemplos de cómo se puede explotar una aplicación web para que puedan aprender de ellos; para esto usaremos
Gruyere, una aplicación intencionalmente vulnerable que también usamos internamente para la formación en seguridad. No examine los sitios web de otros en busca de vulnerabilidades sin permiso ya que puede percibirse como piratería informática; pero es bienvenido —es más, se le anima— a realizar pruebas en Gruyere.

Manipulación del estado del cliente – ¿Qué pasará si altero la URL?

Digamos que tiene un sitio de alojamiento de imágenes y está usando un script PHP para mostrar las imágenes que los usuarios han subido:

Entonces, ¿qué hará la aplicación si altero la URL a algo como esto y userpasswords.txt es un archivo real?

¿Obtendré el contenido de userpasswords.txt?

Otro ejemplo de manipulación del estado del cliente es cuando los campos de los formularios no se validan. Por ejemplo, digamos que tiene este formulario:

Parece que el nombre de usuario de quien lo envía se almacena en un campo de entrada oculto. ¡Vaya, eso es genial! ¿Significa eso que si cambio el valor de ese campo a otro nombre de usuario, puedo enviar el formulario como ese usuario? Puede suceder perfectamente; Aparentemente, la entrada del usuario no está autenticada con, por ejemplo, un token que se pueda verificar en el servidor.

Imagine la situación de que ese formulario fuera parte de su carrito de compras y yo modificara el precio de un artículo de $1000 a $1, y luego realizara el pedido.

Proteger su aplicación contra este tipo de ataques no es fácil; eche un vistazo a la tercera parte de Gruyere para aprender algunos consejos sobre cómo defender su aplicación.

Cross-site scripting (XSS) – No se puede confiar en la entrada del usuario

Una URL simple e inofensiva:

¿Pero es realmente inofensiva? Si decodifico los
caracteres codificados por porcentaje
, obtengo:

Gruyere, al igual que muchos sitios con
páginas de error personalizadas, está diseñado para incluir el componente de ruta en la página HTML. Esto puede introducir errores de seguridad, como XSS, ya que introduce la entrada del usuario directamente en la página HTML renderizada de la aplicación web. Podría decir: “Es solo un cuadro de alerta, ¿y qué?” El caso es que, si puedo inyectar un cuadro de alerta, lo más probable es que también pueda inyectar otra cosa, y tal vez robar sus cookies que podría usar para iniciar sesión en su sitio como usted.

Otro ejemplo es cuando la entrada de usuario almacenada no se sanea. Digamos que escribo un comentario en su blog; el comentario es simple:

Si otros usuarios hacen clic en mi enlace inocente, tengo sus cookies:

Puede aprender cómo encontrar vulnerabilidades XSS en su propia aplicación web y cómo solucionarlas en la segunda parte de
Gruyere; o, si es un desarrollador avanzado, eche un vistazo a las características de escape automático en los sistemas de plantillas sobre las que escribimos en nuestro
Online Security blog.

Falsificación de peticiones en sitios cruzados (XSRF) – ¿Debería confiar en solicitudes de evil.com?

Vaya, una imagen rota. No puede ser peligrosa —después de todo está rota—, lo que significa que la URL de la imagen devuelve un 404 o simplemente está mal formada. ¿Es eso verdad en todos los casos?

¡No, no lo es! Puede especificar cualquier URL como fuente de imagen, independientemente de su tipo de contenido. Puede ser una página HTML, un archivo JavaScript o algún otro recurso potencialmente malicioso. En este caso, la fuente de la imagen era la URL de una página simple:

Esa página solo funcionará si he iniciado sesión y tengo algunas cookies configuradas. Dado que en realidad había iniciado sesión en la aplicación, cuando el navegador intentó recuperar la imagen accediendo a la URL de origen de la imagen, también eliminó mi primer fragmento. Esto no suena particularmente peligroso, pero si estoy un poco familiarizado con la aplicación, también podría invocar una URL que elimine el perfil de un usuario o permita a los administradores otorgar permisos a otros usuarios.

Para proteger su aplicación contra XSRF, no debe permitir que las acciones que cambian el estado se llamen a través de
GET; el método POST fue inventado para este tipo de solicitudes que cambian el estado. Este cambio por sí solo podría haber mitigado el ataque anterior, pero por lo general no es suficiente y necesita incluir un valor impredecible en todas las solicitudes que cambian el estado para evitar XSRF. Diríjase a Gruyere si desea obtener más información sobre XSRF.

Inclusión de scripts en sitios cruzados (XSSI) – Todos sus scripts nos pertenecen

Muchos sitios hoy en día pueden actualizar dinámicamente el contenido de una página a través de solicitudes JavaScript asíncronas que devuelven datos JSON. A veces, JSON puede contener datos confidenciales y, si no se toman las precauciones adecuadas, es posible que un atacante robe esta información confidencial.

Imaginemos el siguiente escenario: he creado una página HTML estándar y le he enviado el enlace; como confía en mí, visita el enlace que le envié. La página contiene solo unas pocas líneas:

Dado que ha iniciado sesión en Gruyere y tiene un fragmento privado, verá un cuadro de alerta en mi página que le informará sobre el contenido de su fragmento. Como siempre, si logré activar un cuadro de alerta, puedo hacer cualquier otra cosa que quiera; en este caso era un fragmento simple, pero también podría haber sido su mayor secreto.

No es muy difícil defender su aplicación contra XSSI, pero aún requiere un pensamiento cuidadoso. Puede usar tokens como se explica en la sección XSRF, configurar su script para que responda solo a solicitudes POST o simplemente iniciar la respuesta JSON con ‘n’ para asegurarse de que el script no sea ejecutable.

SQL Injection – ¿Todavía cree que la entrada del usuario es segura?

¿Qué pasará si intento iniciar sesión en su aplicación con un nombre de usuario como
JohnDoe'; DROP TABLE members;--

Si bien este ejemplo específico no expondrá los datos del usuario, puede causar grandes dolores de cabeza porque tiene el potencial de eliminar por completo la tabla SQL donde su aplicación almacena información sobre los miembros.

En general, puede proteger su aplicación contra la inyección SQL con un pensamiento proactivo y validación de entradas. Primero, ¿está seguro de que el usuario de SQL necesita tener permiso para ejecutar
DROP TABLE members¿No sería suficiente conceder solo derechos SELECT ? Al configurar cuidadosamente los permisos del usuario de SQL, puede evitar experiencias dolorosas y muchos problemas. Es posible que también desee configurar el informe de errores de modo que el nombre de la base de datos y sus tablas no se expongan en caso de una consulta fallida.

Segundo, como aprendimos en el caso de XSS, nunca confíe en la entrada del usuario: lo que para usted parece un formulario de inicio de sesión, para un atacante parece una puerta de entrada potencial. Siempre sanee y proteja con comillas la entrada que se almacenará en una base de datos y, siempre que sea posible, haga uso de declaraciones comúnmente conocidas como declaraciones preparadas o parametrizadas disponibles en la mayoría de las interfaces de programación de bases de datos.

Saber cómo se pueden explotar las aplicaciones web es el primer paso para comprender cómo defenderlas. A la luz de esto, le recomendamos que tome el
curso de Gruyere, tome otros cursos de seguridad web de
Google Code University
y consulte
skipfish
si está buscando una herramienta automatizada de pruebas de seguridad de aplicaciones web. Si tiene más preguntas, publíquelas en nuestro
Foro de Ayuda para Webmasters.

Escrito por
Gary Illyes, Analista de Tendencias para WebmastersSeguridad de Sitios Web para Webmasters | Alien Road