En .NET, puede utilizar la clase BinaryFormatter para convertir un objeto en una secuencia binaria que contiene tanto el objeto en sí como los metadatos necesarios para reconstruirlo durante la deserialización.

El uso de la clase BinaryFormatter puede generar escenarios de deserialización inseguros donde los atacantes pueden ejecutar código arbitrario, abusar de la lógica de la aplicación o desencadenar una condición de denegación de servicio.

El uso del tipo BinaryFormatter es peligroso y no se recomienda para el procesamiento de datos, ya que no se puede proteger.

Ejemplo 1: La aplicación permite el uso de la clase BinaryFormatter no segura estableciendo la propiedad de configuración EnableUnsafeBinaryFormatterSerialization a true en el archivo runtimeConfig.json.

...
AppContext.SetSwitch("System.Runtime.Serialization.EnableUnsafeBinaryFormatterSerialization", true);
...

La API AccessibleObject permite que el programador eluda las comprobaciones de control de acceso proporcionadas por los especificadores de acceso de Java. En particular, permite que el programador permita que un objeto reflejado eluda los controles de acceso de Java y a cambio cambie el valor de los campos privados o invoque métodos privados, es decir, comportamientos que normalmente están prohibidos.

En una aplicación JSF normal, los valores se convierten y validan mediante convertidores y validadores especificados por los componentes de la interfaz de usuario. La conversión y validación en sí ocurre cuando se envía la página. Una vista que se puede marcar en una aplicación Fusion no causa el envío de páginas y, por lo tanto, no se realiza una conversión o validación similar de forma predeterminada.

Ejemplo 1: El siguiente fragmento de archivo de configuración muestra una vista de muestra, que se puede marcar como favorita, configurada para no realizar ninguna conversión o validación del parámetro de URL paramName.

...
    <bookmark>
        <method>#{paramHandler.handleParams}</method>
        <url-parameter>
            <name>paramName</name>
            <value>#{requestScope.paramName}</value>
        </url-parameter>
    </bookmark>
...

No se recomienda a los desarrolladores crear las aplicaciones con API no documentadas u ocultas. No hay garantía de que Google no quite o cambie dichas API en el futuro y, por lo tanto, estas se deben evitar. También se debe evitar el uso de estos métodos o campos porque constituyen un riesgo y podrían dañar la aplicación.

El código intenta usar el objeto Camera una vez que se ha liberado. Todas las referencias adicionales al objeto Camera sin que se vuelva a adquirir el recurso generarán una excepción y pueden provocar que se bloquee la aplicación si no se detecta la excepción.

Ejemplo 1: El siguiente código utiliza un botón de conmutación para activar o desactivar la vista previa de la cámara. Después de que el usuario pulse el botón una vez, la vista previa de la cámara se detiene y el recurso de cámara se libera. Sin embargo, si este pulsa de nuevo el botón, se llamará a startPreview() en el objeto Camera liberado anteriormente.

public class ReuseCameraActivity extends Activity {
  private Camera cam;

  ...
  private class CameraButtonListener implements OnClickListener {
      public void onClick(View v) {
          if (toggle) {
              cam.stopPreview();
              cam.release();
          }
          else {
              cam.startPreview();
          }
          toggle = !toggle;
      }
  }
  ...
}

El código intenta usar el objeto multimedia una vez que se ha liberado. Todas las referencias adicionales al objeto multimedia sin que se vuelva a adquirir el recurso generarán una excepción y pueden provocar que se bloquee la aplicación si no se detecta la excepción.

Ejemplo 1: El siguiente código usa un botón de pausa para activar o desactivar la reproducción multimedia. Después de que el usuario pulse el botón una vez, la canción o el vídeo actuales se detendrán temporalmente y se liberará el recurso de cámara. Sin embargo, si este pulsa de nuevo el botón, se llamará a start() en el recurso multimedia liberado anteriormente.

public class ReuseMediaPlayerActivity extends Activity {
  private MediaPlayer mp;

  ...
  private class PauseButtonListener implements OnClickListener {
      public void onClick(View v) {
          if (paused) {
              mp.pause();
              mp.release();
          }
          else {
              mp.start();
          }
          paused = !paused;
      }
  }
  ...
}

El código intenta usar el controlador de base de datos SQLite de Android una vez que se ha cerrado. Todas las referencias adicionales al controlador sin que se restablezca la conexión a la base de datos generarán una excepción y pueden provocar que se bloquee la aplicación si no se detecta la excepción.

Ejemplo 1: El siguiente código puede proceder de un programa que almacena temporalmente valores de usuario en la memoria caché, pero puede llamar a flushUpdates() para confirmar los cambios en el disco. El método cierra correctamente el controlador de base de datos tras escribir las actualizaciones en la base de datos. Sin embargo, cuando se llama de nuevo a flushUpdates(), se hace referencia de nuevo al objeto de base de datos sin reinicializarlo.

public class ReuseDBActivity extends Activity {
  private myDBHelper dbHelper;
  private SQLiteDatabase db;

  @Override
  public void onCreate(Bundle state) {
      ...
      db = dbHelper.getWritableDatabase();
      ...
  }
  ...

  private void flushUpdates() {
      db.insert(cached_data);     // flush cached data
      dbHelper.close();
  }
  ...
}

Las vulnerabilidades de secuestro al cargar clases de Android se presentan de dos formas:

- Un usuario malintencionado puede cambiar el nombre de los directorios que busca el programa para cargar clases, de modo que la ruta señale a un directorio que controla: este controla de forma explícita las rutas en las que se buscarán las clases.

- Un usuario malintencionado puede cambiar el entorno donde se carga la clase: este controla de forma implícita lo que significa el nombre de la ruta.

En este caso, nos preocupa principalmente el primer caso, la posibilidad de que un usuario malintencionado pueda controlar los directorios donde se buscan las clases para cargar. Las vulnerabilidades de secuestro al cargar clases de Android de este tipo tienen lugar cuando:

1. Los datos entran en la aplicación desde una fuente no confiable.



2. Los datos se utilizan como una cadena, o parte de ella, que representa un directorio de biblioteca donde buscar las clases para cargar.



3. Al ejecutar el código desde la ruta de la biblioteca, la aplicación concede al usuario malintencionado un privilegio o capacidad que, de lo contrario, no tendría.

Ejemplo 1: el siguiente código utiliza la userClassPath modificable por el usuario para determinar el directorio donde buscar las clases para cargar.

...
  productCategory = this.getIntent().getExtras().getString("userClassPath");
  DexClassLoader dexClassLoader = new DexClassLoader(productCategory, optimizedDexOutputPath.getAbsolutePath(), null, getClassLoader());
  ...

Este código permite a un usuario malintencionado cargar una biblioteca y posiblemente ejecutar código arbitrario con el privilegio elevado de la aplicación mediante la modificación de userClassPath para que señale a una ruta diferente que controla este. Como el programa no valida el valor leído del entorno, si un usuario malintencionado puede controlar el valor de userClassPath, podría engañar a la aplicación para que señalara un directorio controlado por él y, por lo tanto, cargar las clases que hubiera definido, utilizando los mismos privilegios que la aplicación original.

Ejemplo 2: el siguiente código utiliza la userOutput modificable por el usuario para determinar el directorio donde deberían escribirse los archivos DEX optimizados.

...
  productCategory = this.getIntent().getExtras().getString("userOutput");
  DexClassLoader dexClassLoader = new DexClassLoader(sanitizedPath, productCategory, null, getClassLoader());
...

Este código permite a un usuario malintencionado especificar el directorio de salida para los archivos DEX optimizados (ODEX). Esto permite a un usuario malintencionado cambiar el valor de userOutput por un directorio que controle, como por ejemplo almacenamiento externo. Una vez logrado esto, basta con reemplazar el archivo ODEX producido con un archivo ODEX malintencionado para ejecutar este con los mismos privilegios que la aplicación original.

Las aplicaciones para Android se pueden configurar para producir archivos binarios de depuración. Estos binarios proporcionan mensajes de depuración detallados y no deben usarse en entornos de producción. El atributo debuggable de la etiqueta <application> define si los binarios compilados deben incluir información de depuración.

El uso de binarios de depuración hace que una aplicación proporcione al usuario tanta información sobre sí misma como sea posible. Los binarios de depuración están diseñados para usarse en un entorno de desarrollo o prueba y pueden suponer un riesgo de seguridad si se implementan en producción. Los atacantes pueden valerse de información adicional que obtengan del resultado de seguimiento para planear ataques contra el marco de trabajo, la base de datos o cualquier otro recurso que la aplicación utilice.

Las vulnerabilidades de recorrido de ruta zip ocurren cuando un actor malintencionado puede especificar nombres de entradas de archivos zip en un archivo zip determinado. Cuando se especifica un nombre de entrada de archivo zip de forma maliciosa, un atacante puede sobrescribir el contenido de los archivos clave del sistema cuando se expande el archivo zip correspondiente. Los atacantes pueden usar expresiones de recorrido de ruta como ../ y / para acceder a archivos del sistema que de otro modo estarían fuera del alcance del programa. Las aplicaciones de Android que apuntan a Android 14 y versiones posteriores pueden, de forma predeterminada, generar una excepción cuando se detectan expresiones como ../ y / durante la extracción del archivo zip. Esta función de seguridad se puede anular o desactivar por completo.

Ejemplo 1: El siguiente código deshabilita la protección Zip Entry Overwrite.

...
dalvik.system.ZipPathValidator.clearCallback();
...

De forma predeterminada, los servidores de ASP.NET almacenan el objeto HttpSessionState, sus atributos y cualquier objeto al que hagan referencia en la memoria. Este modelo limita el estado de sesiones activas que puede alojar la memoria del sistema de un solo equipo. Para ampliar la capacidad más allá de estas limitaciones, los servidores se configuran con frecuencia para almacenar la información de estado de sesión, lo que permite ampliar la capacidad y efectuar la replicación entre varios equipos a fin de mejorar el rendimiento general. Para almacenar su estado de sesión, el servidor debe serializar el objeto HttpSessionState, para lo que es necesario que todos los objetos almacenados sean serializables.

Para poder serializar la sesión correctamente, todos los objetos que almacena la aplicación como atributos de sesión deben declarar el atributo [Serializable]. Además, si el objeto requiere métodos de serialización personalizados, también debe implementar la interfaz ISerializable.

Ejemplo 1: la siguiente clase se añade a sí misma a la sesión, pero como no es serializable, la sesión no se puede serializar correctamente.

public class DataGlob {
   String GlobName;
   String GlobValue;

   public void AddToSession(HttpSessionState session) {
     session["glob"] = this;
   }
}

La minimización mejora los tiempos de carga de páginas para las aplicaciones que incluyen archivos JavaScript al reducir su tamaño. La minimización hace referencia al proceso de eliminación de espacios en blanco, comentarios, signos de punto y coma, y llaves acortando el nombre de las variables locales y eliminando código inaccesible.

Ejemplo 1: en el siguiente código ASPX se incluye la versión no minimizada de la biblioteca jQuery de Microsoft:

...
<script src="http://applicationserver.application.com/lib/jquery/jquery-1.4.2.js" type="text/javascript"></script>
...

Las entradas sin validar son una de las principales causas de vulnerabilidades en los servicios de API web ASP.NET. Las entradas no comprobadas pueden llevar a muchas vulnerabilidades, incluidas Cross-Site Scripting, Process Control, Access Control y SQL Injection, entre otras. Aunque los servicios de API web ASP.NET normalmente no son susceptibles de ataques de corrupción de memoria, si un servicio de API web ASP.NET llama en código nativo que no realiza comprobaciones de enlaces de matriz, un atacante puede utilizar una debilidad de validación de entrada del servicio de API web ASP.NET para iniciar un ataque de buffer overflow.

Para evitar ataques de este tipo:
1. Utilice atributos de validación para anotar comprobaciones de validación mediante programación en parámetros o miembros de parámetros de objeto de enlace de modelos para acciones del servicio de API web ASP.NET.
2. Utilice ModelState.IsValid para comprobar si la validación del modelo es correcta.

Configurar el modo de validación del certificado en None desactiva todo el proceso de validación de la certificación, lo que expone la aplicación a ataques de tipo "man-in-the-middle". Este modo no debe utilizarse en entornos de producción.

Las cookies se utilizan a menudo para almacenar información importante sobre los usuarios, como información personal, tokens de autenticación y un historial de su actividad. Si esta información se almacena en texto sin formato, cualquier persona con acceso a las máquinas utilizadas para interactuar con la aplicación tendrá acceso a la información almacenada en la cookie. Peor aún, si pueden modificar arbitrariamente los datos almacenados en las cookies, los atacantes también pueden falsificar la información proporcionada a la aplicación y potencialmente alterar su comportamiento en su beneficio.

En muchos casos, una aplicación puede validar la entrada de las cookies mediante programación de acuerdo con el contexto en el que se utiliza, pero el marco de validación ASP.NET ofrece una manera excelente de proteger el contenido de la cookie y de verificar que la cookie no se haya modificado inesperadamente. Sin este método, es difícil, y a menudo imposible, establecer con un alto nivel de confianza que todas las entradas están validadas.

Las aplicaciones ASP .NET se pueden configurar para producir binarios de depuración. Estos binarios proporcionan mensajes de depuración detallados y no deben usarse en entornos de producción. El atributo debug de la etiqueta <compilation> define si los binarios compilados deben incluir información de depuración.

El uso de binarios de depuración hace que una aplicación proporcione al usuario tanta información sobre sí misma como sea posible. Los binarios de depuración están diseñados para usarse en un entorno de desarrollo o prueba y pueden suponer un riesgo de seguridad si se implementan en producción. Los atacantes pueden valerse de información adicional que obtengan del resultado de seguimiento para planear ataques contra el marco de trabajo, la base de datos o cualquier otro recurso que la aplicación utilice.

Cuanto más tiempo permanece abierta una sesión, mayor es la ventana de oportunidad que tiene un atacante para comprometer las cuentas de usuario. Mientras una sesión permanece activa, un atacante puede forzar la contraseña de un usuario, descifrar su clave de cifrado inalámbrica o controlar una sesión desde un explorador abierto. Los tiempos de espera de autenticación más prolongados también pueden evitar que se libere la memoria y acabar en una denegación de servicio si se crea una cantidad suficientemente grande de sesiones.

Ejemplo 1: El siguiente ejemplo muestra ASP.NET MVC configurado con un tiempo de espera de autenticación de una hora.

...
<configuration>
  <system.web>
  <authentication>
    <forms
      timeout="60" />
  </authentication>
  </system.web>
</configuration>
...

Si no se especifica el atributo de tiempo de espera, el tiempo de espera de autenticación predeterminado es de 30 minutos.

Los programas se pueden configurar para validar certificados X.509 de una de estas tres formas. De forma predeterminada, los certificados se validan mediante su cadena de confianza con una entidad de certificación raíz de confianza. Esta configuración se conoce como ChainTrust y proporciona el máximo nivel de seguridad de que el certificado es válido. De forma predeterminada, todos los certificados se validan mediante ChainTrust.

Para hacer uso de un certificado que una entidad de certificación raíz de confianza no haya emitido, se puede configurar un programa para que confíe en certificados emitidos por sus pares estableciendo PeerTrust o PeerOrChainTrust. Estas configuraciones no deben usarse en entornos de producción porque reducen significativamente el nivel de seguridad otorgado por los certificados.

Las cookies se utilizan a menudo para almacenar información importante sobre los usuarios, como información personal, tokens de autenticación y un historial de su actividad. Si esta información se almacena en texto sin formato, cualquier persona con acceso a las máquinas utilizadas para interactuar con la aplicación tendrá acceso a la información almacenada en la cookie. Peor aún, si pueden modificar arbitrariamente los datos almacenados en las cookies, los atacantes también pueden falsificar la información proporcionada a la aplicación y potencialmente alterar su comportamiento en su beneficio.

En muchos casos, una aplicación puede validar la entrada de las cookies mediante programación de acuerdo con el contexto en el que se utiliza, pero el marco de validación ASP.NET ofrece una manera excelente de proteger el contenido de la cookie y de verificar que la cookie no se haya modificado inesperadamente. Sin este método, es difícil, y a menudo imposible, establecer con un alto nivel de confianza que todas las entradas están validadas.

Si el atributo cacheRolesInCookie del elemento configuration/system.web/authentication/forms enweb.config se establece entrue , las funciones de cada usuario se almacenan en caché en una cookie. Si esta información se almacena en texto sin formato, cualquier persona con acceso a las máquinas utilizadas para interactuar con la aplicación tendrá acceso a la información almacenada en la cookie. Peor aún, si pueden modificar arbitrariamente los datos almacenados en las cookies, los atacantes también pueden falsificar la información proporcionada a la aplicación y potencialmente alterar su comportamiento en su beneficio.

En muchos casos, una aplicación puede validar la entrada de las cookies mediante programación de acuerdo con el contexto en el que se utiliza, pero el marco de validación ASP.NET ofrece una manera excelente de verificar que la cookie no se haya modificado inesperadamente. Sin este método, es difícil, y a menudo imposible, establecer con un alto nivel de confianza que todas las entradas están validadas.