La extensión recibe los datos de la aplicación host en su controlador de vistas y no implementa SLComposeServiceViewController isContentValid para validar los datos que no son de confianza antes de usarlos.

Ejemplo 1: el siguiente controlador de vistas de extensión recibe datos de la aplicación host pero no implementa el método de devolución de llamada SLComposeServiceViewController isContentValid para validarlos:

    import MobileCoreServices

    class ShareViewController: SLComposeServiceViewController {
        
        ... 

        override func didSelectPost() {
            let extensionItem = extensionContext?.inputItems.first as! NSExtensionItem
            let itemProvider = extensionItem.attachments?.first as! NSItemProvider
            ...
            // Use the received items
            ...
            self.extensionContext?.completeRequestReturningItems([], completionHandler:nil)
        }

        ...
    }

Cuando una aplicación de terceros o wewbview usa una URL para comunicarse con su aplicación, la aplicación receptora debe verificar que el remitente coincida con la lista de aplicaciones permitidas que se espera que se comuniquen con esta. La aplicación receptora tiene la opción de verificar el origen de la URL de llamada mediante los métodos de delegación UIApplicationDelegate application:openURL:options: o UIApplicationDelegate application:openURL:sourceApplication:annotation:.

Ejemplo 1: la siguiente implementación del método de delegación UIApplicationDelegate application:openURL:options: no verifica el remitente de la llamada de IPC y simplemente procesa la URL de llamada:

    func application(app: UIApplication, openURL url: NSURL, options: [String : AnyObject]) -> Bool {
        return processCall(url)
    }

Cuando una aplicación de terceros o webview usa una URL para comunicarse con su aplicación, la aplicación receptora debe validar la URL que efectúa la llamada antes de realizar más acciones. La aplicación receptora tiene la opción de verificar si desea abrir la URL de llamada mediante los métodos de delegación UIApplicationDelegate application:didFinishLaunchingWithOptions: o UIApplicationDelegate application:willFinishLaunchingWithOptions:.

Ejemplo 1: la siguiente implementación del método de delegación UIApplicationDelegate application:didFinishLaunchingWithOptions: no valida la URL de llamada y siempre procesa la URL que no es de confianza:

    func application(application: UIApplication, didFinishLaunchingWithOptions launchOptions: [NSObject: AnyObject]?) -> Bool {
        return true
    }

Las aplicaciones pueden registrar esquemas de URL personalizados para que las aplicaciones de terceros se comuniquen con ellos. Si bien este es un canal de IPC simple, puede exponer a su aplicación al "secuestro de esquemas de URL". Debido a que cualquier aplicación puede registrar un esquema de URL con la condición de que no esté reservado por Apple, una aplicación malintencionada puede registrar el mismo esquema utilizado por su aplicación, lo que provoca un comportamiento indefinido. De acuerdo con la documentación de Apple: "Si más de una aplicación de terceros se registra para controlar el mismo esquema de URL, actualmente no hay ningún proceso para determinar qué aplicación recibirá ese esquema". Si la aplicación malintencionada se instala antes que su aplicación, podrá registrar el esquema y evitar que su aplicación se instale correctamente. Por otro lado, si la aplicación malintencionada se instala después de su aplicación y logra registrar el esquema, podrá secuestrar su aplicación.

Cuando se utiliza una función que puede producir valores predecibles como un origen de aleatoriedad en un contexto de seguridad, se producen errores de aleatoriedad no segura.

Los equipos son máquinas deterministas y como tales no pueden producir una aleatoriedad auténtica. Los generadores de números pseudoaleatorios (PRNG, Pseudorandom Number Generator) aproximan la aleatoriedad de forma algorítmica, a partir de un valor de inicialización desde el que se calculan los valores siguientes.

Existen dos tipos de PRNG: estadísticos y criptográficos. Los PRNG estadísticos proporcionan propiedades estadísticas útiles, pero su resultado es altamente predecible y crea una secuencia numérica fácil de reproducir que no es adecuada para aquellos casos en los que la seguridad dependa de que los valores generados sean impredecibles. Los PRNG criptográficos resuelven este problema mediante la generación de resultados que sean más difíciles de predecir. Para que un valor sea criptográficamente seguro, debe ser imposible o altamente improbable para un usuario malintencionado distinguir entre el valor aleatorio generado y un valor verdaderamente aleatorio. Por lo general, si un algoritmo PRNG no se anuncia como criptográficamente seguro, es probable que se trate de un PRNG estadístico y no debería usarse en contextos relativos a la seguridad en los que su uso podría provocar vulnerabilidades graves, como contraseñas temporales fáciles de adivinar, claves criptográficas predecibles, secuestro de sesiones y suplantación de identidad DNS.

Ejemplo 1: El siguiente código utiliza un PRNG estadístico para crear una dirección URL de un recibo que permanece activo durante un período de tiempo después de una compra.

FORM GenerateReceiptURL CHANGING baseUrl TYPE string.
    DATA: r TYPE REF TO cl_abap_random,
		  var1 TYPE i,
		  var2 TYPE i,
		  var3 TYPE n.


	GET TIME.
	var1 = sy-uzeit.
	r = cl_abap_random=>create( seed = var1 ).
	r->int31( RECEIVING value = var2 ).
	var3 = var2.
    CONCATENATE baseUrl var3 ".html" INTO baseUrl.
ENDFORM.

Este código utiliza la función CL_ABAP_RANDOM->INT31 para generar identificadores "únicos" para las páginas de recibos que crea. Como CL_ABAP_RANDOM es un PRNG estadístico, es fácil que un usuario malintencionado adivine las cadenas que genera. Aunque el diseño subyacente del sistema de recepción también es defectuoso, sería más seguro si utilizara un generador de números aleatorios que no generase identificadores de recibos predecibles, como un PRNG criptográfico.

Cuando se utiliza una función que puede producir valores predecibles como un origen de aleatoriedad en un contexto de seguridad, se producen errores de aleatoriedad no segura.

Los equipos son máquinas deterministas y como tales no pueden producir una aleatoriedad auténtica. Los generadores de números pseudoaleatorios (PRNG, Pseudorandom Number Generator) aproximan la aleatoriedad de forma algorítmica, a partir de un valor de inicialización desde el que se calculan los valores siguientes.

Existen dos tipos de PRNG: estadísticos y criptográficos. Los PRNG estadísticos proporcionan propiedades estadísticas útiles, pero su resultado es altamente predecible y crea una secuencia numérica fácil de reproducir que no es adecuada para aquellos casos en los que la seguridad dependa de que los valores generados sean impredecibles. Los PRNG criptográficos resuelven este problema mediante la generación de resultados que sean más difíciles de predecir. Para que un valor sea criptográficamente seguro, debe ser imposible o altamente improbable para un usuario malintencionado distinguir entre el valor aleatorio generado y un valor verdaderamente aleatorio. Por lo general, si un algoritmo PRNG no se anuncia como criptográficamente seguro, es probable que se trate de un PRNG estadístico y no debería usarse en contextos relativos a la seguridad en los que su uso podría provocar vulnerabilidades graves, como contraseñas temporales fáciles de adivinar, claves criptográficas predecibles, secuestro de sesiones y suplantación de identidad DNS.

Ejemplo 1: El siguiente código utiliza un PRNG estadístico para crear una dirección URL de un recibo que permanece activo durante un período de tiempo después de una compra.

string GenerateReceiptURL(string baseUrl) {
    Random Gen = new Random();
    return (baseUrl + Gen.Next().toString() + ".html");
}

Este código utiliza la función Random.Next() para generar identificadores "únicos" para las páginas de recibos que crea. Como Random.Next() es un PRNG estadístico, es fácil que un usuario malintencionado adivine las cadenas que genera. Aunque el diseño subyacente del sistema de recepción también es defectuoso, sería más seguro si utilizara un generador de números aleatorios que no generase identificadores de recibos predecibles, como un PRNG criptográfico.

Cuando se utiliza una función que puede producir valores predecibles como un origen de aleatoriedad en un contexto de seguridad, se producen errores de aleatoriedad no segura.

Los equipos son máquinas deterministas y como tales no pueden producir una aleatoriedad auténtica. Los generadores de números pseudoaleatorios (PRNG, Pseudorandom Number Generator) aproximan la aleatoriedad de forma algorítmica, a partir de un valor de inicialización desde el que se calculan los valores siguientes.

Existen dos tipos de PRNG: estadísticos y criptográficos. Los PRNG estadísticos proporcionan propiedades estadísticas útiles, pero su resultado es altamente predecible y crea una secuencia numérica fácil de reproducir que no es adecuada para aquellos casos en los que la seguridad dependa de que los valores generados sean impredecibles. Los PRNG criptográficos resuelven este problema mediante la generación de resultados que sean más difíciles de predecir. Para que un valor sea criptográficamente seguro, debe ser imposible o altamente improbable para un usuario malintencionado distinguir entre el valor aleatorio generado y un valor verdaderamente aleatorio. Por lo general, si un algoritmo PRNG no se anuncia como criptográficamente seguro, es probable que se trate de un PRNG estadístico y no debería usarse en contextos relativos a la seguridad en los que su uso podría provocar vulnerabilidades graves, como contraseñas temporales fáciles de adivinar, claves criptográficas predecibles, secuestro de sesiones y suplantación de identidad DNS.

Ejemplo 1: El siguiente código utiliza un PRNG estadístico para crear una dirección URL de un recibo que permanece activo durante un período de tiempo después de una compra.

char* CreateReceiptURL() {
    int num;
    time_t t1;
    char *URL = (char*) malloc(MAX_URL);
    if (URL) {
        (void) time(&t1);
        srand48((long) t1);     /* use time to set seed */
        sprintf(URL, "%s%d%s", "http://test.com/", lrand48(), ".html");
    }
    return URL;
}

Este código utiliza la función lrand48() para generar identificadores "únicos" para las páginas de recibos que crea. Como lrand48() es un PRNG estadístico, es fácil que un usuario malintencionado adivine las cadenas que genera. Aunque el diseño subyacente del sistema de recepción también presenta errores, sería más seguro si utilizase un generador de números aleatorios que no crease identificadores de recepción predecibles.

Cuando se utiliza una función que puede producir valores predecibles como un origen de aleatoriedad en un contexto de seguridad, se producen errores de aleatoriedad no segura.


Los equipos son máquinas deterministas y como tales no pueden producir una aleatoriedad auténtica. Los generadores de números pseudoaleatorios (PRNG, Pseudorandom Number Generator) aproximan la aleatoriedad de forma algorítmica, a partir de un valor de inicialización desde el que se calculan los valores siguientes.

Existen dos tipos de PRNG: estadísticos y criptográficos. Los PRNG estadísticos proporcionan propiedades estadísticas útiles, pero su resultado es altamente predecible y crea una secuencia numérica fácil de reproducir que no es adecuada para aquellos casos en los que la seguridad dependa de que los valores generados sean impredecibles. Los PRNG criptográficos resuelven este problema mediante la generación de resultados que sean más difíciles de predecir. Para que un valor sea criptográficamente seguro, debe ser imposible o altamente improbable para un usuario malintencionado distinguir entre el valor aleatorio generado y un valor verdaderamente aleatorio. Por lo general, si un algoritmo PRNG no se anuncia como criptográficamente seguro, es probable que se trate de un PRNG estadístico y no debería usarse en contextos relativos a la seguridad en los que su uso podría provocar vulnerabilidades graves, como contraseñas temporales fáciles de adivinar, claves criptográficas predecibles, secuestro de sesiones y suplantación de identidad DNS.

Ejemplo 1: El siguiente código utiliza un PRNG estadístico para crear una dirección URL de un recibo que permanece activo durante un período de tiempo después de una compra.

<cfoutput>
Receipt: #baseUrl##Rand()#.cfm
</cfoutput>

Este código utiliza la función Rand() para generar identificadores "únicos" para las páginas de recibos que crea. Como Rand() es un PRNG estadístico, es fácil que un usuario malintencionado adivine las cadenas que genera. Aunque el diseño subyacente del sistema de recepción también es defectuoso, sería más seguro si utilizara un generador de números aleatorios que no generase identificadores de recibos predecibles, como un PRNG criptográfico.

Cuando se utiliza una función que puede producir valores predecibles como un origen de aleatoriedad en un contexto de seguridad, se producen errores de aleatoriedad no segura.

Los equipos son máquinas deterministas y, como tales, no pueden producir una aleatoriedad auténtica. Los generadores de números pseudoaleatorios (PRNG, Pseudorandom Number Generator) aproximan la aleatoriedad de forma algorítmica, a partir de un valor de inicialización desde el que se calculan los valores siguientes.

Existen dos tipos de PRNG: estadísticos y criptográficos. Los PRNG estadísticos proporcionan propiedades estadísticas útiles. Sin embargo, su resultado es altamente predecible y crea una secuencia numérica fácil de reproducir que no es adecuada para aquellos casos en los que la seguridad dependa de que los valores generados sean impredecibles. Los PRNG criptográficos resuelven este problema mediante la generación de resultados que sean más difíciles de predecir. Para que un valor sea criptográficamente seguro, debe ser imposible o altamente improbable para un usuario malintencionado distinguir entre el valor aleatorio generado y un valor verdaderamente aleatorio. Por lo general, si un algoritmo PRNG no se anuncia como criptográficamente seguro, es probable que se trate de un PRNG estadístico y no debería usarse en contextos relativos a la seguridad en los que su uso podría provocar vulnerabilidades graves, como contraseñas temporales fáciles de adivinar, claves criptográficas predecibles, secuestro de sesiones y suplantación de identidad DNS.

Ejemplo 1: El siguiente código utiliza un PRNG estadístico para crear una clave RSA.

import "math/rand"
...
var mathRand = rand.New(rand.NewSource(1))
rsa.GenerateKey(mathRand, 2048)

Este código utiliza la función rand.New() a fin de generar aleatoridad para una clave RSA. Como rand.New() es un PRNG estadístico, es fácil que un atacante adivine los valores que genera.

Cuando se utiliza una función que puede producir valores predecibles como un origen de aleatoriedad en un contexto de seguridad, se producen errores de aleatoriedad no segura.

Los equipos son máquinas deterministas y como tales no pueden producir una aleatoriedad auténtica. Los generadores de números pseudoaleatorios (PRNG, Pseudorandom Number Generator) aproximan la aleatoriedad de forma algorítmica, a partir de un valor de inicialización desde el que se calculan los valores siguientes.

Existen dos tipos de PRNG: estadísticos y criptográficos. Los PRNG estadísticos proporcionan propiedades estadísticas útiles, pero su resultado es altamente predecible y crea una secuencia numérica fácil de reproducir que no es adecuada para aquellos casos en los que la seguridad dependa de que los valores generados sean impredecibles. Los PRNG criptográficos resuelven este problema mediante la generación de resultados que sean más difíciles de predecir. Para que un valor sea criptográficamente seguro, debe ser imposible o altamente improbable para un usuario malintencionado distinguir entre el valor aleatorio generado y un valor verdaderamente aleatorio. Por lo general, si un algoritmo PRNG no se anuncia como criptográficamente seguro, es probable que se trate de un PRNG estadístico y no debería usarse en contextos relativos a la seguridad en los que su uso podría provocar vulnerabilidades graves, como contraseñas temporales fáciles de adivinar, claves criptográficas predecibles, secuestro de sesiones y suplantación de identidad DNS.

Ejemplo 1: El siguiente código utiliza un PRNG estadístico para crear una dirección URL de un recibo que permanece activo durante un período de tiempo después de una compra.

function genReceiptURL (baseURL){
  var randNum = Math.random();
  var receiptURL = baseURL + randNum + ".html";
  return receiptURL;
}

Este código utiliza la función Math.random() para generar identificadores "únicos" para las páginas de recibos que crea. Como Math.random() es un PRNG estadístico, es fácil que un usuario malintencionado adivine las cadenas que genera. Aunque el diseño subyacente del sistema de recepción también es defectuoso, sería más seguro si utilizara un generador de números aleatorios que no generase identificadores de recibos predecibles, como un PRNG criptográfico.

Cuando se utiliza una función que puede producir valores predecibles como un origen de aleatoriedad en un contexto de seguridad, se producen errores de aleatoriedad no segura.

Los equipos son máquinas deterministas y, como tales, no pueden producir una aleatoriedad auténtica. Los generadores de números pseudoaleatorios (PRNG, Pseudorandom Number Generator) aproximan la aleatoriedad de forma algorítmica, a partir de un valor de inicialización desde el que se calculan los valores siguientes.

Existen dos tipos de PRNG: estadísticos y criptográficos. Los PRNG estadísticos proporcionan propiedades estadísticas útiles, pero su resultado es altamente predecible y crea una secuencia numérica fácil de reproducir que no es adecuada para aquellos casos en los que la seguridad dependa de que los valores generados sean impredecibles. Los PRNG criptográficos resuelven este problema mediante la generación de resultados que sean más difíciles de predecir. Para que un valor sea criptográficamente seguro, debe ser imposible o altamente improbable para un usuario malintencionado distinguir entre el valor aleatorio generado y un valor verdaderamente aleatorio. Por lo general, si un algoritmo PRNG no se anuncia como criptográficamente seguro, es probable que se trate de un PRNG estadístico y no debería usarse en contextos relativos a la seguridad en los que su uso podría provocar vulnerabilidades graves, como contraseñas temporales fáciles de adivinar, claves criptográficas predecibles, secuestro de sesiones y suplantación de identidad DNS.

Ejemplo 1: El siguiente código utiliza un PRNG estadístico para crear una dirección URL de un recibo que permanece activo durante un período de tiempo después de una compra.

fun GenerateReceiptURL(baseUrl: String): String {
    val ranGen = Random(Date().getTime())
    return baseUrl + ranGen.nextInt(400000000).toString() + ".html"
}

Este código utiliza la función Random.nextInt() para generar identificadores "únicos" para las páginas de recibos que cree. Como Random.nextInt() es un PRNG estadístico, es fácil que un atacante adivine las cadenas que genera. Aunque el diseño subyacente del sistema de recepción también es defectuoso, sería más seguro si utilizara un generador de números aleatorios que no generase identificadores de recibos predecibles, como un PRNG criptográfico.

Cuando se utiliza una función que puede producir valores predecibles como un origen de aleatoriedad en un contexto de seguridad, se producen errores de aleatoriedad no segura.

Los equipos son máquinas deterministas y como tales no pueden producir una aleatoriedad auténtica. Los generadores de números pseudoaleatorios (PRNG, Pseudorandom Number Generator) aproximan la aleatoriedad de forma algorítmica, a partir de un valor de inicialización desde el que se calculan los valores siguientes.

Existen dos tipos de PRNG: estadísticos y criptográficos. Los PRNG estadísticos proporcionan propiedades estadísticas útiles, pero su resultado es altamente predecible y crea una secuencia numérica fácil de reproducir que no es adecuada para aquellos casos en los que la seguridad dependa de que los valores generados sean impredecibles. Los PRNG criptográficos resuelven este problema mediante la generación de resultados que sean más difíciles de predecir. Para que un valor sea criptográficamente seguro, debe ser imposible o altamente improbable para un usuario malintencionado distinguir entre el valor aleatorio generado y un valor verdaderamente aleatorio. Por lo general, si un algoritmo PRNG no se anuncia como criptográficamente seguro, es probable que se trate de un PRNG estadístico y no debería usarse en contextos relativos a la seguridad en los que su uso podría provocar vulnerabilidades graves, como contraseñas temporales fáciles de adivinar, claves criptográficas predecibles, secuestro de sesiones y suplantación de identidad DNS.

Ejemplo 1: El siguiente código utiliza un PRNG estadístico para crear una dirección URL de un recibo que permanece activo durante un período de tiempo después de una compra.

  function genReceiptURL($baseURL) {
    $randNum = rand();
    $receiptURL = $baseURL . $randNum . ".html";
    return $receiptURL;
  }

Este código utiliza la función rand() para generar identificadores "únicos" para las páginas de recibos que crea. Como rand() es un PRNG estadístico, es fácil que un usuario malintencionado adivine las cadenas que genera. Aunque el diseño subyacente del sistema de recepción también es defectuoso, sería más seguro si utilizara un generador de números aleatorios que no generase identificadores de recibos predecibles, como un PRNG criptográfico.

Cuando se utiliza una función que puede producir valores predecibles como un origen de aleatoriedad en un contexto de seguridad, se producen errores de aleatoriedad no segura.

Los equipos son máquinas deterministas y como tales no pueden producir una aleatoriedad auténtica. Los generadores de números pseudoaleatorios (PRNG, Pseudorandom Number Generator) aproximan la aleatoriedad de forma algorítmica, a partir de un valor de inicialización desde el que se calculan los valores siguientes.

Existen dos tipos de PRNG: estadísticos y criptográficos. Los PRNG estadísticos proporcionan propiedades estadísticas útiles, pero su resultado es altamente predecible y crea una secuencia numérica fácil de reproducir que no es adecuada para aquellos casos en los que la seguridad dependa de que los valores generados sean impredecibles. Los PRNG criptográficos resuelven este problema mediante la generación de resultados que sean más difíciles de predecir. Para que un valor sea criptográficamente seguro, debe ser imposible o altamente improbable para un usuario malintencionado distinguir entre el valor aleatorio generado y un valor verdaderamente aleatorio. Por lo general, si un algoritmo PRNG no se anuncia como criptográficamente seguro, es probable que se trate de un PRNG estadístico y no debería usarse en contextos relativos a la seguridad en los que su uso podría provocar vulnerabilidades graves, como contraseñas temporales fáciles de adivinar, claves criptográficas predecibles, secuestro de sesiones y suplantación de identidad DNS.

Ejemplo 1: El siguiente código utiliza un PRNG estadístico para crear una dirección URL de un recibo que permanece activo durante un período de tiempo después de una compra.

CREATE or REPLACE FUNCTION CREATE_RECEIPT_URL
  RETURN VARCHAR2
AS
  rnum VARCHAR2(48);
  time TIMESTAMP;
  url VARCHAR2(MAX_URL)
BEGIN
  time := SYSTIMESTAMP;
  DBMS_RANDOM.SEED(time);
  rnum := DBMS_RANDOM.STRING('x', 48);
  url := 'http://test.com/' || rnum || '.html';
  RETURN url;
END

Este código utiliza la función DBMS_RANDOM.SEED() para generar identificadores "únicos" para las páginas de recibos que crea. Como DBMS_RANDOM.SEED() es un PRNG estadístico, es fácil que un usuario malintencionado adivine las cadenas que genera. Aunque el diseño subyacente del sistema de recepción también presenta errores, sería más seguro si utilizase un generador de números aleatorios que no crease identificadores de recepción predecibles.

Cuando se utiliza una función que puede producir valores predecibles como un origen de aleatoriedad en un contexto de seguridad, se producen errores de aleatoriedad no segura.

Los equipos son máquinas deterministas y como tales no pueden producir una aleatoriedad auténtica. Los generadores de números pseudoaleatorios (PRNG, Pseudorandom Number Generator) aproximan la aleatoriedad de forma algorítmica, a partir de un valor de inicialización desde el que se calculan los valores siguientes.

Existen dos tipos de PRNG: estadísticos y criptográficos. Los PRNG estadísticos proporcionan propiedades estadísticas útiles, pero su resultado es altamente predecible y crea una secuencia numérica fácil de reproducir que no es adecuada para aquellos casos en los que la seguridad dependa de que los valores generados sean impredecibles. Los PRNG criptográficos resuelven este problema mediante la generación de resultados que sean más difíciles de predecir. Para que un valor sea criptográficamente seguro, debe ser imposible o altamente improbable para un usuario malintencionado distinguir entre el valor aleatorio generado y un valor verdaderamente aleatorio. Por lo general, si un algoritmo PRNG no se anuncia como criptográficamente seguro, es probable que se trate de un PRNG estadístico y no debería usarse en contextos relativos a la seguridad en los que su uso podría provocar vulnerabilidades graves, como contraseñas temporales fáciles de adivinar, claves criptográficas predecibles, secuestro de sesiones y suplantación de identidad DNS.

Ejemplo 1: El siguiente código utiliza un PRNG estadístico para crear una dirección URL de un recibo que permanece activo durante un período de tiempo después de una compra.

    def genReceiptURL(self,baseURL):
        randNum = random.random()
        receiptURL = baseURL + randNum + ".html"
        return receiptURL

Este código utiliza la función rand() para generar identificadores "únicos" para las páginas de recibos que crea. Como rand() es un PRNG estadístico, es fácil que un usuario malintencionado adivine las cadenas que genera. Aunque el diseño subyacente del sistema de recepción también es defectuoso, sería más seguro si utilizara un generador de números aleatorios que no generase identificadores de recibos predecibles, como un PRNG criptográfico.

Cuando se utiliza una función que puede producir valores predecibles como un origen de aleatoriedad en un contexto de seguridad, se producen errores de aleatoriedad no segura.

Los equipos son máquinas deterministas y como tales no pueden producir una aleatoriedad auténtica. Los generadores de números pseudoaleatorios (PRNG, Pseudorandom Number Generator) aproximan la aleatoriedad de forma algorítmica, a partir de un valor de inicialización desde el que se calculan los valores siguientes.

Existen dos tipos de PRNG: estadísticos y criptográficos. Los PRNG estadísticos proporcionan propiedades estadísticas útiles, pero su resultado es altamente predecible y crea una secuencia numérica fácil de reproducir que no es adecuada para aquellos casos en los que la seguridad dependa de que los valores generados sean impredecibles. Los PRNG criptográficos resuelven este problema mediante la generación de resultados que sean más difíciles de predecir. Para que un valor sea criptográficamente seguro, debe ser imposible o altamente improbable para un usuario malintencionado distinguir entre el valor aleatorio generado y un valor verdaderamente aleatorio. Por lo general, si un algoritmo PRNG no se anuncia como criptográficamente seguro, es probable que se trate de un PRNG estadístico y no debería usarse en contextos relativos a la seguridad en los que su uso podría provocar vulnerabilidades graves, como contraseñas temporales fáciles de adivinar, claves criptográficas predecibles, secuestro de sesiones y suplantación de identidad DNS.

Ejemplo 1: El siguiente código utiliza un PRNG estadístico para crear una dirección URL de un recibo que permanece activo durante un período de tiempo después de una compra.

def generateReceiptURL(baseUrl) {
  randNum = rand(400000000)
  return ("#{baseUrl}#{randNum}.html");
}

Este código utiliza la función Kernel.rand() para generar identificadores "únicos" para las páginas de recibos que crea. Como Kernel.rand() es un PRNG estadístico, es fácil que un usuario malintencionado adivine las cadenas que genera.

Cuando se utiliza una función que puede producir valores predecibles como un origen de aleatoriedad en un contexto de seguridad, se producen errores de aleatoriedad no segura.

Los equipos son máquinas deterministas y como tales no pueden producir una aleatoriedad auténtica. Los generadores de números pseudoaleatorios (PRNG, Pseudorandom Number Generator) aproximan la aleatoriedad de forma algorítmica, a partir de un valor de inicialización desde el que se calculan los valores siguientes.

Existen dos tipos de PRNG: estadísticos y criptográficos. Los PRNG estadísticos proporcionan propiedades estadísticas útiles, pero su resultado es altamente predecible y crea una secuencia numérica fácil de reproducir que no es adecuada para aquellos casos en los que la seguridad dependa de que los valores generados sean impredecibles. Los PRNG criptográficos resuelven este problema mediante la generación de resultados que sean más difíciles de predecir. Para que un valor sea criptográficamente seguro, debe ser imposible o altamente improbable para un usuario malintencionado distinguir entre el valor aleatorio generado y un valor verdaderamente aleatorio. Por lo general, si un algoritmo PRNG no se anuncia como criptográficamente seguro, es probable que se trate de un PRNG estadístico y no debería usarse en contextos relativos a la seguridad en los que su uso podría provocar vulnerabilidades graves, como contraseñas temporales fáciles de adivinar, claves criptográficas predecibles, secuestro de sesiones y suplantación de identidad DNS.

Ejemplo 1: El siguiente código utiliza un PRNG estadístico para crear una dirección URL de un recibo que permanece activo durante un período de tiempo después de una compra.

def GenerateReceiptURL(baseUrl : String) : String {
    val ranGen = new scala.util.Random()
    ranGen.setSeed((new Date()).getTime())
    return (baseUrl + ranGen.nextInt(400000000) + ".html")
}

Este código utiliza la función Random.nextInt() para generar identificadores "únicos" para las páginas de recibos que crea. Como Random.nextInt() es un PRNG estadístico, es fácil que un usuario malintencionado adivine las cadenas que genera. Aunque el diseño subyacente del sistema de recepción también es defectuoso, sería más seguro si utilizara un generador de números aleatorios que no generase identificadores de recibos predecibles, como un PRNG criptográfico.

Cuando se utiliza una función que puede producir valores predecibles como un origen de aleatoriedad en un contexto de seguridad, se producen errores de aleatoriedad no segura.

Los equipos son máquinas deterministas y, como tales, no pueden producir una aleatoriedad auténtica. Los generadores de números pseudoaleatorios (PRNG, Pseudorandom Number Generator) aproximan la aleatoriedad de forma algorítmica, a partir de un valor de inicialización desde el que se calculan los valores siguientes.

Existen dos tipos de PRNG: estadísticos y criptográficos. Los PRNG estadísticos proporcionan propiedades estadísticas útiles, pero su resultado es altamente predecible y crea una secuencia numérica fácil de reproducir que no es adecuada para aquellos casos en los que la seguridad dependa de que los valores generados sean impredecibles. Los PRNG criptográficos resuelven este problema mediante la generación de resultados que sean más difíciles de predecir. Para que un valor sea criptográficamente seguro, debe ser imposible o altamente improbable para un usuario malintencionado distinguir entre el valor aleatorio generado y un valor verdaderamente aleatorio. Por lo general, si un algoritmo PRNG no se anuncia como criptográficamente seguro, es probable que se trate de un PRNG estadístico y no debería usarse en contextos relativos a la seguridad en los que su uso podría provocar vulnerabilidades graves, como contraseñas temporales fáciles de adivinar, claves criptográficas predecibles, secuestro de sesiones y suplantación de identidad DNS.

Ejemplo 1: El código siguiente usa un PRNG estadístico para crear un valor aleatorio que se usa como token de restablecimiento de contraseñas.

    sqlite3_randomness(10, &reset_token)

Cuando se utiliza una función que puede producir valores predecibles como un origen de aleatoriedad en un contexto de seguridad, se producen errores de aleatoriedad no segura.

Los equipos son máquinas deterministas y como tales no pueden producir una aleatoriedad auténtica. Los generadores de números pseudoaleatorios (PRNG, Pseudorandom Number Generator) aproximan la aleatoriedad de forma algorítmica, a partir de un valor de inicialización desde el que se calculan los valores siguientes.

Existen dos tipos de PRNG: estadísticos y criptográficos. Los PRNG estadísticos proporcionan propiedades estadísticas útiles, pero su resultado es altamente predecible y crea una secuencia numérica fácil de reproducir que no es adecuada para aquellos casos en los que la seguridad dependa de que los valores generados sean impredecibles. Los PRNG criptográficos resuelven este problema mediante la generación de resultados que sean más difíciles de predecir. Para que un valor sea criptográficamente seguro, debe ser imposible o altamente improbable para un usuario malintencionado distinguir entre el valor aleatorio generado y un valor verdaderamente aleatorio. Por lo general, si un algoritmo PRNG no se anuncia como criptográficamente seguro, es probable que se trate de un PRNG estadístico y no debería usarse en contextos relativos a la seguridad en los que su uso podría provocar vulnerabilidades graves, como contraseñas temporales fáciles de adivinar, claves criptográficas predecibles, secuestro de sesiones y suplantación de identidad DNS.

Ejemplo 1: El siguiente código utiliza un PRNG estadístico para crear una dirección URL de un recibo que permanece activo durante un período de tiempo después de una compra.

...
Function genReceiptURL(baseURL)
dim randNum
randNum = Rnd()
genReceiptURL = baseURL & randNum & ".html"
End Function
...

Este código utiliza la función Rnd() para generar identificadores "únicos" para las páginas de recibos que crea. Como Rnd() es un PRNG estadístico, es fácil que un usuario malintencionado adivine las cadenas que genera. Aunque el diseño subyacente del sistema de recepción también es defectuoso, sería más seguro si utilizara un generador de números aleatorios que no generase identificadores de recibos predecibles, como un PRNG criptográfico.

A las funciones que generan valores aleatorios o pseudoaleatorios, a las que se pasa un valor de inicialización, no se les debe llamar con un argumento constante. Si un generador de números pseudoaleatorios (como la clase CL_ABAP_RANDOM o sus variantes) se inicializa con un valor constante específico, los valores devueltos por GET_NEXT, INT y métodos similares que devuelven o asignan valores son predecibles para un atacante que puede recopilar varios resultados de PRNG.

Ejemplo 1: En el siguiente extracto de código, los valores que produce el objeto random_gen2 son predecibles desde el objeto random_gen1.

		DATA: random_gen1 TYPE REF TO cl_abap_random,
			  random_gen2 TYPE REF TO cl_abap_random,
			  var1 TYPE i,
			  var2 TYPE i.

		random_gen1 = cl_abap_random=>create( seed = '1234' ).

		DO 10 TIMES.
			CALL METHOD random_gen1->int
				RECEIVING
			value  = var1.

			WRITE:/ var1.
		ENDDO.

		random_gen2 = cl_abap_random=>create( seed = '1234' ).

		DO 10 TIMES.
			CALL METHOD random_gen2->int
				RECEIVING
			value  = var2.

			WRITE:/ var2.
		ENDDO.

En este ejemplo, los generadores de números pseudoaleatorios: random_gen1 y random_gen2 se inicializaron de forma idéntica, por lo que var1 = var2

A las funciones que generan valores aleatorios o pseudoaleatorios, a las que se pasa un valor de inicialización, no se les debe llamar con un argumento constante. Si un generador de números pseudoaleatorios (como rand()) se inicializa con un valor específico (mediante una función como srand(unsigned int)), los valores devueltos por rand() y métodos similares que devuelven o asignan valores son predecibles para un usuario malintencionado que puede recopilar varios resultados de PRNG.

Ejemplo 1: Los valores que produce el generador de números pseudoaleatorios son predecibles en los dos primeros bloques porque ambos comienzan con el mismo valor de inicialización.

        srand(2223333);
        float randomNum = (rand() % 100);
        syslog(LOG_INFO, "Random: %1.2f", randomNum);
        randomNum = (rand() % 100);
        syslog(LOG_INFO, "Random: %1.2f", randomNum);

        srand(2223333);
        float randomNum2 = (rand() % 100);
        syslog(LOG_INFO, "Random: %1.2f", randomNum2);
        randomNum2 = (rand() % 100);
        syslog(LOG_INFO, "Random: %1.2f", randomNum2);

        srand(1231234);
        float randomNum3 = (rand() % 100);
        syslog(LOG_INFO, "Random: %1.2f", randomNum3);
        randomNum3 = (rand() % 100);
        syslog(LOG_INFO, "Random: %1.2f", randomNum3);

En este ejemplo, los resultados de randomNum1 y randomNum2 se inicializan de manera idéntica, de modo que cada llamada a rand() después de la llamada que inicializa el generador de números pseudoaleatorios srand(2223333) producirá los mismos resultados en el mismo orden de llamada. Por ejemplo, la salida podría ser parecida a esta:

Random: 32.00
Random: 73.00
Random: 32.00
Random: 73.00
Random: 15.00
Random: 75.00

Estos resultados no son aleatorios en absoluto.

A las funciones que generan valores aleatorios o pseudoaleatorios, a las que se pasa un valor de inicialización, no se les debe llamar con un argumento constante. Si un generador de números pseudoaleatorios (PRNG) se inicializa con un valor específico (usando funciones como math.Rand.New(Source)), los valores devueltos por math.Rand.Int() y otros métodos similares que devuelven o asignan valores son predecibles para un atacante que puede recopilar varios resultados de PRNG.

Ejemplo 1: Los valores que produce el generador de números pseudoaleatorios son predecibles en los dos primeros bloques porque ambos comienzan con el mismo valor de inicialización.

  randomGen := rand.New(rand.NewSource(12345))
  randomInt1 := randomGen.nextInt()
  
  randomGen.Seed(12345)
  randomInt2 := randomGen.nextInt()

En este ejemplo, los PRNG se inicializaron de forma idéntica, de modo que cada llamada a nextInt() después de la llamada que inicializó el generador de números pseudoaleatorios (randomGen.Seed(12345)), resulta en las mismas salidas y en el mismo orden.

A las funciones que generan valores aleatorios o pseudoaleatorios, a las que se pasa un valor de inicialización, no se les debe llamar con un argumento constante. Si un generador de números pseudoaleatorios (como Random) se inicializa con un valor específico (usando una función como Random(Int)), los valores devueltos por Random.nextInt() y métodos similares que devuelven o asignan valores son predecibles para un atacante que puede recopilar varios resultados de PRNG.

Ejemplo 1: Los valores que produce el objeto RandomrandomGen2 son predecibles desde el objeto RandomrandomGen1.

        val randomGen1 = Random(12345)
        val randomInt1 = randomGen1.nextInt()
        val byteArray1 = ByteArray(4)
        randomGen1.nextBytes(byteArray1)

        val randomGen2 = Random(12345)
        val randomInt2 = randomGen2.nextInt()
        val byteArray2 = ByteArray(4)
        randomGen2.nextBytes(byteArray2)

En este ejemplo, los generadores de números pseudoaleatorios: randomGen1 y randomGen2 se inicializaron de forma idéntica, por lo que randomInt1 == randomInt2 y los valores correspondientes de las matrices byteArray1 y byteArray2 son iguales.

A las funciones que generan valores pseudoaleatorios, a las que se pasa un valor de inicialización, no se les debe llamar con un argumento de entero constante. Si se inicializa un generador de números pseudoaleatorios con un valor específico, los valores devueltos son predecibles.

Ejemplo 1: Los valores que produce el generador de números pseudoaleatorios son predecibles en los dos primeros bloques porque ambos comienzan con el mismo valor de inicialización.

...
import random
random.seed(123456)
print "Random: %d" % random.randint(1,100)
print "Random: %d" % random.randint(1,100)
print "Random: %d" % random.randint(1,100)

random.seed(123456)
print "Random: %d" % random.randint(1,100)
print "Random: %d" % random.randint(1,100)
print "Random: %d" % random.randint(1,100)
...

En este ejemplo los PRNG se inicializaron de manera idéntica, de modo que cada llamada a randint() después de la llamada que inicializó el generador de números pseudoaleatorios (random.seed(123456)) generará los mismos resultados en la misma salida en el mismo orden. Por ejemplo, la salida podría ser parecida a esta:

Random: 81
Random: 80
Random: 3
Random: 81
Random: 80
Random: 3

Estos resultados no son aleatorios en absoluto.

A las funciones que generan valores aleatorios o pseudoaleatorios, a las que se pasa un valor de inicialización, no se les debe llamar con un argumento constante. Si un generador de números pseudoaleatorios (como Random) se inicializa con un valor específico (usando una función como Random.setSeed()), los valores devueltos por Random.nextInt() y métodos similares que devuelven o asignan valores son predecibles para un atacante que puede recopilar varios resultados de PRNG.

Ejemplo 1: Los valores que produce el objeto RandomrandomGen2 son predecibles desde el objeto RandomrandomGen1.

        val randomGen1 = new Random()
        randomGen1.setSeed(12345)
        val randomInt1 = randomGen1.nextInt()
        val bytes1 = new byte[4]
        randomGen1.nextBytes(bytes1)

        val randomGen2 = new Random()
        randomGen2.setSeed(12345)
        val randomInt2 = randomGen2.nextInt()
        val bytes2 = new byte[4]
        randomGen2.nextBytes(bytes2)

En este ejemplo, los generadores de números pseudoaleatorios: randomGen1 y randomGen2 se inicializaron de forma idéntica, por lo que randomInt1 == randomInt2 y los valores correspondientes de las matrices bytes1[] y bytes2[] son iguales.

La clase CL_ABAP_RANDOM (o sus variantes) no deben inicializarse con un argumento contaminado. Al hacerlo, se permite que un usuario malintencionado controle el valor usado para inicializar el generador de números pseudoaleatorios y, por lo tanto, que pueda predecir la secuencia de valores producida por las llamadas a métodos como los siguientes: GET_NEXT, INT, FLOAT, PACKED.

A las funciones que generan valores aleatorios o pseudoaleatorios (como rand()), a las que se pasa un valor de inicialización (como srand()), no se les debe llamar con un argumento contaminado. Al hacerlo, se permite que un usuario malintencionado controle el valor usado para inicializar el generador de números pseudoaleatorios y, por lo tanto, que pueda predecir la secuencia de valores (normalmente enteros) producida por las llamadas al generador de números pseudoaleatorios.

A las funciones que generan valores pseudoaleatorios, tales como ed25519.NewKeyFromSeed(), no se les debe llamar con un argumento contaminado. Si se hace, se permite que un usuario malintencionado controle el valor que se utiliza para inicializar el generador de números pseudoaleatorios, y así pueda predecir la secuencia de valores que producen las llamadas al generador de números pseudoaleatorios.

Random.setSeed() no debe llamarse con un argumento de entero contaminado. Si se hace, se permite que un usuario malintencionado controle el valor que se utiliza para inicializar el generador de números pseudoaleatorios, y así pueda predecir la secuencia de valores (normalmente enteros) que producen las llamadas a Random.nextInt(), Random.nextLong(), Random.nextDouble(), o que devuelve Random.nextBoolean() o que se establecen en Random.nextBytes(ByteArray).

Las funciones que generan valores pseudoaleatorios (como random.randint()) no se deben llamar con un argumento contaminado. Al hacerlo, se permite que un usuario malintencionado controle el valor usado para inicializar el generador de números pseudoaleatorios y, por lo tanto, que pueda predecir la secuencia de valores (normalmente enteros) producida por las llamadas al generador de números pseudoaleatorios.

Random.setSeed() no debe llamarse con un argumento de entero contaminado. Si se hace, se permite que un usuario malintencionado controle el valor que se utiliza para inicializar el generador de números pseudoaleatorios, y así pueda predecir la secuencia de valores (normalmente enteros) que producen las llamadas a Random.nextInt(), Random.nextShort(), Random.nextLong(), o que devuelve Random.nextBoolean() o que se establecen en Random.nextBytes(byte[]).

La falta de un origen de entropía adecuado para el generador de números aleatorios o pseudoaleatorios puede dar lugar a la denegación del servicio o a la generación de secuencias de números predecibles. Si el generador de números aleatorios o pseudoaleatorios utiliza un origen de entropía que se agota, el programa puede interrumpirse o incluso bloquearse, dando lugar a una denegación del servicio. De forma alternativa, el generador de números aleatorios o pseudoaleatorios puede producir números predecibles. Una fuente de números aleatorios débil podría llevar a vulnerabilidades como contraseñas temporales fáciles de adivinar, claves criptográficas predecibles, secuestro de sesiones y suplantación de identidad DNS.

Ejemplo 1: el código siguiente utiliza el reloj del sistema como origen de entropía:

...
import time
import random

random.seed(time.time())
...

El reloj del sistema no es un buen origen de entropía porque genera valores predecibles. Lo mismo ocurre con otros orígenes de aleatoriedad no basados en hardware, como búferes de sistema/entrada/salida, direcciones o números de serie de usuario/sistema/hardware/red o la entrada del usuario.

La infraestructura de clave pública (PKI) se basa en entidades de certificación de confianza; no obstante, el creciente número de entidades de certificación comprometidas implica que sus certificados raíz ya no son de confianza y que, por lo tanto, tampoco se puede confiar en los certificados que firman dichas entidades de certificación. Los atacantes en posesión de estos certificados comprometidos podrían interceptar todo el tráfico SSL/TLS que confíe en estas entidades de certificación.

Las firmas de las entidades de certificación son necesarias para las herramientas de comunicación de red generales, como los exploradores que se conectan a puntos finales de red arbitrarios y que no tienen conocimientos previos sobre las entidades de certificación que firman los certificados SSL/TLS de dichos puntos finales. Las aplicaciones móviles que se conectan a un número limitado de servidores back-end pueden beneficiarse del conocimiento de una breve lista de las entidades de certificación de confianza que pueden usar dichos servidores para firmar sus certificados, así como "asignar" dichos certificados o claves públicas en las aplicaciones, de modo que la confianza se otorgue solo a los certificados que espera la aplicación.

Ejemplo 1: El siguiente ejemplo establece una conexión SSL/TLS mediante las entidades de certificación del sistema predeterminadas cargadas con anterioridad.

val url = URL("https://myserver.org")
val data = url.readBytes()

Dado que no se ha cambiado el SSLSocketFactory subyacente usado por la URLConnection, se usará el valor predeterminado que confiará en todas las entidades de certificación presentes en el almacén de claves de Android predeterminado.

La infraestructura de clave pública (PKI) se basa en entidades de certificación de confianza; no obstante, el creciente número de entidades de certificación comprometidas implica que sus certificados raíz ya no son de confianza y que, por lo tanto, tampoco se puede confiar en los certificados que firman dichas entidades de certificación. Los atacantes en posesión de estos certificados comprometidos podrían interceptar todo el tráfico SSL/TLS que confíe en estas entidades de certificación.

Las firmas de las entidades de certificación son necesarias para las herramientas de comunicación de red generales, como los exploradores que se conectan a extremos de red arbitrarios y que no tienen conocimientos previos sobre las entidades de certificación que firman los certificados SSL/TLS de dichos extremos. Las aplicaciones móviles que se conectan a un número limitado de servidores back-end pueden beneficiarse del conocimiento de una lista de entidades de certificación de confianza que pueden usar dichos servidores para firmar sus certificados, así como "asignar" dichos certificados o claves públicas en las aplicaciones, de modo que la confianza se otorgue solo a los certificados que espera la aplicación.

Ejemplo 1: El siguiente ejemplo establece una conexión SSL/TLS mediante las entidades de certificación del sistema predeterminadas cargadas con anterioridad.

NSString* requestString = @"https://myserver.org";
NSURL* requestUrl = [NSURL URLWithString:requestString];
NSURLRequest* request = [NSURLRequest requestWithURL:requestUrl
                                         cachePolicy:NSURLRequestReloadIgnoringLocalCacheData
                                     timeoutInterval:10.0f];
NSURLConnection* connection = [[NSURLConnection alloc] initWithRequest:request delegate:self];

Dado que no hay métodos NSURLConnectionDelegate definidos para gestionar la comprobación de certificados, se usarán los del sistema que confían en todas las entidades de certificación presentes en el almacén de claves predeterminado de iOS.

La infraestructura de clave pública (PKI) se basa en entidades de certificación de confianza; no obstante, el creciente número de entidades de certificación comprometidas implica que sus certificados raíz ya no son de confianza y que, por lo tanto, tampoco se puede confiar en los certificados que firman dichas entidades de certificación. Los atacantes en posesión de estos certificados comprometidos podrían interceptar todo el tráfico SSL/TLS que confíe en estas entidades de certificación.

Las firmas de las entidades de certificación son necesarias para las herramientas de comunicación de red generales, como los exploradores que se conectan a extremos de red arbitrarios y que no tienen conocimientos previos sobre las entidades de certificación que firman los certificados SSL/TLS de dichos extremos. Las aplicaciones móviles que se conectan a un número limitado de servidores back-end pueden beneficiarse del conocimiento de una lista de entidades de certificación de confianza que pueden usar dichos servidores para firmar sus certificados, así como "asignar" dichos certificados o claves públicas en las aplicaciones, de modo que la confianza se otorgue solo a los certificados que espera la aplicación.

Ejemplo 1: El siguiente ejemplo establece una conexión SSL/TLS mediante las entidades de certificación del sistema predeterminadas cargadas con anterioridad.

let requestString = NSURL(string: "https://myserver.org") 
let requestUrl : NSURL = NSURL(string:requestString)!;
let request : NSURLRequest = NSURLRequest(URL:requestUrl);
let connection : NSURLConnection = NSURLConnection(request:request, delegate:self)!;

Dado que no hay métodos NSURLConnectionDelegate definidos para gestionar la comprobación de certificados, se usarán los del sistema que confían en todas las entidades de certificación presentes en el almacén de claves predeterminado de iOS.

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. En otros casos, esto se puede deshabilitar de forma explícita, ya sea intencionalmente o no.

Ejemplo 1: Esta aplicación siempre comprueba que la cadena de certificados sea correcta, por lo que confía en todos los certificados.

...
private bool CertificateCheck(object sender, X509Certificate certificate, X509Chain chain, SslPolicyErrors sslPolicyErrors)
{
  ...
  return true; 
}
...
  HttpWebRequest webRequest = (HttpWebRequest) WebRequest.Create("https://www.myTrustedSite.com");
  webRequest.ServerCertificateValidationCallback = CertificateCheck;
  WebResponse response = webRequest.GetResponse();
...

Al intentar conectarse a "https://www.myTrustedSite.com", esta aplicación aceptará sin objeciones un certificado emitido para "hackedserver.com". La aplicación podría filtrar entonces información de usuario confidencial en una conexión SSL interrumpida en el servidor pirateado.

En algunas bibliotecas que utilizan conexiones SSL, es posible deshabilitar la verificación del certificado de servidor. Esto equivale a confiar en todos los certificados.

Ejemplo 1: esta aplicación deshabilita explícitamente la verificación del certificado:

...
  SSL_CTX_set_verify(ctx, SSL_VERIFY_NONE, verify_callback);
...

Al intentar la conexión con un host válido, esta aplicación aceptará sin objeciones un certificado emitido para "hackedserver.com". La aplicación podría filtrar entonces información de usuario confidencial en una conexión SSL interrumpida en el servidor pirateado.

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 expresamente el certificado de servidor.

    ...
    config := &tls.Config{
        // Set InsecureSkipVerify to skip the default validation
        InsecureSkipVerify: true,
        ...
    }

    conn, err := tls.Dial("tcp", "example.com:443", conf)
    ..
    

Al intentar establecer una conexión con example.com, esta aplicación aceptará sin objeciones cualquier certificado emitido por el servidor. Esta aplicación puede filtrar información de usuario confidencial en una conexión SSL interrumpida en el servidor pirateado.

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: este servidor intenta verificar las conexiones del cliente de forma incorrecta:

...
var options = {
  key : fs.readFileSync('my-server-key.pem'),
  cert : fs.readFileSync('server-cert.pem'),
  requestCert: true,
  ...
}
https.createServer(options);
...

Cuando se crea el objeto https.Server, el parámetro requestCert se define como true, pero no se establece rejectUnauthorized, lo que establece false de forma predeterminada. Esto significa que, aunque el servidor se creó con la intención de verificar clientes en SSL, se seguirán aceptando conexiones incluso si el certificado no está autorizado con la lista de entidades de certificación proporcionadas.

Ejemplo 2: esta aplicación intenta conectarse con un servidor en SSL:

var tls = require('tls');
...
tls.connect({
  host: 'https://www.hackersite.com',
  port: '443',
  ...
  rejectUnauthorized: false,
  ...
});

En este ejemplo, como rejectUnauthorized se estableció en el valor false, significa que se aceptarán certificados no autorizados y que de todas formas se creará una conexión segura con el servidor no identificado. La aplicación podría filtrar entonces información de usuario confidencial en una conexión SSL interrumpida en el servidor pirateado.

En algunas bibliotecas que utilizan conexiones SSL, el certificado de servidor no se comprueba de forma predeterminada (o se puede configurar de forma explícita para que así sea). Esto equivale a confiar en todos los certificados.

Ejemplo 1: este código configura NSURLConnectionDelegate para que acepte cualquier certificado HTTPS:

implementation NSURLRequest (IgnoreSSL)

+ (BOOL)allowsAnyHTTPSCertificateForHost:(NSString *)host
{
  return YES;
}

@end

Al intentar conectarse a un servidor protegido con SSL usando la implementación de NSURLRequest del Example 1, no aparecerá ningún error o advertencia si el certificado del servidor que recibe la solicitud se ha firmado automáticamente (y, por lo tanto, no está verificado). Como resultado, la aplicación podría filtrar entonces información de usuario confidencial en una conexión SSL interrumpida.

En algunas bibliotecas que utilizan conexiones SSL, es posible deshabilitar la verificación del certificado de servidor. Esto equivale a confiar en todos los certificados.

Ejemplo 1: Esta aplicación no comprueba el certificado de servidor de forma predeterminada:

...
import ssl
ssl_sock = ssl.wrap_socket(s)
...

Al intentar la conexión con un host válido, esta aplicación aceptará sin objeciones un certificado emitido para "hackedserver.com". La aplicación podría filtrar entonces información de usuario confidencial en una conexión SSL interrumpida en el servidor pirateado.

En algunas bibliotecas que utilizan conexiones SSL, es posible deshabilitar la verificación del certificado de servidor. Esto equivale a confiar en todos los certificados.

Ejemplo 1: esta aplicación deshabilita explícitamente la verificación del certificado:

require 'openssl'
...
ctx = OpenSSL::SSL::SSLContext.new
ctx.verify_mode=OpenSSL::SSL::VERIFY_NONE
...

Al intentar la conexión con un host válido, esta aplicación aceptará sin objeciones un certificado emitido para "hackedserver.com". La aplicación podría filtrar entonces información de usuario confidencial en una conexión SSL interrumpida en el servidor pirateado.

En algunas bibliotecas que utilizan conexiones SSL, el certificado de servidor no se comprueba de forma predeterminada (o se puede configurar de forma explícita para que así sea). Esto equivale a confiar en todos los certificados.

Ejemplo 1: este código configura NSURLConnectionDelegate para que acepte cualquier certificado HTTPS:

class Delegate: NSObject, NSURLConnectionDelegate {
    
    ...

    func connection(connection: NSURLConnection, canAuthenticateAgainstProtectionSpace protectionSpace: NSURLProtectionSpace?) -> Bool {
        return protectionSpace?.authenticationMethod == NSURLAuthenticationMethodServerTrust
    }

    func connection(connection: NSURLConnection, willSendRequestForAuthenticationChallenge challenge: NSURLAuthenticationChallenge) {
        challenge.sender?.useCredential(NSURLCredential(forTrust: challenge.protectionSpace.serverTrust!), forAuthenticationChallenge: challenge)
        challenge.sender?.continueWithoutCredentialForAuthenticationChallenge(challenge)
    }
}

Al intentar conectarse a un servidor protegido con SSL usando la implementación de NSURLConnectionDelegate del Example 1, no aparecerá ningún error o advertencia si el certificado del servidor que recibe la solicitud se ha firmado automáticamente (y, por lo tanto, no está verificado). Como resultado, la aplicación podría filtrar entonces información de usuario confidencial en una conexión SSL interrumpida.

Ejemplo 2: en una clase NSURLSession, la validación de la cadena SSL/TLS se controla a través del método de delegación de autenticación de la aplicación, pero en lugar de proporcionar al servidor las credenciales para autenticar al usuario (o aplicación), la aplicación comprueba las credenciales que proporciona el servidor durante el intercambio SSL/TLS e indica al sistema de carga de URL si debe aceptar o rechazar esas credenciales. El siguiente código muestra un NSURLSessionDelgate que devuelve la proposedCredential del desafío recibido como una credencial para la sesión, lo que en la práctica permite eludir la verificación del servidor:

class MySessionDelegate : NSObject, NSURLSessionDelegate {
    ...
    func URLSession(session: NSURLSession, didReceiveChallenge challenge: NSURLAuthenticationChallenge, completionHandler: (NSURLSessionAuthChallengeDisposition, NSURLCredential?) -> Void) {
        ...
        completionHandler(NSURLSessionAuthChallengeDisposition.UseCredential, challenge.proposedCredential)
        ...
    }
    ...
}