+52 222 812 6913
info@cesuma.mx
Internet es un lugar peligroso. A menudo oímos hablar de sitios web que han dejado de estar disponibles debido a ataques de denegación de servicio, o que muestran información modificada (y a menudo perjudicial) en sus páginas de inicio. En otros casos de gran repercusión, millones de contraseñas, direcciones de correo electrónico y datos de tarjetas de crédito se revelan al público, exponiendo a los usuarios de sitios web tanto a la vergüenza personal como al riesgo de pérdidas financieras.
Seguridad de un sitio web
El objetivo de la seguridad de los sitios web es prevenir este tipo de ataques. Más formalmente, la seguridad de los sitios web es el acto de protegerlos contra el acceso, uso, modificación, destrucción o interrupción no autorizados.
La seguridad eficaz de un sitio web requiere un esfuerzo de diseño en todo el sitio: en su aplicación web, en la configuración del servidor web, en sus políticas de creación y renovación de contraseñas y en el código del lado del cliente. Aunque todo esto suena muy preocupante, la buena noticia es que, si utilizas un framework web del lado del servidor, seguramente incluirá mecanismos de defensa fuertes y bien pensados contra varios de los ataques más comunes por defecto. Otros ataques se pueden mitigar configurando el servidor web, por ejemplo, activando HTTPS. Por último, las herramientas de exploración de vulnerabilidades disponibles al público pueden ayudarte a descubrir posibles fallos de diseño.
El resto de este artículo detalla las amenazas más comunes para los sitios web y algunos pasos sencillos para proteger tu sitio.
XSS es un término empleado para describir una clase de ataque que permite al atacante inyectar scripts, que se ejecutan del lado del cliente, a través del sitio web para dirigirse a los navegadores de otros usuarios. Dado que el código inyectado proviene del sitio web que el navegador considera seguro, puede hacer cosas como pasar la cookie de autenticación del usuario al atacante. Una vez que el atacante obtiene esta cookie puede entrar en el sitio como si fuera el usuario atacado y puede hacer cualquier cosa que el usuario pudiera hacer. Dependiendo del sitio en el que se produzca el ataque, esto puede incluir el acceso a los datos de la tarjeta de crédito, la información de contacto, el cambio de la contraseña, etc.
Hay dos formas principales de solicitar al sitio que devuelva un script inyectado a un navegador web: se denominan vulnerabilidades XSS reflexivas y persistentes.
1. Una vulnerabilidad XSS reflexiva se produce cuando el contenido del usuario enviado al servidor se devuelve inmediatamente, sin modificar, para su visualización en el navegador: ¡todos los scripts presentes en el contenido original se ejecutarán cuando se cargue la nueva página!
Un ejemplo sería una función de búsqueda en un sitio donde los términos de búsqueda se codifican como parámetros en la URL, y que estos términos se muestran permanentemente con los resultados. Un atacante puede construir un enlace de búsqueda que contenga un script malicioso como parámetro y enviarlo por correo electrónico a otro usuario. Si el usuario objetivo hace clic en este enlace interesante, el script se ejecutará cuando se muestren los resultados de la búsqueda. Como se ha visto antes, esto da al atacante toda la información que necesita para entrar en el sitio con la cuenta de la víctima y potencialmente hacer compras como ese usuario o acceder a la lista de contactos.
2. Una vulnerabilidad XSS persistente será aquella en la que el script malicioso se almacena en el sitio web y luego se muestra, sin modificación, un poco más tarde por otros usuarios y se ejecuta sin su conocimiento.
Por ejemplo, una pantalla de chat que acepta comentarios que contienen código HTML puro puede almacenar el script malicioso del atacante. Cuando se muestran los comentarios, el script se ejecuta y puede transmitir al atacante la información necesaria para acceder a la cuenta del usuario. Este método de ataque es extremadamente común y efectivo, porque el atacante no necesita tener una relación directa con las víctimas.
Aunque el envío de datos con POST o GET es la fuente más común de vulnerabilidad XSS, cualquier dato que provenga del navegador web es potencialmente vulnerable (esto incluye la visualización de datos de cookies por parte del navegador, o los archivos del usuario que se cargan y muestran).
La mejor defensa contra las vulnerabilidades XSS es eliminar o desactivar todas las etiquetas que puedan contener potencialmente instrucciones para ejecutar código. En el caso de HTML, esto incluye etiquetas como <script>, <object>, <embed> y <link>.
Es necesario procesar los datos introducidos por el usuario para asegurarse de que no pueden ejecutar scripts ni interrumpir el funcionamiento normal del sitio (este proceso se denomina sanitización de la entrada). Muchos frameworks proponen por defecto esta verificación en las entradas del formulario.
Inyección SQL
La inyección SQL es una vulnerabilidad que permite a un atacante ejecutar código SQL fraudulento en una base de datos, permitiendo el acceso, la modificación o la eliminación de datos independientemente de los derechos del usuario. Un ataque de inyección exitoso puede permitir la usurpación de una cuenta, la creación de una cuenta con derechos de administrador, el acceso a todos los datos del servidor o la modificación/destrucción de datos para hacerlos inutilizables.
Esta vulnerabilidad está presente cuando se pasa una entrada del usuario a una consulta SQL subyacente que puede cambiar la dirección de la consulta. Por ejemplo, en el código siguiente que debe listar todos los usuarios con un nombre determinado (userName) y que proviene de un formulario HTML.
Si el usuario introduce un nombre correcto, funcionará como está previsto. Sin embargo, un usuario malintencionado puede cambiar completamente el significado de esta consulta SQL a la siguiente consulta, simplemente añadiendo un texto en negrita como nombre, esta consulta modificada creará una consulta SQL válida que borrará la tabla users y seleccionará todos los datos de la tabla userinfo (revelando la información de cada usuario). Todo esto es posible gracias al comienzo del texto inyectado (‘a’) que completará la consulta original (es el símbolo para delimitar una cadena de texto en SQL).
La forma de evitar este tipo de ataque es asegurar que cualquier entrada del usuario que se pase a una consulta SQL no pueda cambiar la naturaleza de esa consulta. Una forma de hacerlo es escapar todos los caracteres de la entrada del usuario cuando tienen un significado particular en SQL.
Conozca más de nuestro Diplomado en Servicios y Sistemas de Información Digital
Creativa, social media manager, copywriter y amante de gatitos. Donde me encanta escribir y crear conceptualizaciones para las marcas, y expresarme libremente a través de mis letras.
- El rol del pensamiento lateral en la innovación educativa - 27 de octubre de 2024
- Evaluación del desempeño laboral: métodos y mejores prácticas - 27 de octubre de 2024
- Cómo diseñar un plan de negocio para una empresa turística: pasos y ejemplos - 27 de octubre de 2024
