La seguridad de aplicaciones web consta de una gran variedad de controles de seguridad que garantizan que una aplicación web:
- Funciona como se esperaba.
- No se puede explotar para operar fuera de los límites.
- No puede iniciar operaciones que no se supone que debe realizar.
Las aplicaciones web se han vuelto omnipresentes después de la expansión de la Web 2.0, que las plataformas de redes sociales, los sitios web de comercio electrónico y los clientes de correo electrónico saturaron los espacios de Internet en los últimos años.
A medida que las aplicaciones consumen y almacenan datos aún más confidenciales y completos, se convierten en un objetivo cada vez más atractivo para los atacantes.
Métodos de ataque comunes
Las tres vulnerabilidades más comunes que existen en este espacio son inyecciones (SQL, código remoto), fallas criptográficas (exposición previa de datos confidenciales) y control de acceso roto (BAC). Hoy nos centraremos en las inyecciones y el control de acceso 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 comerciales internos.
Una inyección SQL es un ataque que utiliza código SQL malicioso para la manipulación de la base de datos backend para acceder a información que no estaba destinada a mostrarse.
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.
Imagine un ataque como este realizado contra una gran empresa de redes sociales o una gran empresa de comercio electrónico y podrá comenzar a ver cuántos datos confidenciales se pueden recuperar con un solo comando.
Control de acceso roto
El control de acceso roto (BAC) ha ascendido en el ranking de los diez primeros de OWASP, pasando del quinto lugar al riesgo de seguridad de aplicaciones web más común. Las 34 enumeraciones de debilidades comunes (CWE) asignadas al control de acceso roto tuvieron más ocurrencias en las aplicaciones que cualquier otra categoría durante las pruebas recientes de OWASP.
Los tipos más comunes de BAC son la escalada de privilegios vertical y horizontal. La escalada de privilegios verticales ocurre cuando un usuario puede elevar sus privilegios y realizar acciones a las que no deberían 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 HTTP Apache que se ejecutan en sistemas Unix, especialmente aquellos que utilizan las bibliotecas mod_prefork, mod_worker y mod_event.
Esto otorgaba a los atacantes la capacidad de ejecutar scripts sin privilegios, lo que potencialmente conducía al acceso raíz y comprometía los servicios de alojamiento compartido. Explotar esta falla requiere la manipulación de regiones de memoria compartida dentro de los procesos de trabajo de Apache, lo que debe realizarse antes de iniciar un reinicio elegante de Apache.
La siguiente es una captura de pantalla del código POC. Como se puede ver, se requiere un cierto nivel de habilidad técnica a este respecto; sin embargo, la escalada vertical de privilegios puede ocurrir con la misma facilidad cuando los permisos de un usuario son demasiado permisivos o no se revocan cuando abandonan una empresa.
Esto nos lleva de regreso al principio de privilegio mínimo, un término omnipresente que se encuentra en todo el mundo de TI, que ahora se está volviendo más común a medida que nos damos cuenta de cuán cruciales se han vuelto las aplicaciones web.
La escalada de privilegios horizontal se produce cuando un usuario obtiene acceso a datos a los que se supone que no debe tener acceso, pero esos datos se mantienen al mismo nivel que sus propios permisos. Esto se puede ver cuando un usuario estándar accede a los datos de otro usuario estándar. Si bien esto no debería permitirse, los privilegios no aumentan verticalmente, sino que se extienden horizontalmente. A veces esto se considera más peligroso, ya que puede ocurrir sin generar ninguna alerta en los sistemas de seguridad.
Dado que BAC está cada vez más presente en los últimos años, es importante recordar:
- Depender únicamente de la ofuscación no es un método suficiente para el control de acceso.
- Si un recurso no está destinado a ser accesible al público, se le debe negar 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 configuración predeterminada.
Mejores prácticas: lectura entre 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 eficaces de gestión de sesiones para proteger los datos confidenciales. Gran parte de esto depende tanto de la seguridad de los navegadores web como de la seguridad de back-end de los servidores web que entregan contenido web, lo que lleva a una segregación de funciones en materia de 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 crearon estos sitios. La ciberseguridad a menudo puede convertirse en una idea de último momento, prefiriéndose la funcionalidad.
Ejemplo práctico: validación de entradas
La validación de entrada es la forma más sencilla y eficaz de implementar codificación segura, en este ejemplo para evitar inyecciones de SQL.
- Entrada del usuario: el usuario proporciona información, por ejemplo:
- Saneamiento: la entrada del usuario no se inserta directamente en la consulta SQL. Se desinfecta y se trata como datos, no como código SQL.
- Ejecución de consulta: La consulta SQL se ejecuta 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 manejar adecuadamente esta entrada. Garantiza 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 o 1=1», no se ejecuta como SQL. En cambio, se trata como un valor que se compara con el ID de usuario 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, lo que garantiza que el tráfico del cliente pase a través del WAF antes de ingresar al servidor backend. Las reglas o políticas del WAF protegen contra las vulnerabilidades documentadas que están presentes en estos servidores backend y filtran el tráfico malicioso.
Hay una gran cantidad de WAF en el mercado, y todos ellos pueden proporcionar una fuerte defensa contra los ataques más novedosos y contribuir bien a un enfoque de defensa en profundidad; la práctica de la codificación segura es algo que garantiza que los cimientos de la aplicación web sean sólidos. seguro y no será víctima de ataques más complejos o novedosos en el futuro.
Actualmente, los WAF están avanzando hacia una combinación 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 bajo esfuerzo a sitios web.
El principal inconveniente de utilizar un WAF, además de la latencia adicional y la sobrecarga de HTTP, es el hecho de que se puede evitar un WAF mediante el uso de un exploit de día 0 contra una aplicación web, que la codificación segura y la desinfección correcta pueden mitigar de manera más efectiva que compensando toda la seguridad de las aplicaciones web a un WAF. Es importante recordar que un WAF es simplemente una capa de seguridad y no la solución completa.
Respuesta y recuperación de incidentes
Sede de seguridad sugerencias para mitigar los ataques:
- Emplear un WAF como primera línea de defensa es fundamental para garantizar que las empresas puedan defenderse contra un gran volumen de ataques.
- Asegúrese de que se utilicen algoritmos y protocolos estándar sólidos y actualizados; esto debe combinarse con una gestión de claves adecuada.
- Cifre los datos en tránsito con protocolos seguros como TLS con cifrados de secreto directo (FS), priorización de cifrado por parte del servidor. Aplique el cifrado mediante directivas como HTTP Strict Transport Security (HSTS).
- Habilite estrategias de gestión de bots en sitios web y tenga un plan de respuesta a incidentes documentado.
- Asegúrese de que existan prácticas de desarrollo seguras, con un proceso documentado para probar nuevas funciones en aplicaciones web y asegúrese de que se implemente la validación de entradas.
- Esto debería ir acompañado de la garantía del principio de privilegio mínimo.
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 por Tim Chambers, gerente senior de seguridad cibernética de SecurityHQ.