Existen varias herramientas dentro del mundo del desarrollo de Java que facilitan la administración de dependencias: tanto Apache Ant como Apache Maven son sistemas de compilación que incluyen funcionalidad específicamente diseñada para facilitar la administración de dependencias, y Apache Ivy está diseñado expresamente como administrador de dependencias. Aunque existen diferencias en su comportamiento, estas herramientas comparten la funcionalidad común de descargar de forma automática dependencias externas especificadas en el proceso de compilación en tiempo de compilación. Así, resulta mucho más sencillo para un desarrollador B compilar software de la misma forma que un desarrollador A. Los desarrolladores simplemente almacenan información de dependencias en el archivo de compilación, lo que significa que cada desarrollador e ingeniero de compilación tiene una forma consistente de obtener dependencias, compilar el código y llevar a cabo la implementación sin las complicaciones de la administración de dependencias que supone la administración manual. En los siguientes ejemplos, se ilustra cómo Ivy, Ant y Maven se pueden utilizar para administrar dependencias externas como parte de un proceso de compilación.

Los desarrolladores especifican las dependencias externas en un destino de Ant mediante una tarea <get>, que recupera la dependencia especificada por la dirección URL correspondiente. Este enfoque es funcionalmente equivalente al escenario en el que un desarrollador documenta cada dependencia externa como un artefacto incluido en el proyecto de software, pero es más deseable porque automatiza la recuperación e incorporación de las dependencias cuando se realiza una compilación.

Ejemplo 1: El siguiente extracto de un archivo de configuración build.xml de Ant muestra una referencia típica a una dependencia externa:

<get src="http://people.apache.org/repo/m2-snapshot-repository/org/apache/openejb/openejb-jee/3.0.0-SNAPSHOT/openejb-jee-3.0.0-SNAPSHOT.jar"
dest="${maven.repo.local}/org/apache/openejb/openejb-jee/3.0.0-SNAPSHOT/openejb-jee-3.0.0-SNAPSHOT.jar"
usetimestamp="true" ignoreerrors="true"/>

Dos tipos distintos de escenarios de ataque afectan a estos sistemas: Un atacante podría comprometer el servidor que hospeda la dependencia o el servidor DNS que utiliza la máquina de compilación para redirigir las solicitudes de nombre de host del servidor que hospeda la dependencia a una máquina controlada por el atacante. Ambos escenarios dan lugar a que el atacante consiga inyectar una versión malintencionada de una dependencia en una compilación que se ejecuta en una máquina no comprometida.

Independientemente del vector de ataque utilizado para entregar la dependencia de troyano, estos escenarios comparten el elemento común de que el sistema de compilación acepta ciegamente el archivo binario malintencionado y lo incluye en la compilación. Dado que el sistema de compilación no tiene ningún recurso para rechazar el binario malintencionado y que los mecanismos de seguridad existentes, como la revisión del código, suelen centrarse en el código desarrollado internamente y no en las dependencias externas, este tipo de ataque tiene un gran potencial para pasar desapercibido a medida que se extiende por el entorno de desarrollo y, potencialmente, a producción.

Aunque existe cierto riesgo de que se introduzca una dependencia comprometida en un proceso de compilación manual, la tendencia de los sistemas de compilación automatizados a recuperar la dependencia de un origen externo cada vez que el sistema de compilación se ejecuta en un nuevo entorno aumenta enormemente la ventana de oportunidad para un atacante. Un atacante solo necesita comprometer el servidor de dependencias o el servidor DNS durante una de las muchas veces que se recupera la dependencia para comprometer la máquina en la que se está produciendo la compilación.

Existen varias herramientas dentro del mundo del desarrollo de Java que facilitan la administración de dependencias: tanto Apache Ant como Apache Maven son sistemas de compilación que incluyen funcionalidad específicamente diseñada para facilitar la administración de dependencias, y Apache Ivy está diseñado expresamente como administrador de dependencias. Aunque existen diferencias en su comportamiento, estas herramientas comparten la funcionalidad común de descargar de forma automática dependencias externas especificadas en el proceso de compilación en tiempo de compilación. Así, resulta mucho más sencillo para un desarrollador B compilar software de la misma forma que un desarrollador A. Los desarrolladores simplemente almacenan información de dependencias en el archivo de compilación, lo que significa que cada desarrollador e ingeniero de compilación tiene una forma consistente de obtener dependencias, compilar el código y llevar a cabo la implementación sin las complicaciones de la administración de dependencias que supone la administración manual. En los siguientes ejemplos, se ilustra cómo Ivy, Ant y Maven se pueden utilizar para administrar dependencias externas como parte de un proceso de compilación.

En Ivy, en lugar de enumerar las direcciones URL explícitas de las que recuperar las dependencias, los desarrolladores especifican los nombres y las versiones de las dependencias, e Ivy se basa en su configuración subyacente para identificar los servidores de los que recuperar las dependencias. Para los componentes de uso común, esta medida evita que el desarrollador tenga que investigar las ubicaciones de las dependencias.

Ejemplo 1: El siguiente extracto de un archivo ivy.xml de Ivy muestra cómo un desarrollador puede especificar múltiples dependencias externas usando su nombre y versión:

<dependencies>
  <dependency org="javax.servlet"
             name="servletapi"
              rev="2.3" conf="build->*"/>
  <dependency org="javax.jms"
             name="jms"
              rev="1.1" conf="build->*"/>  ...
</dependencies>

Dos tipos distintos de escenarios de ataque afectan a estos sistemas: Un atacante podría comprometer el servidor que hospeda la dependencia o el servidor DNS que utiliza la máquina de compilación para redirigir las solicitudes de nombre de host del servidor que hospeda la dependencia a una máquina controlada por el atacante. Ambos escenarios dan lugar a que el atacante consiga inyectar una versión malintencionada de una dependencia en una compilación que se ejecuta en una máquina no comprometida.

Independientemente del vector de ataque utilizado para entregar la dependencia de troyano, estos escenarios comparten el elemento común de que el sistema de compilación acepta ciegamente el archivo binario malintencionado y lo incluye en la compilación. Dado que el sistema de compilación no tiene ningún recurso para rechazar el binario malintencionado y que los mecanismos de seguridad existentes, como la revisión del código, suelen centrarse en el código desarrollado internamente y no en las dependencias externas, este tipo de ataque tiene un gran potencial para pasar desapercibido a medida que se extiende por el entorno de desarrollo y, potencialmente, a producción.

Aunque existe cierto riesgo de que se introduzca una dependencia comprometida en un proceso de compilación manual, la tendencia de los sistemas de compilación automatizados a recuperar la dependencia de un origen externo cada vez que el sistema de compilación se ejecuta en un nuevo entorno aumenta la ventana de oportunidad para un atacante. Un atacante solo necesita comprometer el servidor de dependencias o el servidor DNS durante una de las muchas veces que se recupera la dependencia para comprometer la máquina en la que se está produciendo la compilación.

Existen varias herramientas dentro del mundo del desarrollo de Java que facilitan la administración de dependencias: tanto Apache Ant como Apache Maven son sistemas de compilación que incluyen funcionalidad específicamente diseñada para facilitar la administración de dependencias, y Apache Ivy está diseñado expresamente como administrador de dependencias. Aunque existen diferencias en su comportamiento, estas herramientas comparten la funcionalidad común de descargar de forma automática dependencias externas especificadas en el proceso de compilación en tiempo de compilación. Así, resulta mucho más sencillo para un desarrollador B compilar software de la misma forma que un desarrollador A. Los desarrolladores simplemente almacenan información de dependencias en el archivo de compilación, lo que significa que cada desarrollador e ingeniero de compilación tiene una forma consistente de obtener dependencias, compilar el código y llevar a cabo la implementación sin las complicaciones de la administración de dependencias que supone la administración manual. En los siguientes ejemplos, se ilustra cómo Ivy, Ant y Maven se pueden utilizar para administrar dependencias externas como parte de un proceso de compilación.

En Maven, en lugar de enumerar las direcciones URL explícitas de las que recuperar las dependencias, los desarrolladores especifican los nombres y las versiones de las dependencias y Maven se basa en su configuración subyacente para identificar los servidores de los que recuperar las dependencias. Para los componentes de uso común, esta medida evita que el desarrollador tenga que investigar las ubicaciones de las dependencias.

Ejemplo 1: El siguiente extracto de un archivo pom.xml de Maven muestra cómo un desarrollador puede especificar múltiples dependencias externas usando su nombre y versión:

<dependencies>
  <dependency>
    <groupId>commons-logging</groupId>
    <artifactId>commons-logging</artifactId>
    <version>1.1</version>
  </dependency>
  <dependency>
    <groupId>javax.jms</groupId>
    <artifactId>jms</artifactId>
    <version>1.1</version>
  </dependency>
  ...
</dependencies>

Dos tipos distintos de escenarios de ataque afectan a estos sistemas: Un atacante podría comprometer el servidor que hospeda la dependencia o el servidor DNS que utiliza la máquina de compilación para redirigir las solicitudes de nombre de host del servidor que hospeda la dependencia a una máquina controlada por el atacante. Ambos escenarios dan lugar a que el atacante consiga inyectar una versión malintencionada de una dependencia en una compilación que se ejecuta en una máquina no comprometida.

Independientemente del vector de ataque utilizado para entregar la dependencia de troyano, estos escenarios comparten el elemento común de que el sistema de compilación acepta ciegamente el archivo binario malintencionado y lo incluye en la compilación. Dado que el sistema de compilación no tiene ningún recurso para rechazar el binario malintencionado y que los mecanismos de seguridad existentes, como la revisión del código, suelen centrarse en el código desarrollado internamente y no en las dependencias externas, este tipo de ataque tiene un gran potencial para pasar desapercibido a medida que se extiende por el entorno de desarrollo y, potencialmente, a producción.

Aunque existe cierto riesgo de que se introduzca una dependencia comprometida en un proceso de compilación manual, la tendencia de los sistemas de compilación automatizados a recuperar la dependencia de un origen externo cada vez que el sistema de compilación se ejecuta en un nuevo entorno aumenta enormemente la ventana de oportunidad para un atacante. Un atacante solo necesita comprometer el servidor de dependencias o el servidor DNS durante una de las muchas veces que se recupera la dependencia para comprometer la máquina en la que se está produciendo la compilación.

CakePHP puede configurarse para que exponga información de depuración que incluya errores, advertencias, instrucciones SQL y seguimientos de la pila. La información de depuración no se debe utilizar en los entornos de producción.

Ejemplo 1:

    Configure::write('debug', 3);

el segundo parámetro para el método Configure::write() indica el nivel de depuración. Cuanto mayor sea el número, más detallados serán los mensajes de registro.

Cuanto más tiempo permanezca una sesión abierta, más oportunidades tendrá un atacante para poner en peligros las cuentas de los usuarios. Durante el tiempo que una sesión permanece activa, un usuario malintencionado puede ser capaz de forzar el robo de la contraseña de un usuario, descifrar la clave de cifrado inalámbrico de un usuario o dirigir una sesión desde un explorador abierto. Los tiempos de expiración de sesión largos pueden, además, impedir que se libere memoria y que se produzca al final una denegación de servicio si se crea un número de sesiones suficientemente largo.

Ejemplo 1: en el siguiente ejemplo se muestra CakePHP configurado con la sesión de seguridad low.

    Configure::write('Security.level', 'low');

Junto con la opción Session.timeout, las opciones Security.level definen cuánto tiempo es válida una sesión. El tiempo de espera de sesión real es igual al Session.timeout por uno de los siguientes múltiplos:

'high' = x 10
'medium' = x 100
'low' = x 300

El almacenamiento de un certificado de texto sin formato en una configuración o un archivo de manifiesto permite que cualquier persona que pueda leer el archivo acceda al recurso protegido por certificado. Los desarrolladores a veces creen que no pueden proteger la aplicación de alguien que tenga acceso a la configuración, pero esta actitud facilita el trabajo de un atacante. Las buenas pautas de administración de certificados requieren que un certificado nunca se almacene en texto sin formato.

La manipulación de ClassLoader permite a un atacante acceder a la configuración del servidor de aplicaciones subyacente y modificarla. En ciertos servidores de aplicaciones, como Tomcat 8, un atacante puede modificar estas configuraciones para cargar un shell web y ejecutar comandos arbitrarios.

La suplantación de DNS, también conocida como envenenamiento de la caché de DNS, es un tipo de ataque en el que un atacante corrompe la caché del solucionador de DNS, lo que le lleva a devolver direcciones IP incorrectas. Al utilizar la suplantación de DNS, un atacante puede redirigir a los usuarios a sitios web maliciosos sin su estos lo sepan. En el contexto de JavaScript del lado del servidor que utiliza Node.js, el manejo inadecuado de la configuración del servidor DNS puede generar vulnerabilidades de seguridad.

Ejemplo 1: Piense en un escenario en el que una aplicación Node.js permite a los usuarios especificar servidores DNS personalizados. Si esta entrada no se valida y desinfecta de forma adecuada, un atacante puede suministrar servidores DNS maliciosos e implementar ataques de suplantación de DNS.

const dns = require('dns');

// User-controlled input for DNS servers
const customDnsServers = from_user_controlled_input;

// Set custom DNS servers
dns.setServers(customDnsServers);

En este ejemplo, a la variable customDnsServers se le asigna un valor derivado de la entrada controlada por el usuario. Esta entrada se utiliza luego para configurar los servidores DNS usandodns.setServers(customDnsServers). Si un atacante proporciona direcciones de servidor DNS maliciosas, puede dirigir la aplicación para que resuelva nombres de dominio utilizando sus servidores, lo que puede devolver direcciones IP falsas.

Cuando un Dockerfile no especifica un USER, los contenedores de Docker se ejecutan con privilegios de superusuario de forma predeterminada. Estos privilegios de superusuario se propagan al código que se ejecuta dentro del contenedor, que suele ser más permisivo de lo necesario. La ejecución del contenedor Docker con privilegios de superusuario amplía la superficie de ataque, lo que podría permitir a los atacantes realizar formas de explotación más graves.

Dockerfiles puede especificar un rango independiente de versiones para dependencias e imágenes base. Si un atacante puede agregar versiones malintencionadas de dependencias a un repositorio o engañar al sistema de compilación para que descargue dependencias de un repositorio bajo el control del atacante, si el docker está configurado sin versiones específicas de dependencias, el docker descargará y ejecutará silenciosamente la dependencia comprometida.

Este tipo de debilidad podría aprovecharse como resultado de un ataque a la cadena de suministro en el que los atacantes pueden aprovechar la configuración incorrecta de los desarrolladores, el error tipográfico y pueden agregar paquetes malintencionados a los repositorios de código abierto. Un ataque de este tipo aprovecha la confianza en los paquetes publicados para obtener acceso y extraer datos.

En Docker, la etiqueta latest indica automáticamente el nivel de versión de una imagen que no usa un resumen o una etiqueta única para proporcionar una versión. Docker asigna automáticamente la etiqueta latest como mecanismo para apuntar al archivo de archivo de manifiesto más reciente. Debido a que las etiquetas son mutables, un atacante puede reemplazar una imagen o capa usando una etiqueta latest (o etiquetas débiles comoimagename-lst, imagename-last, myimage).

Ejemplo 1: La siguiente configuración indica a Docker que elija la imagen base con la última versión de ubuntu.

    FROM ubuntu:Latest
    ...

Docker no valida si el repositorio configurado para admitir el administrador de paquetes es de confianza.

Ejemplo 2: La siguiente configuración instruye al administrador de paquetes zypper para que recupere la última versión del paquete dado.

...
zypper install package
...

En Example 2 , si el repositorio está comprometido, un atacante podría simplemente cargar una versión que cumpla con los criterios dinámicos y provoque que zypper descargue una versión malintencionada de la dependencia.

El Dockerfile con instrucción USER que se ha configurado como raíz, tiene un privilegio excesivamente permisivo para realizar cambios en el contenedor. Infringe el principio de ejecutar imágenes con privilegios mínimos. En casos habituales, es posible que se requieran permisos de raíz para instalar paquetes y crear carpetas. Una vez realizada la instalación, es una buena práctica agregar un usuario con privilegios restringidos.

De forma predeterminada, el docker permite enlazar puertos privilegiados a un contenedor y, si el usuario no declara un puerto, el docker asigna el puerto del contenedor a uno disponible en el rango 49153-65535. En muchos casos, es necesario abrir ciertos puertos para ejecutar servicios y, con el tiempo, la cantidad de puertos abiertos puede aumentar. Los puertos abiertos aumentan la superficie de ataque, especialmente para los servicios que se ejecutan con mayores privilegios. Asegúrese de abrir solo los puertos necesarios para ese servicio específico. Cuando los servicios no requieran mayores privilegios, ejecútelos en un puerto no incluido en el rango de puertos privilegiados.

Puede reconstruir un Dockerfile a partir de una imagen de docker públicamente disponible mediante la inspección del docker y el comando de historial, o automatizando este proceso a través de una herramienta de terceros. Si se agrega información confidencial utilizando el comando ADD/COPY, un atacante puede recrear cada capa del docker para obtener la información.

El uso de Volumes también puede exponer directorios confidenciales. Si necesita usar Volumes para conservar los datos, evite montar directorios confidenciales.

Cuando se ejecuta un servicio Secure Shell (SSH) en un contenedor, es difícil administrar directivas de acceso, claves, contraseñas y actualizaciones de seguridad.

Al usar una CDN para suministrar contenido JavaScript dependiente de la aplicación, se ofrecen muchas ventajas al proporcionar JavaScript desde el propio servidor de la aplicación. Entre estas ventajas, se incluyen un aumento del rendimiento y un menor mantenimiento del código por parte del propietario de la aplicación. Sin embargo, la aplicación presupone que la CDN proporcionará contenido seguro al explorador. Si un usuario malintencionado pone en peligro una CDN, esta proporcionará código malintencionado al explorador del usuario, que ahora ejecuta código que la aplicación no puede controlar o detectar como malintencionado.

Ejemplo 1: en el siguiente código ASPX se incluye el código de jQuery de Microsoft mediante la referencia a Microsoft CDN:

...
<script src="http://ajax.microsoft.com/ajax/jquery/jquery-1.4.2.min.js" type="text/javascript"></script>
...

Ejemplo 2: en el siguiente código ASPX se permite la redirección automática de todas las solicitudes de secuencias de comandos de ASP.NET para Microsoft Ajax CDN:

...
<asp:ScriptManager
   ID="ScriptManager1"
   EnableCdn="true"
   Runat="Server" />
...

En el Example 2, el control ScriptManager configura su página ASPX para que redireccione automáticamente cualquier solicitud de script a la CDN correspondiente.

Si está utilizando Blaze DS para llevar a cabo el registro de eventos inesperados, el archivo del descriptor services-config.xml especifica un elemento XML "Logging" (Registro) para describir los diferentes aspectos del registro. Tiene un formato similar al siguiente:

Ejemplo 1:

<logging>
    <target class="flex.messaging.log.ConsoleTarget" level="Debug">
        <properties>
            <prefix>[BlazeDS]</prefix>
            <includeDate>false</includeDate>
            <includeTime>false</includeTime>
            <includeLevel>false</includeLevel>
            <includeCategory>false</includeCategory>
        </properties>
        <filters>
            <pattern>Endpoint.*</pattern>
            <pattern>Service.*</pattern>
            <pattern>Configuration</pattern>
        </filters>
    </target>
</logging>

Esta etiqueta target toma un atributo opcional que se llama level, el cual indica el nivel de registro. Si el nivel de depuración se establece en un nivel demasiado detallado, su aplicación puede escribir datos confidenciales en el archivo de registro.

Las claves de cifrado administradas por el cliente (CMEK) no están habilitadas para los datos en reposo.

Por defecto, Google Cloud usa claves de cifrado de datos (DEK) generadas aleatoriamente para cifrar los datos en reposo. La función CMEK permite a las organizaciones utilizar claves criptográficas de su elección para cifrar las DEK. Esto brinda a las organizaciones un mejor control y registro de los procesos de cifrado.

Como tal, la CMEK suele ser parte de la solución para satisfacer requisitos que incluyen, entre otros:
- Registros de auditoría para el acceso a datos confidenciales
- Residencia de datos
- Reemplazo, deshabilitación o destrucción de claves
- Módulo de seguridad de hardware resistente a manipulaciones

Otorgar acceso o funciones de BigQuery al tipo principal especial, como allUsers y allAuthenticatedUsers, otorga a cualquier persona acceso a datos confidenciales.

Las claves de cifrado administradas por el cliente (CMEK) no están habilitadas para los datos en reposo.

Por defecto, Google Cloud usa claves de cifrado de datos (DEK) generadas aleatoriamente para cifrar los datos en reposo. La función CMEK permite a las organizaciones utilizar claves criptográficas de su elección para cifrar las DEK. Esto brinda a las organizaciones un mejor control y registro de los procesos de cifrado.

Como tal, la CMEK suele ser parte de la solución para satisfacer requisitos que incluyen, entre otros:
- Registros de auditoría para el acceso a datos confidenciales
- Residencia de datos
- Reemplazo, deshabilitación o destrucción de claves
- Módulo de seguridad de hardware resistente a manipulaciones

Las claves de cifrado administradas por el cliente (CMEK) no están habilitadas para los datos en reposo.

Por defecto, Google Cloud usa claves de cifrado de datos (DEK) generadas aleatoriamente para cifrar los datos en reposo. La función CMEK permite a las organizaciones utilizar claves criptográficas de su elección para cifrar las DEK. Esto brinda a las organizaciones un mejor control y registro de los procesos de cifrado.

Como tal, la CMEK suele ser parte de la solución para satisfacer requisitos que incluyen, entre otros:
- Registros de auditoría para el acceso a datos confidenciales
- Residencia de datos
- Reemplazo, deshabilitación o destrucción de claves
- Módulo de seguridad de hardware resistente a manipulaciones