Asegúrese de que los hipervínculos en sus páginas web solo enlacen a ubicaciones seguras para evitar riesgos para el usuario al navegar por su sitio web. Incluso si el enlace redirige a partir de un protocolo inseguro (como HTTP) a un protocolo seguro (como HTTPS), la conexión inicial a través de un canal sin cifrar permite que a un atacante lanzar un ataque "man-in-the-middle" (MiTM). Así, este podrá controlar la página de aterrizaje que se abra.

Ejemplo 1: Considere el siguiente hipervínculo:

<a href="http://www.example.com/index.html"/>

Si un atacante está escuchando el tráfico de red entre el usuario y el servidor, puede imitar o manipular www.example.com para cargar su propia página web.

Es posible que los enlaces a sitios web de terceros inicialmente no se consideren importantes para la seguridad, pero a un usuario puede parecerle que un enlace en su página web supone un riesgo, lo que podría reducir la confianza del usuario en el uso de su plataforma.

El uso de configuraciones de seguridad del canal Google Remote Procedure Call (gRPC) que se especifican como no cifradas o que no son compatibles con la autenticación o no tienen la capacidad de identidad de conexión deja al canal expuesto a muchas formas de ataque. No se puede confiar en los datos enviados con este canal inseguro.

Ejemplo 1: El siguiente código muestra una configuración de canal gRPC con credenciales de canal no seguras

...
ManagedChannel channel = Grpc.newChannelBuilder("hostname", InsecureChannelCredentials.create()).build();
...

El uso de configuraciones de seguridad del servidor Google Remote Procedure Call (gRPC) que se especifican como no cifradas o que no tienen la capacidad de identidad de conexión deja al servidor expuesto a muchas formas de ataque. No se puede confiar en los datos enviados hacia y desde este servidor inseguro.

Ejemplo 1: El siguiente código muestra una configuración de servidor gRPC con credenciales de servidor no seguras

...
Server server = Grpc.newServerBuilderForPort(port, InsecureServerCredentials.create())
...

Un ataque de extracción de HTTPS es un tipo de ataque "man-in-the-middle" donde el atacante observa todo el tráfico HTTP en busca de los encabezados de ubicación y los vínculos que hacen referencia a HTTPS, y los reemplaza por HTTP. El atacante conserva una lista de todas las sustituciones de HTTP realizadas para poder devolver la solicitud HTTPS al servidor. Todas las conexiones HTTP extraídas se conectan a través de un proxy con el servidor mediante HTTPS. Todo el tráfico entre la víctima y el atacante se envía a través de HTTP, por lo que se revelan nombres de usuario, contraseñas y otros datos privados, pero el servidor sigue recibiendo el tráfico HTTPS esperado del atacante para que nada parezca incorrecto.

La seguridad de transporte estricta de HTTP (HSTS) es un encabezado de seguridad que indica al explorador que siempre se conecte al sitio que devuelve los encabezados HSTS a través de SSL/TLS durante un período especificado dentro del encabezado. Cualquier conexión con el servidor mediante HTTP se reemplazará automáticamente por una HTTPS, incluso si el usuario escribe una URL con http:// en la barra de dirección URL del explorador.

Ejemplo 1: El siguiente código configura una aplicación protegida con Spring Security para deshabilitar HSTS en los subdominios:

	<http auto-config="true">
        ...
        <headers>
            ...
            <hsts include-sub-domains="false" />
        </headers>
	</http>

Un ataque de extracción de HTTPS es un tipo de ataque "man-in-the-middle" donde el atacante observa todo el tráfico HTTP en busca de los encabezados de ubicación y los vínculos que hacen referencia a HTTPS, y los reemplaza por versiones HTTP. El atacante conserva una lista de todas las sustituciones de HTTP realizadas para poder devolver la solicitud HTTPS al servidor. Todas las conexiones HTTP extraídas se conectan a través de un proxy con el servidor mediante HTTPS. Todo el tráfico entre la víctima y el atacante se envía a través de HTTP, por lo que se revelan nombres de usuario, contraseñas y otros datos privados, pero el servidor sigue recibiendo el tráfico HTTPS esperado del atacante para que nada parezca incorrecto.


La seguridad de transporte estricta de HTTP (HSTS) es un encabezado de seguridad que indica al explorador que siempre se conecte al sitio que devuelve los encabezados HSTS a través de SSL/TLS durante un período especificado dentro del encabezado. Cualquier conexión con el servidor mediante HTTP se reemplazará automáticamente por una HTTPS, incluso si el usuario escribe una URL con http:// en la barra de dirección URL del explorador.

Ejemplo 1: El siguiente código configura una aplicación protegida con Spring Security para deshabilitar los encabezados HSTS:

	<http auto-config="true">
        ...
        <headers>
            ...
            <hsts disabled="true" />
        </headers>
	</http>

El algoritmo de intercambio de claves Diffie-Hellman utiliza números primos fijos como base para calcular la clave secreta para proteger el canal de comunicación. El tamaño del número primo implementado dicta el nivel de seguridad de la clave generada, que define la seguridad efectiva que proporciona el algoritmo de intercambio de claves Diffie-Hellman.

Ejemplo 1: La siguiente aplicación Node.js utiliza el grupo modp2 predefinido para inicializar un protocolo de intercambio de claves Diffie-Hellman, que utiliza un valor primo de 1024 bits:

const dh = getDiffieHellman('modp2');
dh.generateKeys();
...

Los canales de comunicación asegurados con esta implementación de intercambio de claves son vulnerables a ataques de intermediarios. Esta vulnerabilidad afecta a todos los algoritmos de intercambio de claves Diffie-Hellman anónimos, efímeros y fijos, excepto el intercambio de claves Elliptical-Curve Diffie-Hellman (ECDHE).

Un ataque de extracción de HTTPS es un tipo de ataque "man-in-the-middle" donde el atacante observa todo el tráfico HTTP en busca de los encabezados de ubicación y los vínculos que hacen referencia a HTTPS, y los reemplaza por versiones HTTP. El atacante conserva una lista de todas las sustituciones de HTTP realizadas para poder devolver la solicitud HTTPS al servidor. Todas las conexiones HTTP extraídas se conectan a través de un proxy con el servidor mediante HTTPS. Todo el tráfico entre la víctima y el atacante se envía a través de HTTP, por lo que se revelan nombres de usuario, contraseñas y otros datos privados, pero el servidor sigue recibiendo el tráfico HTTPS esperado del atacante para que nada parezca incorrecto.

La seguridad de transporte estricta de HTTP (HSTS) es un encabezado de seguridad que indica al explorador que siempre se conecte al sitio que devuelve los encabezados HSTS a través de SSL/TLS durante un período especificado dentro del encabezado. Cualquier conexión con el servidor mediante HTTP se reemplazará automáticamente por una HTTPS, incluso si el usuario escribe una URL con http:// en la barra de dirección URL del explorador.

Ejemplo 1: El siguiente código configura una aplicación protegida con Spring Security para utilizar un tiempo de vencimiento breve:

    @Bean
    public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        ...
        http.headers(headers ->
                headers.httpStrictTransportSecurity(hstsConfig ->
                    hstsConfig.maxAgeInSeconds(300)
                )
            );
        ...
    }

Los datos confidenciales enviados a través de una conexión de cable sin cifrar pueden ser leídos o modificados por cualquier atacante que pueda interceptar el tráfico de la red.

Ejemplo 1: La siguiente instancia de Spring Mailer está configurada incorrectamente, no usa SSL/TLS para comunicarse con un servidor SMTP:

<bean id="mailSender" class="org.springframework.mail.javamail.JavaMailSenderImpl">
    <property name="host" value="smtp.acme.com" />
    <property name="port" value="25" />
    <property name="javaMailProperties">
        <props>
            <prop key="mail.smtp.auth">true</prop>
        </props>
    </property>
</bean>

Los sockets RFCOMM no seguros establecen un canal de comunicación sin clave de enlace autenticada, por lo que estarán expuestos a ataques "man-in-the-middle". Para dispositivos Bluetooth 2.1, la clave de enlace se cifrará de forma obligatoria. Para dispositivos heredados (anteriores a Bluetooth 2.1), la clave de enlace no se cifrará.

Ejemplo 1: El código siguiente utiliza sockets RFCOMM que no son seguros:

    device.createInsecureRfcommSocketToServiceRecord(MY_UUID);

Una aplicación que se basa en protocolos SSL/TLS para garantizar la autenticidad, la confidencialidad y la integridad de las transmisiones de datos puede resultar vulnerable a compromisos si no elige algoritmos criptográficos lo suficientemente sólidos. La solidez del mecanismo de protección viene determinada por los algoritmos de autenticación, cifrado y hash, conocidos colectivamente como conjunto de cifrado. Se utiliza un conjunto de cifrado para la transmisión de información confidencial a través del canal TLS/SSL.

Cuando un servidor admite una variedad de conjuntos de cifrado de diferentes niveles, el uso de un cifrado débil o una clave de cifrado de longitud insuficiente puede permitir que un atacante anule el mecanismo de protección y robe o modifique información confidencial. Los atacantes podrían manipular las aplicaciones implementadas en un servidor web configurado de manera insegura, para que elijan conjuntos de cifrado débiles. Es posible que los conjuntos de cifrado débiles resulten vulnerables a los ataques de fuerza bruta y los ataques "man-in-the-middle", lo que puede derivar en la interceptación y manipulación de datos confidenciales.

El protocolo Seguridad de la capa de transporte (TLS) y el protocolo Capa de sockets seguros (SSL) ofrecen un mecanismo de protección para garantizar la autenticidad, la confidencialidad y la integridad de los datos transmitidos entre un cliente y el servidor web. Los protocolos TLS y SSL han sufrido varias revisiones que dan como resultado actualizaciones periódicas de versión. Cada nueva revisión se diseña para abordar las deficiencias de seguridad halladas en versiones previas. El uso de versiones de los protocolos TLS/SSL inseguras debilita la fortaleza de la protección de los datos y podría permitir a un atacante poner en peligro, robar o modificar información confidencial.

Los protocolos TLS/SSL débiles se caracterizan por alguna o todas las propiedades siguientes:

- No protegen ante los ataques "man-in-the-middle"
- Se usa la misma clave para autenticación y cifrado
- Débil control de autenticación de mensajes
- No protegen ante el cierre de conexión TCP
- Uso de conjuntos de cifrado débiles

La presencia de estas propiedades puede permitir que un atacante intercepte, modifique o manipule datos confidenciales.

Un desbordamiento de entero se produce cuando un programa no consigue contar con el hecho de que una operación aritmética puede dar como resultado una cantidad o bien mayor que el valor máximo del tipo de datos o inferior que su valor mínimo. A menudo, estos errores provocan problemas en las funciones de asignación de memoria, donde la entrada de un usuario se cruza con una conversión implícita entre los valores firmados y sin firma. Si un atacante puede provocar que el programa subasigne una memoria o interprete un valor firmado como un valor sin firmar en una operación de memoria, el programa puede ser vulnerable a un desbordamiento de búfer.

Ejemplo 1: El siguiente código, obtenido de OpenSSH 3.3, muestra un caso clásico de desbordamiento de enteros:

nresp = packet_get_int();
if (nresp > 0) {
 response = xmalloc(nresp*sizeof(char*));
 for (i = 0; i < nresp; i++)
  response[i] = packet_get_string(NULL);
}

Si nresp tiene el valor 1073741824 y sizeof(char*) tiene su valor típico de 4, el resultado de la operación nresp*sizeof(char*) se desbordaría y el argumento de xmalloc() sería 0. La mayor parte de las implementaciones de malloc() permitirán la asignación de un búfer de 0 bytes, lo que hará que las iteraciones de bucle posteriores desborden el búfer de montón response.

Ejemplo 2: Este ejemplo procesa la entrada de usuario formada por una serie de estructuras de longitud variable. Los dos primeros bytes de entrada establecen el tamaño de la estructura que se va a procesar.

 char* processNext(char* strm) {
 char buf[512];
 short len = *(short*) strm;
 strm += sizeof(len);
 if (len <= 512) {
  memcpy(buf, strm, len);
  process(buf);
  return strm + len;
 } else {
  return -1;
 }
}

El programador ha establecido un límite superior en el tamaño de la estructura: si es mayor que 512, la entrada no se procesará. El problema es que len es un entero con signo, de modo que la comprobación en relación con la longitud máxima de la estructura se realiza con enteros con signo, pero len se convierte en un entero sin signo para la llamada a memcpy(). Si len es negativo, parecerá que la estructura tiene un tamaño adecuado (se tomará la rama if), pero la cantidad de memoria copiada por memcpy() será bastante grande y el atacante podrá desbordar la pila con los datos de strm.

Se produce un problema de manipulación de finalidad cuando se cumplen las dos condiciones siguientes:

1. Un atacante puede especificar la acción, el nombre de clase o el componente de una finalidad de Android.

Por ejemplo, un atacante puede especificar el nombre de clase o el componente para gestionar la finalidad.

2. Al especificar la acción, el nombre de clase o el componente, el usuario malintencionado adquiere una capacidad que de otro modo no estaría permitida.

Por ejemplo, el programa puede otorgar al usuario malintencionado la capacidad de transmitir información confidencial a un software de terceros en el dispositivo.

Ejemplo 1: el siguiente código utiliza un argumento leído de una solicitud HTTP para establecer el nombre de clase de una finalidad.

String arg = request.getParameter("arg");
...
Intent intent = new Intent();
...
intent.setClassName(arg);
ctx.startActivity(intent);
...

Un Intent interno utiliza una acción personalizada definida por un componente interno. Los intents implícitos pueden facilitar la llamada de intenciones desde cualquier componente externo determinado sin conocimiento del componente específico. La combinación de ambos permite que una aplicación acceda a intenciones especificadas para un uso interno específico desde fuera del contexto de la aplicación deseada.

La capacidad de procesar un Intent desde una aplicación externa puede permitir una amplia variedad de explotaciones de intermediario que varían en gravedad. desde fuga de información y denegación de servicio hasta ejecución remota de código, dependiendo de la capacidad de acción interna especificada por el Intent.

Ejemplo 1: El siguiente código utiliza un Intent interno implícito.

...
val imp_internal_intent_action = Intent("INTERNAL_ACTION_HERE")
startActivity(imp_internal_intent_action)
...

Los intents de Android se utilizan para vincular aplicaciones y componentes de aplicaciones proporcionando instrucciones sobre las acciones que realiza un componente determinado. Los intents pendientes se crean para entregar el Intent más adelante. Los intents implícitos facilitan la llamada de intents desde cualquier componente externo determinado, utilizando un nombre general y un filtro para determinar la ejecución.

Cuando se crea un Intent implícito como PendingIntent, esto podría permitir que el Intent se envíe a un componente no deseado que se ejecuta fuera del contexto temporal previsto, dejando al sistema vulnerable para explotar vectores como la denegación de servicio, la fuga de información privada y del sistema y la escalada de privilegios.

Ejemplo 1: El código siguiente utiliza un PendingIntent implícito.

...
val imp_intent = Intent()
val flag_mut = PendingIntent.FLAG_MUTABLE
val pi_flagmutable_impintintent = PendingIntent.getService(
    this,
    0,
    imp_intent,
    flag_mut
)
...

Permitir la modificación del Intent subyacente de un PendingIntent después de su creación puede dejar un sistema abierto a ataques. Esto depende principalmente de la capacidad general del Intent subyacente. En la mayoría de los casos, se recomienda evitar posibles problemas configurando la marca PendingIntent en FLAG_IMMUTABLE.

Ejemplo 1: El siguiente incluye un PendingIntent creado con un valor de marca de FLAG_MUTABLE.

...
val intent_flag_mut = Intent(Intent.ACTION_GTALK_SERVICE_DISCONNECTED, Uri.EMPTY, this, DownloadService::class.java)
val flag_mut = PendingIntent.FLAG_MUTABLE

val pi_flagmutable = PendingIntent.getService(
    this,
    0,
    intent_flag_mut,
    flag_mut
)
...

Se produce un problema manipulación de intento de redireccionamiento cuando se cumplen las condiciones siguientes:
1. Un componente exportado acepta un Intent arbitrario anidado en el paquete de extras de un Intent proporcionado externamente.

2. El componente exportado utiliza el Intent arbitrario para iniciar un componente llamando a startActivity, startService o sendBroadcast.

Un atacante posiblemente pueda obtener una capacidad que de otro modo no estaría permitida cuando existen estas condiciones.
Ejemplo 1: El siguiente código acepta un Intent anidado de una fuente externa y usa ese Intent para iniciar una actividad.

...
Intent nextIntent = (Intent) getIntent().getParcelableExtra("next-intent");
startActivity(nextIntent);
...

El estándar J2EE requiere que las aplicaciones usen las utilidades de administración de recursos del contenedor para obtener conexiones a los recursos.

Por ejemplo, una aplicación J2EE debe obtener una conexión de base de datos, como se indica a continuación:

ctx = new InitialContext();
datasource = (DataSource)ctx.lookup(DB_DATASRC_REF);
conn = datasource.getConnection();

y debe evitar obtener una conexión de la siguiente forma:

conn = DriverManager.getConnection(CONNECT_STRING);

Todos los contenedores de aplicaciones web principales ofrecen administración de conexiones de base de datos agrupadas en conjuntos como parte de su estructura de administración de recursos. La duplicación de esta funcionalidad en una aplicación es difícil y susceptible a errores, que es parte del motivo por el que está prohibida en virtud de la norma de J2EE.

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: el código del siguiente ejemplo establece un valor negativo para el intervalo inactivo máximo producido en una sesión que permanece activa indefinidamente.

...
HttpSession sesssion = request.getSession(true);
sesssion.setMaxInactiveInterval(-1);
...

Nunca es recomendable que una aplicación web intente cerrar el contenedor de aplicaciones. Una llamada a un método de finalización es probablemente parte de un código de depuración sobrante o un código importado de una aplicación que no es de J2EE.