Novedades de OWASP Top 10 2021 (III)

Tras comentar en el primer post de la serie algunos detalles sobre la nueva versión de OWASP Top 10, y en el segundo la nueva categoría A08, fallos de integridad del software y de los datos, en este tercer y último post vamos a analizar la categoría A10: Falsificación de solicitudes del lado del servidor (Server-Side Request Forgery, SSRF), así como las posibilidades de mitigación de este tipo de vulnerabilidades.

A10: Falsificación de solicitudes del lado del servidor (Server-Side Request Forgery, SSRF)

Se está en riesgo de sufrir ataques SSRF cuando una aplicación permite obtener un recurso remoto sin validar la URL que proporciona el usuario. Este tipo de ataque puede evitar la protección que brinda el cortafuegos, la VPN o los controles de acceso.

Por ejemplo, cuando una aplicación permite especificar una URL a la que será redirigida la petición inicial, si no filtramos la URL a la que se redireccionará, el atacante podría aprovechar para indicar una dirección cualquiera.

Los ataques podrían consistir en peticiones del tipo:

o

Por lo que si no se filtran las URL de redirección y los recursos no están protegidos, permitirían que el atacante pudiese acceder a ellos.

Una de las causas de estos ataques es el código de las aplicaciones y que permite que se acceda desde la misma a direcciones a las que no se debería acceder, de modo que el atacante puede enviar solicitudes desde la aplicación a recursos tanto internos como externos y recibir las respuestas.

Los ataques por SSRF están aumentando debido a los servicios en la nube y el progresivo aumento de la complejidad en la arquitecturas.

La mitigación de estos ataques la podemos llevar a cabo desde varios frentes:

• Desde la capa de red.
• Desde la capa de aplicación.
• A nivel general.

2.1 Mitigación desde la capa de red

A continuación se enumeran algunas formas de mitigar estos ataques desde la capa de red.

• Segmentar las redes. Usando por ejemplo VLANs, para evitar que se extienda el ataque en una parte de la red a otras partes de la misma. Sería el mismo principio que se usa en un barco con compartimentos; esto permite que si se produce una vía de agua y no se puede achicar, el agua no invada los otros compartimentos.

• Denegar siempre por defecto. El cortafuegos debería bloquear todo el tráfico de la intranet, dejando solo pasar el que se permita de manera explícita.

• Registrar el tráfico de red cuando se acepta o deniega una petición. Así podríamos acudir a los registros para ver que sucede, en una situación ideal, deberíamos también poder crear alertas que nos avisen de comportamientos sospechosos.

2.2 Mitigación desde la capa de aplicación

A continuación se enumeran algunas formas de mitigación que se pueden llevar a cabo desde la capa de aplicación.

• Sanear y validar los datos de entrada del usuario, algo obligatorio en esta y otras situaciones, ya que es uno de los motivos por el que se producen los ataques de inyección.
• Usar listas blancas para permitir solo los esquemas de URL, puerto y destino a los que decidamos que se podrá acceder. Con las listas blancas se permite solo lo que se especifica en ellas y se deniega todo lo demás.
• Deshabilitar las redirecciones HTTP si no son estrictamente necesarias, ya que se debe incluir la funcionalidad que realmente se necesite, y el resto de funcionalidad deshabilitarse.
• Evitar usar listas de denegación o expresiones regulares ya que se pueden evitar y no servirían de mucho.

2.3 Mitigación a nivel general

A continuación se enumeran algunas de las formas de mitigar estos ataques, aunque ahora, a nivel general.

• Controlar el tráfico de localhost, ya que normalmente se descuida un poco su seguridad, al no estar accesible directamente desde la LAN o Internet. Con este ataque hemos visto que se debe tener también en cuenta.
• Dotar de accesos VPN en la medida de lo posible a los usuarios de nuestra organización. Esto limita la exposición de nuestros servicios a redes externas o Internet, al conceder acceso únicamente a nuestros usuarios desde la red local. Además podemos registrar de una manera más precisa los accesos a los servicios, pudiendo detectar patrones de comportamiento sospechosos.
• Verificar la respuesta a la hora de efectuar la redirección. Deberemos comprobar que la respuesta es la esperada. Por ejemplo, si redirigimos a una página del servidor de repositorios de código fuente, deberíamos comprobar que la página a la que redirigiremos la petición pertenece al servidor y no es otra página.
• Deshabilitar los esquemas de URI no utilizados, al igual que en otros riesgos donde la recomendación es deshabilitar los elementos que no se estén usando o que no sean necesarios. En este riesgo debemos recomendar que los servicios y puertos no utilizados estén restringidos, permitiendo solo el acceso a los que se necesiten o se deban acceder, especificándolos de manera explícita con listas blancas. Para un listado de esquemas URI, puede visitarse el RFC 3986. Uniform Resource Identifier (URI): Generic Syntax: https://datatracker.ietf.org/doc/html/rfc3986.

Una lista de ejemplos recopilados del RFC referenciado de URIs que posiblemente no necesitemos serían:

Nótese que además del dominio, también habría que comprobar que se permite el esquema. Por ejemplo: https://example.com y ftp://example.com comparten el dominio example.com, pero se diferencian en su esquema, https o ftp respectivamente.

• Habilitar autenticación para todos los servicios de red, en especial para aquellos que por defecto no requieran de autenticación, como por ejemplo: Memcached, Redis, Elasticsearch o MongoDB. Además recomendamos que se configuren y habiliten protocolos seguros como HTTPS o TLS para el acceso a los mismos.

A raíz de este punto se debería referir el concepto de “Zero Trust en redes corporativas”, que podría interpretarse como “Confianza cero en redes corporativas”. Puede encontrarse dicha información en la web “Ángeles” del Centro Criptológico Nacional, en el apartado de “Ciberconsejos”, sección “Amenazas”, donde existe un documento a modo de resumen y un vídeo explicativo en Español.

En el documento referenciado se dice una frase significativa para entender la magnitud de Zero Trust: “El modelo tradicional basado en el concepto de perímetro, donde se protege el acceso desde fuera y el usuario interno es de confianza, ya no es válido“, con lo que estamos ante el cambio de un paradigma clásico donde se definía un perímetro para protegernos del exterior y podíamos confiar en los elementos internos.

Se anima al lector a visitar los enlaces adicionales del contenido referido para ampliar los conceptos. En la web mencionada se pueden encontrar documentos y vídeos sobre diversos temas relacionados con formato de infografía, útiles para comprender de una manera visual el concepto. Están acompañados de vídeos y en algunos casos de informes donde se amplía la información, además de consejos y soluciones.

Con este artículo cerramos la serie relacionada con las novedades de OWASP Top 10 2021. Esperamos que haya sido de su agrado y sobretodo que le resulte útil.

Muchas gracias a tod@s.