El acceso no controlado a recursos críticos o confidenciales puede afectar significativamente a una organización de varias maneras, incluida la divulgación o manipulación de datos críticos.

El acceso no controlado a recursos críticos o confidenciales puede afectar significativamente a una organización de varias maneras, incluida la divulgación o manipulación de datos críticos.

Las configuraciones de acceso dinámico pueden exponer los sistemas y amplían la superficie de ataque de una organización. Los servicios abiertos a la interacción con el público suelen estar sujetos a análisis y sondeos casi continuos por parte de entidades malintencionadas.

Esto es especialmente problemático cuando se descubre y publica una vulnerabilidad de día cero para un servicio expuesto, como Heartbleed. Los atacantes pueden perseguir y buscar activamente sistemas expuestos y sin revisión que puedan aprovechar.

El acceso no controlado a recursos críticos o confidenciales puede afectar significativamente a una organización de varias maneras, incluida la divulgación o manipulación de datos críticos.

El acceso no controlado a recursos críticos o confidenciales puede afectar significativamente a una organización de varias maneras, incluida la divulgación o manipulación de datos críticos.

El acceso no controlado a recursos críticos o confidenciales puede afectar significativamente a una organización de varias maneras, incluida la divulgación o manipulación de datos críticos.

Los canales de comunicación de datos insuficientemente protegidos pueden poner los datos críticos de la organización en riesgo de robo, manipulación o divulgación.

Codificar una contraseña permite que todos los desarrolladores de proyectos vean la contraseña. También dificulta la solución del problema. Una vez que el código está en producción, nadie puede cambiar la contraseña sin aplicar revisiones al software. Si la cuenta protegida por la contraseña está en riesgo, los propietarios del sistema deben elegir entre seguridad y disponibilidad.

El conector de la base de datos de Mule debe forzar el transporte cifrado y verificar los certificados del servidor de la base de datos. Si las propiedades de conexión de la base de datos relevantes no se especifican o se configuran incorrectamente, las conexiones resultantes exponen los datos a acceso no autorizado, manipulación y posible robo.

HTTPS utiliza TLS (seguridad de la capa de transporte) para cifrar las solicitudes y respuestas HTTP habituales. Garantiza la integridad y confidencialidad de cualquier intercambio de datos.

Un HTTP Listener Connector no cifra su comunicación si su protocolo no se especifica o se establece en HTTP. Esto expone los datos a acceso no autorizado, manipulaciones y posible robo.

Ejemplo 1: La siguiente configuración de Mule establece el protocol de un HTTP Listener Connector (listener-connection) a HTTP. Como resultado, las conexiones con HTTP Listener no son seguras.

    <http:listener-config name="http_listener_config">
        <http:listener-connection host="example.com" port="8080" protocol="HTTP">
...
        </http:listener-connection>
    </http:listener-config>

La verificación de la certificación es esencial para confirmar la identidad de la contraparte para una comunicación segura. Un elemento tls:context define un conjunto de configuraciones de conexión TLS. Entre las configuraciones, el elemento tls:trust-store especifica un archivo que contiene certificados de autoridades de certificación de confianza que un cliente usa para verificar un certificado presentado por un servidor. De forma predeterminada, el motor de tiempo de ejecución de Mule verifica el certificado del servidor para cada conexión TLS.

Sin embargo, si el valor del atributo insecure del elemento tls:trust-store es true, los certificados de servidor se aceptan sin verificación.

Ejemplo 1: La siguiente configuración de Mule establece el atributo insecure en true. Como resultado, el motor de tiempo de ejecución de Mule no verifica el certificado del servidor de ninguna conexión con el contexto TLS denominado demoTlsContext. Esta conexión es vulnerable a un ataque "man-in-the-middle".

...
<tls:context name="demoTlsContext">
...
    <tls:trust-store ... insecure="true" ... />
...
<tls:context/>
...

Se ha detectado una operación de API que permite el viaje de las credenciales a través de un canal no cifrado. Los requisitos de OpenAPI de security y las definiciones de servers de destino para una operación API siempre anularán la configuración global respectiva.

Sin embargo, cuando estos ajustes no están definidos para una operación, se establecen de forma predeterminada en los valores especificados de forma global.

Los requisitos de seguridad global informan a los consumidores de la API sobre los parámetros de autenticación y autorización necesarios para interactuar con la API correctamente.

Una definición global de security vacía podría permitir a los atacantes interactuar con puntos finales de API confidenciales y permitirles realizar operaciones que deberían estar restringidas a cuentas de usuario específicas con privilegios específicos.

Ejemplo 1: La siguiente especificación de OpenAPI declara una definición de security global vacía. Las API que implementan esta especificación pueden ser vulnerables al acceso no autorizado o no autenticado a operaciones confidenciales.

{
    "openapi" : "3.0.3",
    "info" : {
        "title" : "My API",
        "version" : "1.0.0"
    },
    "servers" : [ {
        "url" : "/"
    } ],
    "security" : [],
    ...
}

Las operaciones de la API definen los requisitos de seguridad para informar a los consumidores de la API sobre los parámetros de autenticación y autorización necesarios para invocarlos correctamente.

Las operaciones que incluyen una definición de security vacía pueden permitir a los atacantes interactuar con puntos finales de API sensibles y realizar acciones que deberían estar restringidas a cuentas de usuario específicas con privilegios explícitos.

Ejemplo 1: La siguiente especificación de OpenAPI establece una definición security vacía para una operación confidencial. Esto anula los requisitos de seguridad definidos globalmente y hace que la operación createUsers sea vulnerable al acceso no autorizado y no autenticado.

{
    "openapi": "3.0.0",
    "info": {
     ...
    },    
    "paths": {
      "/users": {
        "post": {
          "security": [],
          "summary": "Create a user",
          "operationId": "createUsers",
         ...
        }
    ...
    }
}

Los canales de comunicación no cifrados son propensos al espionaje y manipulaciones. Atender las solicitudes de los clientes a través de un canal de comunicación inseguro permite a los atacantes realizar ataques "man-in-the-middle" y les da acceso para leer o modificar los datos en tránsito.

Configure siempre las API para usar respuestas de error personalizadas en lugar de confiar en las respuestas predeterminadas del marco subyacente. Las respuestas predeterminadas pueden brindar información detallada sobre el error que ocurrió y, de forma inadvertida, filtrar información confidencial.

Los atacantes pueden valerse de información adicional que obtengan de una respuesta de error predeterminada para planear ataques contra el marco de trabajo, la base de datos o cualquier otro recurso que la API utilice.

Los requisitos de seguridad global informan a los consumidores de la API sobre los parámetros de autenticación y autorización necesarios para interactuar con la API correctamente.

Una definición global de security inexistente podría permitir a los atacantes interactuar con puntos finales de API confidenciales y permitirles realizar operaciones que deberían estar restringidas a cuentas de usuario específicas con privilegios específicos.

Ejemplo 1: La siguiente especificación de OpenAPI no declara una definición global de security. Las API que implementan esta especificación pueden ser vulnerables al acceso no autorizado o no autenticado a operaciones confidenciales.

{
    "openapi" : "3.0.3",
    "info" : {
        "title" : "My API",
        "version" : "1.0.0"
    },
    "servers" : [ {
        "url" : "https://example.org"
    } ],    
    ...
}

Las operaciones de la API definen los requisitos de seguridad para informar a los consumidores de la API sobre los parámetros de autenticación y autorización necesarios para invocarlos correctamente.

Las operaciones que no incluyen una definición de security pueden permitir a los atacantes interactuar con puntos finales de API sensibles y realizar acciones que deberían estar restringidas a cuentas de usuario específicas con privilegios explícitos.

Ejemplo 1: La siguiente especificación de OpenAPI no establece una definición de security para una operación confidencial. Además, sin una definición global de security, la operación createUsers es vulnerable al acceso no autorizado y no autenticado.

{
    "openapi": "3.0.0",
    "info": {
     ...
    },    
    "paths": {
      "/users": {
        "post": {
          "summary": "Create a user",
          "operationId": "createUsers",
         ...
        }
    ...
    }
}

La definición securitySchemes especifica los mecanismos de seguridad que pueden usarse globalmente o que pueden usar operaciones API específicas.

La definición de securitySchemes generalmente se especifica en el objeto components reutilizable y se hace referencia a ella de forma global o mediante operaciones específicas para dictar los requisitos de seguridad para la interacción.

Ejemplo 1: La siguiente especificación de OpenAPI no logra definir la definición securitySchemes.

{
    "openapi" : "3.0.3",
    "info" : {
        "title" : "My API",
        "version" : "1.0.0"
    },   
    "components": {
        "schemas": {
        "GeneralError": {
            "type": "object",
            "properties": {            
            ...
            }
        }
}

Los requisitos de seguridad global informan a los consumidores de la API sobre los parámetros de autenticación y autorización necesarios para interactuar con la API correctamente.

Las entradas de requisitos de seguridad opcionales definidas dentro de la definición global security podrían permitir a los atacantes interactuar con puntos finales de API confidenciales y permitirles realizar operaciones que deberían estar restringidas a cuentas de usuario específicas con privilegios específicos.

Ejemplo 1: La siguiente especificación de OpenAPI declara una definición global de security con seguridad opcional mediante el elemento {}. Las API que implementan esta especificación pueden ser vulnerables al acceso no autorizado o no autenticado a operaciones confidenciales.

{
    "openapi" : "3.0.3",
    "info" : {
        "title" : "My API",
        "version" : "1.0.0"
    },
    "servers" : [ {
        "url" : "/"
    } ],
     "security" : [ {}, { "oauth_auth" : ["write","read" ]} ],
    ...
}