La Seguridad de Aplicaciones Web consiste en una gran cantidad de controles de seguridad que garantizan que una aplicación web:
Funciona como se espera. No puede ser explotada para operar fuera de los límites. No puede iniciar operaciones que no se supone que deba hacer.
Las aplicaciones web se han vuelto ubicuas después de la expansión de Web 2.0, con plataformas de redes sociales, sitios web de comercio electrónico y clientes de correo electrónico saturando los espacios de Internet en los últimos años.
A medida que las aplicaciones consumen y almacenan datos aún más sensibles y completos, se convierten en objetivos cada vez más atractivos para los atacantes.
Métodos de ataque comunes
Las tres vulnerabilidades más comunes en este espacio son las Inyecciones (SQL, Código Remoto), Fallas criptográficas (exposición previa de datos sensibles) y el Control de acceso roto (BAC). Hoy, nos centraremos en Inyecciones y Control de accesos roto.
Inyecciones
SQL es el software de base de datos más común que se utiliza, y aloja una gran cantidad de datos de pago, datos PII y registros internos de negocios.
Una Inyección SQL es un ataque que utiliza código SQL malintencionado para la manipulación de la base de datos de backend para acceder a información que no se pretendía mostrar.
El punto de partida para esto es un comando como el siguiente:
Esto devolverá TODAS las filas de la tabla «Usuarios», ya que OR 1=1 siempre es VERDADERO. Yendo más allá con esto, este método también devolverá contraseñas si las hay.
Imagínense un ataque como este que se realiza contra una gran compañía de redes sociales o un gran negocio de comercio electrónico, y se puede comenzar a ver cuántos datos sensibles pueden recuperarse con solo un comando.
Control de Accesos Roto
El Control de acceso roto (BAC) ha subido de rango en el top diez de OWASP desde el quinto hasta el más común de los riesgos de seguridad de aplicación web. Las 34 enumeraciones comunes de debilidades (CWE) mapeadas al control de acceso roto tuvieron más apariciones en aplicaciones que cualquier otra categoría durante la reciente prueba de OWASP.
Los tipos más comunes de BAC son la escalada de privilegios vertical y horizontal. La escalada de privilegios vertical ocurre cuando un usuario puede elevar sus privilegios y realizar acciones a las que no debería tener acceso.
El CVE-2019-0211, que fue una Escalada de Privilegios Locales de Apache. Esta vulnerabilidad crítica, de 2019, afectó a los servidores Apache HTTP que se ejecutan en sistemas Unix, especialmente los que utilizan las bibliotecas mod_prefork, mod_worker y mod_event.
Esto otorgó a los atacantes la capacidad de ejecutar scripts sin privilegios, lo que potencialmente llevó a la obtención de acceso a la raíz y a comprometer los servicios de alojamiento compartidos. Explotar esta falla requiere la manipulación de regiones de memoria compartida dentro de los procesos de trabajador de Apache, lo que debe hacerse antes de iniciar un reinicio de Apache.
A continuación se muestra una captura de pantalla del código de prueba de concepto. Como se puede ver, se requiere un cierto nivel de habilidad técnica en este sentido, sin embargo, la escalada de privilegios verticales también puede ocurrir fácilmente cuando los permisos de un usuario son excesivamente permisivos o no se revocan cuando se van de un negocio.
Esto nos lleva de vuelta al principio de menor privilegio, un término ubicuo en todo el mundo de TI, que ahora se está volviendo más común a medida que nos damos cuenta de lo crucial que se han vuelto las aplicaciones web.
Escalada de Privilegios Horizontal es cuando un usuario obtiene acceso a los datos a los que no se supone que debe tener acceso, pero esos datos se mantienen al mismo nivel que sus propios permisos. Esto se puede ver con un usuario estándar que accede a los datos de otro usuario estándar. Si bien esto no debería permitirse, los privilegios no se elevan verticalmente, sino que se extienden horizontalmente. A veces se ve como más peligroso, ya que puede ocurrir sin levantar alertas en los sistemas de seguridad.
Con BAC cada vez más presente en los últimos años, es importante recordar:
Depender exclusivamente de la ofuscación no es un método suficiente para el control de acceso.
Si un recurso no está destinado a ser accesible para el público, debería denegarse el acceso de forma predeterminada.
Los desarrolladores deben especificar explícitamente el acceso permitido para cada recurso a nivel de código, con la denegación de acceso como la configuración predeterminada.
Mejores Prácticas – Lee entre las líneas (de código!)
Para mantener la seguridad, los desarrolladores deben verificar los datos entrantes, implementar consultas parametrizadas al interactuar con bases de datos y aplicar métodos efectivos de gestión de sesiones para proteger datos sensibles. Gran parte de esto depende tanto de la seguridad de los navegadores web como de la seguridad de fondo de los servidores web que entregan contenido web, lo que lleva a una segregación de deberes en la seguridad web.
El mayor problema que surge aquí es que, si bien los Firewalls de Aplicaciones Web (WAF), pueden mitigar estos riesgos, gran parte de la responsabilidad de la implementación segura del contenido web recae en los desarrolladores que hacen estos sitios juntos. La ciberseguridad a menudo puede convertirse en una idea tardía, prefiriendo la funcionalidad.
Ejemplo práctico – Validación de Entrada
La Validación de Entrada es una de las formas más simples y efectivas de implementar codificación segura, en este ejemplo para prevenir las inyecciones SQL.
Entrada del usuario: el usuario proporciona la entrada, por ejemplo: Sanitización: la entrada del usuario no se inserta directamente en la consulta SQL. Se sanea y se trata como datos, no como código SQL. Ejecución de la consulta: se ejecuta la consulta SQL con la entrada del usuario como parámetro: como tal, la consulta ingresa al backend como se muestra a continuación:
En este código, (user_input,) es una tupla que contiene la entrada del usuario. El controlador de la base de datos se encarga de escapar y manipular adecuadamente esta entrada. Asegura que la entrada se trate como un valor de datos, no como un código SQL ejecutable.
Si la entrada del usuario contiene código malicioso, como «105 or 1=1», no se ejecuta como SQL. En cambio, se trata como un valor a comparar con el UserId en la base de datos.
El controlador de la base de datos maneja automáticamente el escape de la entrada, evitando que afecte la estructura de la consulta SQL o introduzca vulnerabilidades de seguridad.
Firewalls de Aplicaciones Web (WAF)
Un WAF opera en la capa 7 del modelo OSI y actúa como un proxy inverso, asegurando que el tráfico del cliente pase por el WAF antes de ingresar al servidor de backend. Las reglas o políticas en el WAF protegen contra las vulnerabilidades documentadas que existen en estos servidores de backend y filtran el tráfico malicioso.
Hay una gran cantidad de WAF en el mercado, y todos estos pueden proporcionar una defensa sólida contra los ataques más novedosos, y contribuir bien a un enfoque de defensa en profundidad, la práctica de codificación segura es algo que garantiza que los cimientos de la aplicación web sean seguros y no se conviertan en víctima de ataques más complejos o novedosos en el futuro.
En la actualidad, los WAF se están moviendo hacia una mezcla de modelos de seguridad que utilizan tecnologías de análisis de comportamiento para detectar amenazas maliciosas y mitigar aún más las amenazas de bots más avanzados que se han aprovechado para ataques de poco esfuerzo en sitios web.
La principal desventaja de usar un WAF, además de la latencia y la sobrecarga HTTP añadidas, es el hecho de que un WAF puede ser eludido mediante el uso de una vulnerabilidad de día cero contra una aplicación web, que la codificación segura y la sanitización correcta pueden mitigar de manera más efectiva que la compensación de toda la seguridad de aplicaciones web a un WAF. Es importante recordar que un WAF es simplemente una capa de seguridad, y no toda la solución.
Respuesta y recuperación de incidentes
Las sugerencias de SecurityHQ para mitigar los ataques son:
Emplear un WAF como primera línea de defensa es fundamental para garantizar que las empresas puedan defenderse contra una gran cantidad de ataques. Asegúrate de que se utilicen algoritmos y protocolos estándar actualizados y sólidos, esto debe ir acompañado de una gestión adecuada de claves. Encriptar datos en tránsito con protocolos seguros como TLS con cifrados de secreto adelante (FS), priorización de cifrado por el servidor. Hacer cumplir la encriptación mediante directivas como la Seguridad del transporte estricta de HTTP (HSTS). Habilitar estrategias de gestión de bots en sitios web y tener un plan de respuesta a incidentes documentado. Asegúrate de que existan prácticas de desarrollo seguras, con un proceso documentado de prueba de nuevas funcionalidades en aplicaciones web y garantizar que se implemente la validación de entrada.
Esto debe ir acompañado de garantizar el principio de menor privilegio.
Realizar pruebas de vulnerabilidades con frecuencia, con la Gestión de Vulnerabilidades y la Defensa Gestionada con las herramientas de IBM, y hacer un seguimiento de las versiones de los componentes.
Utilice una prueba de aplicación roja para descubrir vulnerabilidades que los escáneres no pueden encontrar.
Asegúrate de que los desarrolladores reciban capacitaciones regulares para mantenerse al día con las últimas tendencias de seguridad y amenazas emergentes.
Para obtener más información sobre estas amenazas, hable con un experto aquí. O si sospecha de un incidente de seguridad, puede reportar un incidente aquí.
Nota: Este artículo fue escrito expertamente por Tim Chambers, Gerente Senior de Ciberseguridad en SecurityHQ.
