Detectando Fallos de Seguridad CORS con CodeQL: Modelado de Frameworks para Proteger tus Aplicaciones Web

La seguridad de las aplicaciones web es una carrera constante contra las vulnerabilidades emergentes. Una de las áreas críticas es la configuración de CORS (Cross-Origin Resource Sharing), que, si se implementa incorrectamente, puede permitir a atacantes eludir la autenticación y acceder a servicios internos. En este artículo, exploraremos cómo usar CodeQL para modelar frameworks CORS y detectar configuraciones inseguras.

¿Por qué Modelar Frameworks CORS con CodeQL?

Las implementaciones manuales de CORS y el uso inseguro de frameworks pueden generar vulnerabilidades graves. CodeQL, un motor de análisis semántico de código, ofrece una forma versátil de analizar estructuras, funciones y librerías importadas, superando las limitaciones de herramientas más simples como grep. La naturaleza basada en configuración de los frameworks CORS los hace ideales para el análisis con CodeQL.

Modelando Cabeceras en CodeQL

Al trabajar con CodeQL, es esencial revisar las consultas y frameworks existentes para evitar duplicaciones. CodeQL ya incluye consultas CORS para muchos casos comunes. La implementación más básica de CORS implica configurar manualmente las cabeceras Access-Control-Allow-Origin y Access-Control-Allow-Credentials. Modelando los frameworks (por ejemplo, Django, FastAPI y Flask), CodeQL puede identificar dónde se establecen estas cabeceras y buscar valores vulnerables.

Consideremos este ejemplo en Go, donde se permite el acceso a recursos no autenticados desde cualquier sitio web:

func saveHandler(w http.ResponseWriter, r *http.Request) {
    w.Header().Set("Access-Control-Allow-Origin", "*")
}

Esto es problemático para aplicaciones sin autenticación, como herramientas locales, ya que cualquier endpoint peligroso podría ser explotado. CodeQL modela el método Set del framework http de Go para encontrar escrituras de cabeceras relacionadas con la seguridad. La clase HeaderWrite en HTTP.qll se extiende para modelar todas las escrituras de cabeceras.

/** Provides a class for modeling new HTTP header-write APIs. */nmodule HeaderWrite {
    /**
     * A data-flow node that represents a write to an HTTP header.
     *
     * Extend this class to model new APIs. If you want to refine existing API models,
     * extend `HTTP::HeaderWrite` instead.     */
   abstract class Range extends DataFlow::ExprNode {
      /** Gets the (lower-case) name of a header set by this definition. */
      string getHeaderName() { result = this.getName().getStringValue().toLowerCase() }

Métodos como getHeaderName y getHeaderValue facilitan el desarrollo de consultas de seguridad, como la detección de configuraciones incorrectas de CORS. Un patrón aún más peligroso es reflejar la cabecera Origin de la solicitud y permitir credenciales:

func saveHandler(w http.ResponseWriter, r *http.Request) {
    w.Header().Set("Access-Control-Allow-Origin", r.Header.Get("Origin"))
    w.Header().Set("Access-Control-Allow-Credentials", "true")
}

Esto permite que un sitio web malicioso realice solicitudes en nombre del usuario autenticado, comprometiendo toda la aplicación. CodeQL permite modelar las cabeceras, buscando métodos y valores específicos para identificar estructuras de código relevantes para vulnerabilidades CORS.

/** * An `Access-Control-Allow-Credentials` header write.
 */
class AllowCredentialsHeaderWrite extends Http::HeaderWrite {
    AllowCredentialsHeaderWrite() {
        this.getHeaderName() = headerAllowCredentials()
    }
}

/**
 * predicate for CORS query.
 */
npredicate allowCredentialsIsSetToTrue(DataFlow::ExprNode allowOriginHW) {
    exists(AllowCredentialsHeaderWrite allowCredentialsHW |
        allowCredentialsHW.getHeaderValue().toLowerCase() = "true"

La clase HTTP::HeaderWrite sirve como superclase para AllowCredentialsHeaderWrite, que encuentra todas las escrituras de cabeceras con el valor Access-Control-Allow-Credentials. Esta información se utiliza en la consulta de configuración incorrecta de CORS para verificar si las credenciales están habilitadas.

Modelando Frameworks en CodeQL

Muchos desarrolladores prefieren usar frameworks CORS en lugar de configurar las cabeceras manualmente. Estos frameworks suelen emplear middleware en el router de la aplicación para añadir las cabeceras necesarias. Al modelar un framework CORS en CodeQL, se representan las estructuras y métodos relevantes que definen la política CORS. Una vez modelados, la consulta verifica que la estructura se utilice realmente en el código.

En Go, frameworks como Gin CORS son comunes. Aquí un ejemplo de configuración:

package main

import (
  "time"
  "github.com/gin-contrib/cors"
  "github.com/gin-gonic/gin"
)

func main() {
  router := gin.Default()  router.Use(cors.New(cors.Config{
    AllowOrigins:     []string{"https://foo.com"
},
    AllowMethods:     []string{"PUT", "PATCH"},
    AllowHeaders:     []string{"Origin"},
    ExposeHeaders:    []string{"Content-Length"},
    AllowCredentials: true,
    AllowOriginFunc: func(origin string) bool {
      return origin == "https://github.com"
    },
  }))
  router.Run()
}

Después de modelar el método router.Use y cors.New, y verificar que la estructura cors.Config se use en una función router.Use, se deben inspeccionar todas las estructuras cors.Config para asegurar que tengan cabeceras apropiadas.

Es crucial modelar campos como AllowOrigins, AllowCredentials y AllowOriginFunc. A continuación, un extracto de cómo se modela la configuración de Gin:

/**
 * A variable of type Config that holds the headers to be set.
 */
class GinConfig extends Variable {
    SsaWithFields v;

    GinConfig() {
      this = v.getBaseVariable().getSourceVariable() and
      v.getType().hasQualifiedName(packagePath(), "Config")
    }

    /**
     * Get variable declaration of GinConfig
     */
    SsaWithFields getV() { result = v }
}

El tipo Config se modela utilizando SSAWithFields, lo que permite rastrear la variable a la que se asigna la estructura y dónde se utiliza. Esto es útil para configuraciones que se inicializan de esta manera:

func main() {
...
// We can now track the corsConfig variable for further updates,such as when one of the fields is updated.
corsConfig:= cors.New(cors.Config{
...
})}

Luego, se buscan todas las instancias donde se escribe la variable para entender los valores de las propiedades asignadas y determinar si la configuración CORS es incorrecta.

/**
 * A write to the value of Access-Control-Allow-Origins header
 */
class AllowOriginsWrite extends UniversalOriginWrite {
    DataFlow::Node base;

    // This models all writes to the AllowOrigins field of the Config type
    AllowOriginsWrite() {

      exists(Field f, Write w |
        f.hasQualifiedName(packagePath(), "Config", "AllowOrigins") and
        w.writesField(base, f, this) and

        // To ensure we are finding the correct field, we look for a write of type string (SliceLit)
        this.asExpr() instanceof SliceLit
      )

    }

    /**
     * Get config variable holding header values
     */
    override GinConfig getConfig() {
      exists(GinConfig gc |
        (
          gc.getV().getBaseVariable().getDefinition().(SsaExplicitDefinition).getRhs() =
            base.asInstruction() or
          gc.getV().getAUse() = base
        ) and
        result = gc
      )
    }
  }

La función getConfig devuelve el GinConfig previamente creado, permitiendo verificar que las escrituras a las cabeceras relevantes afecten la misma estructura de configuración. Esto evita resaltar configuraciones que permiten credenciales pero no tienen orígenes vulnerables.

Escribiendo Consultas de Configuración Incorrecta de CORS en CodeQL

Los problemas de CORS se clasifican en dos tipos: sin credenciales (buscando * o null) y con credenciales (buscando reflexión de origen o null). Para simplificar, se puede crear una consulta para cada tipo de vulnerabilidad. En Go, CodeQL tiene una consulta para CORS con credenciales, ya que es aplicable a todas las aplicaciones.

Aquí cómo se utilizan los modelos en la consulta de configuración incorrecta de CORS en Go:

from DataFlow::ExprNode allowOriginHW, string message
where
  allowCredentialsIsSetToTrue(allowOriginHW) and
  (
    flowsFromUntrustedToAllowOrigin(allowOriginHW, message)
    or
    allowOriginIsNull(allowOriginHW, message)
  ) and
  not flowsToGuardedByCheckOnUntrusted(allowOriginHW)
...
select allowOriginHW, message

Esta consulta busca vulnerabilidades críticas, verificando si las credenciales están permitidas y si los orígenes permitidos provienen de una fuente remota o están codificados como null. Para evitar falsos positivos, se verifica si existen protecciones, como comparaciones de cadenas, antes de que la fuente remota llegue al origen.

La función allowCredentialsIsSetToTrue se define como:

/**
 * Holds if the provided `allowOriginHW` HeaderWrite's parent ResponseWriter
 * also has another HeaderWrite that sets a `Access-Control-Allow-Credentials`
 * header to `true`.
 */
predicate allowCredentialsIsSetToTrue(DataFlow::ExprNode allowOriginHW) {
  exists(AllowCredentialsHeaderWrite allowCredentialsHW |
    allowCredentialsHW.getHeaderValue().toLowerCase() = "true"
  |
    allowOriginHW.(AllowOriginHeaderWrite).getResponseWriter() =
      allowCredentialsHW.getResponseWriter()
  )
  or
...

Se utiliza AllowCredentialsHeaderWrite para comparar cabeceras y filtrar las escrituras que no tienen credenciales configuradas.

  exists(UniversalAllowCredentialsWrite allowCredentialsGin |
    allowCredentialsGin.getExpr().getBoolValue() = true
  |
    allowCredentialsGin.getConfig() = allowOriginHW.(UniversalOriginWrite).getConfig() and
    not exists(UniversalAllowAllOriginsWrite allowAllOrigins |
      allowAllOrigins.getExpr().getBoolValue() = true and
      allowCredentialsGin.getConfig() = allowAllOrigins.getConfig()
    )
    or
    allowCredentialsGin.getBase() = allowOriginHW.(UniversalOriginWrite).getBase() and
    not exists(UniversalAllowAllOriginsWrite allowAllOrigins |
      allowAllOrigins.getExpr().getBoolValue() = true and
      allowCredentialsGin.getBase() = allowAllOrigins.getBase()
    )
  )
}

Si CORS no se configura a través de una cabecera, se buscan frameworks CORS utilizando UniversalAllowCredentialsWrite. Para filtrar las instancias donde el valor de Origin es "*", se utiliza not en UniversalAllowAllOriginsWrite.

Consideraciones Adicionales

Las consultas CodeQL para detectar vulnerabilidades CORS deben adaptarse a cada framework web debido a las diferencias en las implementaciones y los patrones de vulnerabilidad. Por ejemplo, Gin CORS tiene una función AllowOriginFunc que puede anular AllowOrigins. Una mejora sería escribir una consulta CodeQL que busque AllowOriginFuncs que siempre retornen true, lo que resultaría en una vulnerabilidad de alta gravedad si se combina con credenciales.

Conclusión

Comprender el comportamiento de los frameworks web y las cabeceras con CodeQL facilita la detección de problemas de seguridad y reduce la posibilidad de que las vulnerabilidades lleguen al código de producción. El soporte para consultas de configuración incorrecta de CORS en CodeQL está en constante crecimiento, y siempre hay margen de mejora por parte de la comunidad.

GitHub Code Security puede ayudarte a proteger tu proyecto detectando y sugiriendo soluciones para errores como la configuración incorrecta de CORS.

Fuente: Github Blog