En algunas bibliotecas que utilizan conexiones SSL, el certificado de servidor no se comprueba de forma predeterminada. Esto equivale a confiar en todos los certificados.

Ejemplo 1: esta aplicación no comprueba explícitamente el certificado de servidor.

  ...
  Email email = new SimpleEmail();
  email.setHostName("smtp.servermail.com");
  email.setSmtpPort(465);
  email.setAuthenticator(new DefaultAuthenticator(username, password));
  email.setSSLOnConnect(true);
  email.setFrom("user@gmail.com");
  email.setSubject("TestMail");
  email.setMsg("This is a test mail ... :-)");
  email.addTo("foo@bar.com");
  email.send();
  ...
  

Al intentar establecer una conexión con smtp.mailserver.com:465, esta aplicación aceptaría sin objeciones cualquier certificado emitido a "hackedserver.com". La aplicación podría filtrar entonces información de usuario confidencial en una conexión SSL interrumpida en el servidor pirateado.

El servicio de copia de seguridad de Android permite que la aplicación guarde los datos persistentes en un almacenamiento en la nube remoto para proporcionar un punto de restauración para los datos de la aplicación en el futuro.

Para configurar las aplicaciones para Android con este servicio de copia de seguridad, establezca el atributo allowBackup en true (el valor predeterminado) y defina el atributo backupAgent en la etiqueta <application>.

Sin embargo, Android no garantiza la seguridad de sus datos mientras utiliza la copia de seguridad, ya que el almacenamiento y el transporte en la nube varían de un dispositivo a otro.

Los datos guardados en el almacenamiento externo permiten un acceso de lectura general y solo los puede modificar el usuario cuando se habilite el almacenamiento masivo USB para transferir archivos en un equipo. Además, los archivos de la tarjeta de almacenamiento masivo permanecerán en esa ubicación, aunque se desinstale la aplicación que escribió estos. Estas limitaciones pueden poner en peligro la información confidencial escrita en el almacenamiento y permitir a los usuarios malintencionados introducir datos en el programa modificando un archivo externo que utilice.

Ejemplo 1: en el código siguiente, Environment.getExternalStorageDirectory() devuelve una referencia al almacenamiento externo del dispositivo Android.

 private void WriteToFile(String what_to_write) {
        try{
            File root = Environment.getExternalStorageDirectory();
            if(root.canWrite()) {
                File dir = new File(root + "write_to_the_SDcard");
                File datafile = new File(dir, number + ".extension");
                FileWriter datawriter = new FileWriter(datafile);
                BufferedWriter out = new BufferedWriter(datawriter);
                out.write(what_to_write);
                out.close();
             }
        }
   }

Los datos guardados en el almacenamiento interno de Android mediante MODE_WORLD_READBLE o MODE_WORLD_WRITEABLE están accesibles para todas las aplicaciones en el dispositivo. Esto no solo impide la protección frente al daño de datos, pero en el caso de información confidencial, infringe la privacidad del usuario y plantea riesgos de seguridad.

Las respuestas de HTTP(S) pueden contener datos confidenciales, como cookies de sesión y tokens de API. El sistema de carga de URL guardará en la caché todas las respuestas de HTTP(S) por razones de rendimiento, y las almacenará sin cifrar en una ubicación de almacenamiento compartido no seguro.

Ejemplo 1: El código siguiente instala la caché de respuestas HTTP(S) en una ubicación de almacenamiento compartido no seguro:

    protected void onCreate(Bundle savedInstanceState) {
       ...

       try {
           File httpCacheDir = new File(context.getExternalCacheDir(), "http");
           long httpCacheSize = 10 * 1024 * 1024; // 10 MiB
           HttpResponseCache.install(httpCacheDir, httpCacheSize);
       } catch (IOException e) {
           Log.i(TAG, "HTTP response cache installation failed:" + e);
       }
    }

    protected void onStop() {
       ...

       HttpResponseCache cache = HttpResponseCache.getInstalled();
       if (cache != null) {
           cache.flush();
       }
   }

Otras aplicaciones pueden acceder a los archivos de aplicación en dispositivos con acceso root o en copias de seguridad sin cifrar. Dado que un usuario podría decidir liberar su dispositivo o realizar copias de seguridad sin cifrar, se recomienda cifrar las bases de datos que contengan datos confidenciales.

Ejemplo 1: El siguiente código establece una conexión con una base de datos Realm sin cifrar:

    Realm realm = Realm.getDefaultInstance();

La concesión de acceso anónimo completo a un objeto o contenedor permite que los usuarios malintencionados lean el contenido o lo reemplacen con contenido malintencionado.

Ejemplo 1: El siguiente código define una Access Control Policy que concede acceso anónimo completo al contenedor foo.

    GetBucketAclRequest bucketAclReq = GetBucketAclRequest.builder().bucket("foo").build();
    GetBucketAclResponse getAclRes = s3.getBucketAcl(bucketAclReq);
    List<Grant> grants = getAclRes.grants();

    Grantee allusers = Grantee.builder().uri("http://acs.amazonaws.com/groups/global/AllUsers").build();
    Permission fc_permission = Permission.fromValue("FullControl");
    Grant grant = Grant.builder().grantee(allusers).permission(fc_permission).build();
    grants.add(grant);

    AccessControlPolicy acl = AccessControlPolicy.builder().grants(grants).build();

La concesión de un permiso anónimo para leer la política de control de acceso (ACP) de un objeto o contenedor permite que los usuarios malintencionados identifiquen los objetos que se pueden recuperar o reemplazar.

Ejemplo 1: El siguiente código define una Access Control Policy que concede un permiso anónimo de lectura de la ACP en el contenedor foo.

    GetBucketAclRequest bucketAclReq = GetBucketAclRequest.builder().bucket("foo").build();
    GetBucketAclResponse getAclRes = s3.getBucketAcl(bucketAclReq);
    List<Grant> grants = getAclRes.grants();

    Grantee allusers = Grantee.builder().uri("http://acs.amazonaws.com/groups/global/AllUsers").build();
    Permission fc_permission = Permission.fromValue("READ_ACP");
    Grant grant = Grant.builder().grantee(allusers).permission(fc_permission).build();
    grants.add(grant);

    AccessControlPolicy acl = AccessControlPolicy.builder().grants(grants).build();

La concesión de acceso anónimo de lectura a un objeto o contenedor permite que los usuarios malintencionados lean su contenido.

Ejemplo 1: El siguiente código define una Access Control Policy que concede acceso anónimo de lectura al contenedor foo.

    GetBucketAclRequest bucketAclReq = GetBucketAclRequest.builder().bucket("foo").build();
    GetBucketAclResponse getAclRes = s3.getBucketAcl(bucketAclReq);
    List<Grant> grants = getAclRes.grants();

    Grantee allusers = Grantee.builder().uri("http://acs.amazonaws.com/groups/global/AllUsers").build();
    Permission fc_permission = Permission.fromValue("Read");
    Grant grant = Grant.builder().grantee(allusers).permission(fc_permission).build();
    grants.add(grant);

    AccessControlPolicy acl = AccessControlPolicy.builder().grants(grants).build();

La concesión de un permiso anónimo para escribir en la política de control de acceso (ACP) de un objeto o contenedor permite que los usuarios malintencionados lean el contenido de dicho contenedor o que escriban en él.

Ejemplo 1: El siguiente código define una Access Control Policy que concede un permiso anónimo de escritura de la ACP en el contenedor foo.

    GetBucketAclRequest bucketAclReq = GetBucketAclRequest.builder().bucket("foo").build();
    GetBucketAclResponse getAclRes = s3.getBucketAcl(bucketAclReq);
    List<Grant> grants = getAclRes.grants();

    Grantee allusers = Grantee.builder().uri("http://acs.amazonaws.com/groups/global/AllUsers").build();
    Permission fc_permission = Permission.fromValue("WRITE_ACP");
    Grant grant = Grant.builder().grantee(allusers).permission(fc_permission).build();
    grants.add(grant);

    AccessControlPolicy acl = AccessControlPolicy.builder().grants(grants).build();

La concesión de acceso anónimo de escritura a un objeto o contenedor permite que los usuarios malintencionados reemplacen el contenido o que carguen contenido malintencionado.

Ejemplo 1: El siguiente código define una Access Control Policy que concede acceso anónimo de escritura al contenedor foo.

    GetBucketAclRequest bucketAclReq = GetBucketAclRequest.builder().bucket("foo").build();
    GetBucketAclResponse getAclRes = s3.getBucketAcl(bucketAclReq);
    List<Grant> grants = getAclRes.grants();

    Grantee allusers = Grantee.builder().uri("http://acs.amazonaws.com/groups/global/AllUsers").build();
    Permission fc_permission = Permission.fromValue("Write");
    Grant grant = Grant.builder().grantee(allusers).permission(fc_permission).build();
    grants.add(grant);

    AccessControlPolicy acl = AccessControlPolicy.builder().grants(grants).build();

Las comunicaciones a través de HTTP, FTP o gopher no están autenticadas ni cifradas. Por lo tanto, están sujetas a riesgos, sobre todo en entornos móviles en los que los dispositivos se conectan con frecuencia a redes inalámbricas públicas poco seguras mediante conexiones WiFi.

Ejemplo 1: En el siguiente ejemplo, se leen datos mediante el protocolo HTTP (en lugar de usar HTTPS).

   URL url = new URL("http://www.android.com/");
   HttpURLConnection urlConnection = (HttpURLConnection) url.openConnection();
   try {
     InputStream in = new BufferedInputStream(urlConnection.getInputStream());
     readStream(in);
     ...
   }

Es posible que la secuencia de entrada, instream, se haya visto comprometida, ya que se proporciona a través de un canal no cifrado ni autenticado.

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: 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: 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>

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: El siguiente código configura una aplicación protegida con Spring Security para utilizar un tiempo de vencimiento breve:

    @Override 
    protected void configure(HttpSecurity http) throws Exception {
        http.httpStrictTransportSecurity().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);