Buenas tardes, en este décimo capítulo de la serie Arquitectura de Sistemas Seguros para Aplicaciones Web en Salud Digital presentaré el Vector Aplicación con respecto a sus amenazas principales y recomendaciones para evitarlas.
Particularmente veremos los ataques que interactúan directamente con la aplicación, mientras que los ataques que se enfocan en las vulnerabilidades de infraestructura serán tratados en los capítulos sobre el Vector Red.
Ataques de Inyección
La principal forma en la que un atacante puede afectar a una aplicación al interactuar con ella es diseñar maliciosamente sus solicitudes, de manera que sus respuestas entreguen información sensible directamente o indirectamente obtniendo control sobre la aplicación web y posiblemente del sistema operativo subyacente. Éstas estrategias son llamadas ataques de inyección y existen de distintos tipos
-
Server Side Template Injections
Consisten en aprovechar el uso de plantillas en el servidor web, de manera que el contenido de las solicitudes enviadas reemplazará las variables presentes en las plantillas. Este contenido en vez de contener los valores esperados (por ejemplo, usuario y contraseña) podría contener código arbitrario que permitiría manipular a voluntad el comportamiento del servidor web.
Uno de estos ataques es SQL injection (SQLi), actualmente amenaza número 1 en OWASP Top 10 (lista de las 10 amenazas web más importantes), consiste en incluir código SQL en las solicitudes enviadas de manera que en el momento en que las correspondientes sentencias SQL vayan a ser ejecutadas, estas sean modificadas, potencialmente solicitando información sensible o manipulando información sin los privilegios correspondientes.
Los ataques SQLi comienzan cuando un hacker mediante prueba y error detecta una vulnerabilidad en el uso de SQL por parte de una aplicación web. Posteriormente éste diseña una solicitud que termina siendo aceptada y ejecutada por la base de datos, lo que eventualmente le permite ver y modificar registros como un administrador de la base de datos. Obtenida desde bartosha.com. -
XML External Entities (XXE)
XML es un formato de serialización muy empleado en aplicaciones web junto con JSON y YAML, sin embargo para este formato en particular existe una vulnerabilidad considerada actualmente número 4 en OWASP Top 10. Esta vulnerabilidad se basa en el uso malicioso de la funcionalidad External Entities, la que consiste en la posibilidad por defecto de XML de hacer referencia a recursos no definidos al interior del archivo XML, como por ejemplo URLs arbitrarias y archivos al interior del servidor web receptor de la solicitud.
Para que este ataque pueda tener éxito, la aplicación debe emplear XML para comunicar información entre clientes y servidor web (en vez de por ejemplo formato JSON) o tener como fin el procesamiento de código XML confeccionado por sus usuarios.
-
Cross Site Scripting (XSS)
Actualmente 7 en OWASP Top 10 consiste en la inyección de Javascript en el frontend de la aplicación web, lo que potencialmente modificaría arbitrariamente la percepción de los usuarios sobre ésta. Existen 2 tipos
El XSS reflejado consiste en la inyección por parte del mismo usuario sin que éste sea consciente de hacerlo, por ejemplo siguiendo un link recibido en un email que hace referencia a un sitio vulnerable a XSS pero además incluye código Javascript como parte de la url.
El XSS persistente consiste en la inyección, normalmente por parte de un atacante de código junto con texto normal en una solicitud que quedará almacenada en una base de datos, como por ejemplo un post en un blog o red social vulnerable a XSS. Luego todo usuario que acceda al sitio (y que abra el mensaje en caso de no estar visible por defecto), será víctima del código Javascript inyectado.
En un ejemplo de XSS persistente, un atacante logra almacenar un script en la base de datos que se encarga de enviar a un servidor propio las cookies de sesión del visitante actual de la página. Luego cada vez que un usuario visite la página, el atacante obtendrá acceso a sus cookies de sesión, pudiendo ingresar al sitio con sus privilegios. Obtenida desde imperva.com -
Insecure Deserialization
Actualmente 8 en OWASP Top 10 consiste en la deserialización del contenido de las solicitudes recibidas, las que en el mismo procedimiento de deserialización pueden ejecutar código malicioso, incluso llegando a reclamar el control absoluto de los recursos del servidor web.
-
Cross Site Request Forgery (CSRF)
Número 8 en OWASP Top 10 de la versión anterior (2013, actual 2017) consiste en aprovechar el comportamiento de los browsers, en el que éstos envían automáticamente las cookies con las credenciales de los usuarios en cada solicitud. De este modo cuando un usuario ingresa a un sitio malicioso, éste puede emplear la sesión activa del usuario en la aplicación objetivo y realizar acciones para las que éste tiene privilegios en aquella plataforma.
Por ejemplo, enviar un mensaje con información sensible al usuario del atacante en esa plataforma y luego eliminar la cuenta de la víctima de manera que el usuario no pueda saber lo que ocurrió.
En un ejemplo de CSRF, un atacante confecciona y envía un link a una víctima de manera que el link lo redirecciona a una página en la que está actualmente autenticada, permitiendo a la solicitud almacenada en el link tener los privilegios para transferir fondos a la cuenta del atacante. Obtenida desde imperva.com
Recomendaciones
-
Validar creación y recepción de las solicitudes. Cada campo de un formulario y cada solicitud recibida por el servidor web debe ser validada con el objetivo no solo de que el usuario haya cometido un error, sino que para evitar un comportamiento maligno en cada una de ellas. Esto se puede lograr limitando los valores que estas puedan tener, por ejemplo mediante expresiones regulares, restricciones de tipo, rango y de longitud.
También es posible añadir un Web Application Firewall (WAF) que se encargue de bloquear solicitudes que poseen patrones conocidos como malware, sin embargo siguiendo el principio de defensa en profundidad la aplicación por su cuenta debería validar efectivamente las solicitudes, tanto en su construcción mediante campos de formulario como en su recepción en el servidor web. Esto permitiría seguir estando protegido en caso de que el WAF llegue a dejar de estar inactivo, o de que los atacantes hayan descubierto una vulnerabilidad en el WAF o en caso de que su aplicación tenga una vulnerabilidad distinta al común de las aplicaciones.
Las bases de datos poseen mecanismos estandarizados para parametrizar las solicitudes que reciben, por ejemplo este artículo de OWASP explica cómo emplear Query Parametrization para evitar SQL injection.
-
Evitar implementar formatos complejos para el envío de solicitudes como XML para cuando sea posible, y reemplazarlos por unos más simples como JSON y cuando sea necesario verificar que su procesador de XML está actualizado, deshabilitar procesamiento XML de DTD y External Entities como explica OWASP y emplear herramientas como XSD para validar las solicitudes XML.
Los ataques XXE envían una solicitud que contiene XML malicioso para aplicaciones que emplean XML para comunicar información entre los clientes y el servidor web. El servidor web recibe la solicitud y entrega el contenido a un intérprete de XML, el que por ejemplo se encarga de compartir el contenido del archivo /etc/passwd con el atacante. Obtenida desde securitysouls.com. -
Implementar Content Security Policy. Este método es el más fuerte para potencialmente eliminar por completo la posibilidad de XSS, sin embargo hay que tener en cuenta que este mecanismo es relativamente reciente y la mayoría de las aplicaciones no están diseñadas para implementarlo fácilmente, por lo que es recomendable realizar pruebas antes de añadirla a su aplicación.
-
Además de validar e implementar un tipado estricto para la deserialización de solicitudes, realizar su deserialización en un ambiente sin privilegios cuando sea posible. Los ataques de deserialización han demostrado ser robustos ante distintos tipos de medidas de prevención, por lo que es recomendable limitar el alcance de las consecuencias de su éxito. Se recomienda también registrar especialmente los resultados de la deserialización, incluyendo los casos en que resulten en errores y excepciones.
Un ejemplo de Insecure Deserialization en conjunto con SQLi envía una solicitud serializada mediante JSON, la que contiene como nombre código SQL que realiza el trabajo de un típico ataque SQLi que obtiene información adicional a la normalmente entregada por la aplicación. Obtenida desde twitter.com. -
Emplear tokens de autenticación en los headers en vez de en las cookies. Los ataques CSRF dependen de que las cookies sean compartidas automáticamente en todas las solicitudes, sin embargo si la sesión no se encuentra en ellas las solicitudes privilegiadas no serán aceptadas por el servidor web. Adicionalmente la implementación de la SameSite flag en las cookies impediría el uso maliciosa de estas en intentos de CSRF.
En el próximo capítulo veremos las demás vulnerabilidades principales a tener en cuenta durante el desarrollo de una aplicación web, tanto en general como en salud digital
→ Link al Capítulo anterior
→ Link al Capítulo siguiente
Referencias
-
Guía completa para evitar SQLi SQL Injection | Complete Guide - YouTube
-
XSS Cross Site Scripting (XSS) Software Attack | OWASP Foundation
-
CSRF y SSRF The difference between cross-site and server-side request forgery - Infosec Resources
-
Explicación de Cross Origin Policy Same-Origin Policy And Cross-Origin Resource Sharing (CORS)
-
Cómo evitar CSRF Cross-Site Request Forgery (CSRF) and How to Prevent It | Netsparker
-
OWASP Top 10 OWASP Top Ten Web Application Security Risks | OWASP
-
CWE Top 25 CWE -