Application resources that contain sensitive information or provide privileged functionality are generally at greater risk of exploitation. During the reconnaissance phase, an attacker makes attempts to discover such files and directories. Using predictable naming schemes for such resources makes it easier for the attacker to locate them. All the application resources that deal with sensitive functionality like authentication, administrative tasks, or handling of private information must be protected from discovery.

Separate resources responsible for storing data from resources that implement application functionality. Programmers must exercise caution when creating temporary or backup resources.

The extension receives data from the host app in its view controller and fails to implement the SLComposeServiceViewController isContentValid to validate the untrusted data received before using it.

Example 1: The following extension view controller receives data from the host app but fails to implement the SLComposeServiceViewController isContentValid callback method to validate it:

    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)
        }

        ...
    }

When a third party application or wewbview uses a URL to communicate with your application, the receiving application should verify that the sender matches an allow list of applications that are expected to communicate with it. The receiving application has the option to verify the origin of the calling URL using the UIApplicationDelegate application:openURL:options: or UIApplicationDelegate application:openURL:sourceApplication:annotation: delegate methods.

Example 1: The following implementation of the UIApplicationDelegate application:openURL:options: delegate method fails to verify the sender of the IPC call and just processes the calling URL:

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

When a third party application or webview uses a URL to communicate with your application, the receiving application should validate the calling URL before proceeding with further actions. The receiving application has the option to verify that it wants to open the calling URL using the UIApplicationDelegate application:didFinishLaunchingWithOptions: or UIApplicationDelegate application:willFinishLaunchingWithOptions: delegate methods.

Example 1: The following implementation of the UIApplicationDelegate application:didFinishLaunchingWithOptions: delegate method fails to validate the calling URL and always processes the untrusted URL:

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

Applications may register custom URL schemes for third party applications to communicate with them. Although this is a simple IPC channel, it may expose your application to "URL Scheme Hijacking". Since any application can register a URL scheme as long as it is not reserved by Apple, a malicious application may register the same scheme used by your application which results in an undefined behavior. According to Apple's documentation: "If more than one third party app registers to handle the same URL scheme, there is currently no process for determining which app will be given that scheme". If the malicious application is installed before your application, it may register the scheme and prevent your application from installing successfully. Alternatively, if the malicious application is installed after your application and it succeeds in the scheme registration, it may hijack it from your application.

Insecure randomness errors occur when a function that can produce predictable values is used as a source of randomness in a security-sensitive context.

Computers are deterministic machines, and as such are unable to produce true randomness. Pseudorandom Number Generators (PRNGs) approximate randomness algorithmically, starting with a seed from which subsequent values are calculated.

There are two types of PRNGs: statistical and cryptographic. Statistical PRNGs provide useful statistical properties, but their output is highly predictable and form an easy to reproduce numeric stream that is unsuitable for use in cases where security depends on generated values being unpredictable. Cryptographic PRNGs address this problem by generating output that is more difficult to predict. For a value to be cryptographically secure, it must be impossible or highly improbable for an attacker to distinguish between the generated random value and a truly random value. In general, if a PRNG algorithm is not advertised as being cryptographically secure, then it is probably a statistical PRNG and should not be used in security-sensitive contexts, where its use can lead to serious vulnerabilities such as easy-to-guess temporary passwords, predictable cryptographic keys, session hijacking, and DNS spoofing.

Example 1: The following code uses a statistical PRNG to create a URL for a receipt that remains active for some period of time after a purchase.

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.

This code uses the CL_ABAP_RANDOM->INT31 function to generate "unique" identifiers for the receipt pages it generates. Since CL_ABAP_RANDOM is a statistical PRNG, it is easy for an attacker to guess the strings it generates. Although the underlying design of the receipt system is also faulty, it would be more secure if it used a random number generator that did not produce predictable receipt identifiers, such as a cryptographic PRNG.

Insecure randomness errors occur when a function that can produce predictable values is used as a source of randomness in a security-sensitive context.

Computers are deterministic machines, and as such are unable to produce true randomness. Pseudorandom Number Generators (PRNGs) approximate randomness algorithmically, starting with a seed from which subsequent values are calculated.

There are two types of PRNGs: statistical and cryptographic. Statistical PRNGs provide useful statistical properties, but their output is highly predictable and form an easy to reproduce numeric stream that is unsuitable for use in cases where security depends on generated values being unpredictable. Cryptographic PRNGs address this problem by generating output that is more difficult to predict. For a value to be cryptographically secure, it must be impossible or highly improbable for an attacker to distinguish between the generated random value and a truly random value. In general, if a PRNG algorithm is not advertised as being cryptographically secure, then it is probably a statistical PRNG and should not be used in security-sensitive contexts, where its use can lead to serious vulnerabilities such as easy-to-guess temporary passwords, predictable cryptographic keys, session hijacking, and DNS spoofing.

Example 1: The following code uses a statistical PRNG to create a URL for a receipt that remains active for some period of time after a purchase.

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

This code uses the Random.Next() function to generate "unique" identifiers for the receipt pages it generates. Since Random.Next() is a statistical PRNG, it is easy for an attacker to guess the strings it generates. Although the underlying design of the receipt system is also faulty, it would be more secure if it used a random number generator that did not produce predictable receipt identifiers, such as a cryptographic PRNG.

Insecure randomness errors occur when a function that can produce predictable values is used as a source of randomness in a security-sensitive context.

Computers are deterministic machines, and as such are unable to produce true randomness. Pseudorandom Number Generators (PRNGs) approximate randomness algorithmically, starting with a seed from which subsequent values are calculated.

There are two types of PRNGs: statistical and cryptographic. Statistical PRNGs provide useful statistical properties, but their output is highly predictable and form an easy to reproduce numeric stream that is unsuitable for use in cases where security depends on generated values being unpredictable. Cryptographic PRNGs address this problem by generating output that is more difficult to predict. For a value to be cryptographically secure, it must be impossible or highly improbable for an attacker to distinguish between the generated random value and a truly random value. In general, if a PRNG algorithm is not advertised as being cryptographically secure, it is probably a statistical PRNG and should not be used in security-sensitive contexts, where its use can lead to serious vulnerabilities such as easy-to-guess temporary passwords, predictable cryptographic keys, session hijacking, and DNS spoofing.

Example 1: The following code uses a statistical PRNG to create a URL for a receipt that remains active for some period of time after a purchase.

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;
}

This code uses the lrand48() function to generate "unique" identifiers for the receipt pages it generates. Since lrand48() is a statistical PRNG, it is easy for an attacker to guess the strings it generates. Although the underlying design of the receipt system is also faulty, it would be more secure if it used a random number generator that did not produce predictable receipt identifiers.

Insecure randomness errors occur when a function that can produce predictable values is used as a source of randomness in a security-sensitive context.


Computers are deterministic machines, and as such are unable to produce true randomness. Pseudorandom Number Generators (PRNGs) approximate randomness algorithmically, starting with a seed from which subsequent values are calculated.

There are two types of PRNGs: statistical and cryptographic. Statistical PRNGs provide useful statistical properties, but their output is highly predictable and form an easy to reproduce numeric stream that is unsuitable for use in cases where security depends on generated values being unpredictable. Cryptographic PRNGs address this problem by generating output that is more difficult to predict. For a value to be cryptographically secure, it must be impossible or highly improbable for an attacker to distinguish between the generated random value and a truly random value. In general, if a PRNG algorithm is not advertised as being cryptographically secure, then it is probably a statistical PRNG and should not be used in security-sensitive contexts, where its use can lead to serious vulnerabilities such as easy-to-guess temporary passwords, predictable cryptographic keys, session hijacking, and DNS spoofing.

Example 1: The following code uses a statistical PRNG to create a URL for a receipt that remains active for some period of time after a purchase.

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

This code uses the Rand() function to generate "unique" identifiers for the receipt pages it generates. Since Rand() is a statistical PRNG, it is easy for an attacker to guess the strings it generates. Although the underlying design of the receipt system is also faulty, it would be more secure if it used a random number generator that did not produce predictable receipt identifiers, such as a cryptographic PRNG.

Insecure randomness errors occur when a function that can produce predictable values is used as a source of randomness in a security-sensitive context.

Computers are deterministic machines, and as such are unable to produce true randomness. Pseudorandom Number Generators (PRNGs) approximate randomness algorithmically, starting with a seed from which subsequent values are calculated.

There are two types of PRNGs: statistical and cryptographic. Statistical PRNGs provide useful statistical properties. However, their output is highly predictable and form an easy to reproduce numeric stream that is unsuitable for use in cases where security depends on generated values being unpredictable. Cryptographic PRNGs address this problem by generating output that is more difficult to predict. For a value to be cryptographically secure, it must be impossible or highly improbable for an attacker to distinguish between the generated random value and a truly random value. In general, if a PRNG algorithm is not advertised as being cryptographically secure, then it is probably a statistical PRNG and should not be used in security-sensitive contexts, where its use can lead to serious vulnerabilities such as easy-to-guess temporary passwords, predictable cryptographic keys, session hijacking, and DNS spoofing.

Example 1: The following code uses a statistical PRNG to create an RSA key.

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

This code uses the rand.New() function to generate randomness for an RSA key. Since rand.New() is a statistical PRNG, it is easy for an attacker to guess the value it generates.

Insecure randomness errors occur when a function that can produce predictable values is used as a source of randomness in a security-sensitive context.

Computers are deterministic machines, and as such are unable to produce true randomness. Pseudorandom Number Generators (PRNGs) approximate randomness algorithmically, starting with a seed from which subsequent values are calculated.

There are two types of PRNGs: statistical and cryptographic. Statistical PRNGs provide useful statistical properties, but their output is highly predictable and form an easy to reproduce numeric stream that is unsuitable for use in cases where security depends on generated values being unpredictable. Cryptographic PRNGs address this problem by generating output that is more difficult to predict. For a value to be cryptographically secure, it must be impossible or highly improbable for an attacker to distinguish between the generated random value and a truly random value. In general, if a PRNG algorithm is not advertised as being cryptographically secure, then it is probably a statistical PRNG and should not be used in security-sensitive contexts, where its use can lead to serious vulnerabilities such as easy-to-guess temporary passwords, predictable cryptographic keys, session hijacking, and DNS spoofing.

Example 1: The following code uses a statistical PRNG to create a URL for a receipt that remains active for some period of time after a purchase.

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

This code uses the Math.random() function to generate "unique" identifiers for the receipt pages it generates. Since Math.random() is a statistical PRNG, it is easy for an attacker to guess the strings it generates. Although the underlying design of the receipt system is also faulty, it would be more secure if it used a random number generator that did not produce predictable receipt identifiers, such as a cryptographic PRNG.

Insecure randomness errors occur when a function that can produce predictable values is used as a source of randomness in a security-sensitive context.

Computers are deterministic machines, and as such are unable to produce true randomness. Pseudorandom Number Generators (PRNGs) approximate randomness algorithmically, starting with a seed from which subsequent values are calculated.

There are two types of PRNGs: statistical and cryptographic. Statistical PRNGs provide useful statistical properties, but their output is highly predictable and form an easy to reproduce numeric stream that is unsuitable for use in cases where security depends on generated values being unpredictable. Cryptographic PRNGs address this problem by generating output that is more difficult to predict. For a value to be cryptographically secure, it must be impossible or highly improbable for an attacker to distinguish between the generated random value and a truly random value. In general, if a PRNG algorithm is not advertised as being cryptographically secure, then it is probably a statistical PRNG and should not be used in security-sensitive contexts, where its use can lead to serious vulnerabilities such as easy-to-guess temporary passwords, predictable cryptographic keys, session hijacking, and DNS spoofing.

Example 1: The following code uses a statistical PRNG to create a URL for a receipt that remains active for some period of time after a purchase.

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

This code uses the Random.nextInt() function to generate "unique" identifiers for the receipt pages it generates. Since Random.nextInt() is a statistical PRNG, it is easy for an attacker to guess the strings it generates. Although the underlying design of the receipt system is also faulty, it would be more secure if it used a random number generator that did not produce predictable receipt identifiers, such as a cryptographic PRNG.

Insecure randomness errors occur when a function that can produce predictable values is used as a source of randomness in a security-sensitive context.

Computers are deterministic machines, and as such are unable to produce true randomness. Pseudorandom Number Generators (PRNGs) approximate randomness algorithmically, starting with a seed from which subsequent values are calculated.

There are two types of PRNGs: statistical and cryptographic. Statistical PRNGs provide useful statistical properties, but their output is highly predictable and form an easy to reproduce numeric stream that is unsuitable for use in cases where security depends on generated values being unpredictable. Cryptographic PRNGs address this problem by generating output that is more difficult to predict. For a value to be cryptographically secure, it must be impossible or highly improbable for an attacker to distinguish between the generated random value and a truly random value. In general, if a PRNG algorithm is not advertised as being cryptographically secure, then it is probably a statistical PRNG and should not be used in security-sensitive contexts, where its use can lead to serious vulnerabilities such as easy-to-guess temporary passwords, predictable cryptographic keys, session hijacking, and DNS spoofing.

Example 1: The following code uses a statistical PRNG to create a URL for a receipt that remains active for some period of time after a purchase.

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

This code uses the rand() function to generate "unique" identifiers for the receipt pages it generates. Since rand() is a statistical PRNG, it is easy for an attacker to guess the strings it generates. Although the underlying design of the receipt system is also faulty, it would be more secure if it used a random number generator that did not produce predictable receipt identifiers, such as a cryptographic PRNG.

Insecure randomness errors occur when a function that can produce predictable values is used as a source of randomness in a security-sensitive context.

Computers are deterministic machines, and as such are unable to produce true randomness. Pseudorandom Number Generators (PRNGs) approximate randomness algorithmically, starting with a seed from which subsequent values are calculated.

There are two types of PRNGs: statistical and cryptographic. Statistical PRNGs provide useful statistical properties, but their output is highly predictable and form an easy to reproduce numeric stream that is unsuitable for use in cases where security depends on generated values being unpredictable. Cryptographic PRNGs address this problem by generating output that is more difficult to predict. For a value to be cryptographically secure, it must be impossible or highly improbable for an attacker to distinguish between the generated random value and a truly random value. In general, if a PRNG algorithm is not advertised as being cryptographically secure, it is probably a statistical PRNG and should not be used in security-sensitive contexts, where its use can lead to serious vulnerabilities such as easy-to-guess temporary passwords, predictable cryptographic keys, session hijacking, and DNS spoofing.

Example: The following code uses a statistical PRNG to create a URL for a receipt that remains active for some period of time after a purchase.

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

This code uses the DBMS_RANDOM.SEED() function to generate "unique" identifiers for the receipt pages it generates. Since DBMS_RANDOM.SEED() is a statistical PRNG, it is easy for an attacker to guess the strings it generates. Although the underlying design of the receipt system is also faulty, it would be more secure if it used a random number generator that did not produce predictable receipt identifiers.

Insecure randomness errors occur when a function that can produce predictable values is used as a source of randomness in a security-sensitive context.

Computers are deterministic machines, and as such are unable to produce true randomness. Pseudorandom Number Generators (PRNGs) approximate randomness algorithmically, starting with a seed from which subsequent values are calculated.

There are two types of PRNGs: statistical and cryptographic. Statistical PRNGs provide useful statistical properties, but their output is highly predictable and form an easy to reproduce numeric stream that is unsuitable for use in cases where security depends on generated values being unpredictable. Cryptographic PRNGs address this problem by generating output that is more difficult to predict. For a value to be cryptographically secure, it must be impossible or highly improbable for an attacker to distinguish between the generated random value and a truly random value. In general, if a PRNG algorithm is not advertised as being cryptographically secure, then it is probably a statistical PRNG and should not be used in security-sensitive contexts, where its use can lead to serious vulnerabilities such as easy-to-guess temporary passwords, predictable cryptographic keys, session hijacking, and DNS spoofing.

Example 1: The following code uses a statistical PRNG to create a URL for a receipt that remains active for some period of time after a purchase.

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

This code uses the rand() function to generate "unique" identifiers for the receipt pages it generates. Since rand() is a statistical PRNG, it is easy for an attacker to guess the strings it generates. Although the underlying design of the receipt system is also faulty, it would be more secure if it used a random number generator that did not produce predictable receipt identifiers, such as a cryptographic PRNG.

Insecure randomness errors occur when a function that can produce predictable values is used as a source of randomness in a security-sensitive context.

Computers are deterministic machines, and as such are unable to produce true randomness. Pseudorandom Number Generators (PRNGs) approximate randomness algorithmically, starting with a seed from which subsequent values are calculated.

There are two types of PRNGs: statistical and cryptographic. Statistical PRNGs provide useful statistical properties, but their output is highly predictable and form an easy to reproduce numeric stream that is unsuitable for use in cases where security depends on generated values being unpredictable. Cryptographic PRNGs address this problem by generating output that is more difficult to predict. For a value to be cryptographically secure, it must be impossible or highly improbable for an attacker to distinguish between the generated random value and a truly random value. In general, if a PRNG algorithm is not advertised as being cryptographically secure, then it is probably a statistical PRNG and should not be used in security-sensitive contexts, where its use can lead to serious vulnerabilities such as easy-to-guess temporary passwords, predictable cryptographic keys, session hijacking, and DNS spoofing.

Example 1: The following code uses a statistical PRNG to create a URL for a receipt that remains active for some period of time after a purchase.

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

This code uses the Kernel.rand() function to generate "unique" identifiers for the receipt pages it generates. Since Kernel.rand() is a statistical PRNG, it is easy for an attacker to guess the strings it generates.

Insecure randomness errors occur when a function that can produce predictable values is used as a source of randomness in a security-sensitive context.

Computers are deterministic machines, and as such are unable to produce true randomness. Pseudorandom Number Generators (PRNGs) approximate randomness algorithmically, starting with a seed from which subsequent values are calculated.

There are two types of PRNGs: statistical and cryptographic. Statistical PRNGs provide useful statistical properties, but their output is highly predictable and form an easy to reproduce numeric stream that is unsuitable for use in cases where security depends on generated values being unpredictable. Cryptographic PRNGs address this problem by generating output that is more difficult to predict. For a value to be cryptographically secure, it must be impossible or highly improbable for an attacker to distinguish between the generated random value and a truly random value. In general, if a PRNG algorithm is not advertised as being cryptographically secure, then it is probably a statistical PRNG and should not be used in security-sensitive contexts, where its use can lead to serious vulnerabilities such as easy-to-guess temporary passwords, predictable cryptographic keys, session hijacking, and DNS spoofing.

Example 1: The following code uses a statistical PRNG to create a URL for a receipt that remains active for some period of time after a purchase.

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

This code uses the Random.nextInt() function to generate "unique" identifiers for the receipt pages it generates. Since Random.nextInt() is a statistical PRNG, it is easy for an attacker to guess the strings it generates. Although the underlying design of the receipt system is also faulty, it would be more secure if it used a random number generator that did not produce predictable receipt identifiers, such as a cryptographic PRNG.

Insecure randomness errors occur when a function that can produce predictable values is used as a source of randomness in a security-sensitive context.

Computers are deterministic machines, and as such are unable to produce true randomness. Pseudorandom Number Generators (PRNGs) approximate randomness algorithmically, starting with a seed from which subsequent values are calculated.

There are two types of PRNGs: statistical and cryptographic. Statistical PRNGs provide useful statistical properties, but their output is highly predictable and form an easy to reproduce numeric stream that is unsuitable for use in cases where security depends on generated values being unpredictable. Cryptographic PRNGs address this problem by generating output that is more difficult to predict. For a value to be cryptographically secure, it must be impossible or highly improbable for an attacker to distinguish between the generated random value and a truly random value. In general, if a PRNG algorithm is not advertised as being cryptographically secure, it is probably a statistical PRNG and should not be used in security-sensitive contexts, where its use can lead to serious vulnerabilities such as easy-to-guess temporary passwords, predictable cryptographic keys, session hijacking, and DNS spoofing.

Example 1: The following code uses a statistical PRNG to create a random value that is used as a reset password token.

    sqlite3_randomness(10, &reset_token)

Insecure randomness errors occur when a function that can produce predictable values is used as a source of randomness in a security-sensitive context.

Computers are deterministic machines, and as such are unable to produce true randomness. Pseudorandom Number Generators (PRNGs) approximate randomness algorithmically, starting with a seed from which subsequent values are calculated.

There are two types of PRNGs: statistical and cryptographic. Statistical PRNGs provide useful statistical properties, but their output is highly predictable and form an easy to reproduce numeric stream that is unsuitable for use in cases where security depends on generated values being unpredictable. Cryptographic PRNGs address this problem by generating output that is more difficult to predict. For a value to be cryptographically secure, it must be impossible or highly improbable for an attacker to distinguish between the generated random value and a truly random value. In general, if a PRNG algorithm is not advertised as being cryptographically secure, then it is probably a statistical PRNG and should not be used in security-sensitive contexts, where its use can lead to serious vulnerabilities such as easy-to-guess temporary passwords, predictable cryptographic keys, session hijacking, and DNS spoofing.

Example 1: The following code uses a statistical PRNG to create a URL for a receipt that remains active for some period of time after a purchase.

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

This code uses the Rnd() function to generate "unique" identifiers for the receipt pages it generates. Since Rnd() is a statistical PRNG, it is easy for an attacker to guess the strings it generates. Although the underlying design of the receipt system is also faulty, it would be more secure if it used a random number generator that did not produce predictable receipt identifiers, such as a cryptographic PRNG.

Functions that generate random or pseudorandom values, which are passed a seed, should not be called with a constant argument. If a pseudorandom number generator (such as CL_ABAP_RANDOM class or its variants) is seeded with a specific constant value, the values returned by GET_NEXT, INT and similar methods which return or assign values are predictable for an attacker that can collect a number of PRNG outputs.

Example 1: In the following excerpt, the values produced by the object random_gen2 are predictable from the object 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.

In this example, pseudorandom number generators: random_gen1 and random_gen2 were identically seeded, so var1 = var2

Functions that generate random or pseudorandom values, which are passed a seed, should not be called with a constant argument. If a pseudorandom number generator (such as rand()) is seeded with a specific value (using a function like srand(unsigned int)), the values returned by rand() and similar methods which return or assign values are predictable for an attacker that can collect a number of PRNG outputs.

Example 1: The values produced by the pseudorandom number generator are predictable in the first two blocks because both start with the same seed.

        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);

In this example the results for randomNum1 and randomNum2 were identically seeded, so each call to rand() after the call which seeds the pseudorandom number generator srand(2223333), will result in the same outputs in the same calling order. For example, the output might resemble the following:

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

These results are far from random.

Functions that generate random or pseudorandom values, which are passed a seed, should not be called with a constant argument. If a pseudorandom number generator (PRNG) is seeded with a specific value (using functions such as math.Rand.New(Source)), the values returned by math.Rand.Int() and similar methods which return or assign values are predictable for an attacker that can collect a number of PRNG outputs.

Example 1: The values produced by the pseudorandom number generator are predictable in the first two blocks because both start with the same seed.

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

In this example, the PRNGs were identically seeded, so each call to nextInt() after the call that seeded the pseudorandom number generator (randomGen.Seed(12345)), results in the same outputs and in the same order.

Functions that generate random or pseudorandom values, which are passed a seed, should not be called with a constant argument. If a pseudorandom number generator (such as Random) is seeded with a specific value (using function such as Random(Int)), the values returned by Random.nextInt() and similar methods which return or assign values are predictable for an attacker that can collect a number of PRNG outputs.

Example 1: The values produced by the Random object randomGen2 are predictable from the Random object randomGen1.

        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)

In this example, pseudorandom number generators: randomGen1 and randomGen2 were identically seeded, so randomInt1 == randomInt2, and corresponding values of arrays byteArray1 and byteArray2 are equal.

Functions that generate pseudorandom values, which are passed a seed, should not be called with a constant integer argument. If a pseudorandom number generator is seeded with a specific value, the values returned are predictable.

Example 1: The values produced by the pseudorandom number generator are predictable in the first two blocks because both start with the same seed.

...
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)
...

In this example the PRNGs were identically seeded, so each call to randint() after the call that seeded the pseudorandom number generator (random.seed(123456)), will result in the same outputs in the same output in the same order. For example, the output might resemble the following:

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

These results are far from random.

Functions that generate random or pseudorandom values, which are passed a seed, should not be called with a constant argument. If a pseudorandom number generator (such as Random) is seeded with a specific value (using a function like Random.setSeed()), the values returned by Random.nextInt() and similar methods which return or assign values are predictable for an attacker that can collect a number of PRNG outputs.

Example 1: The values produced by the Random object randomGen2 are predictable from the Random object randomGen1.

        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)

In this example, pseudorandom number generators: randomGen1 and randomGen2 were identically seeded, so randomInt1 == randomInt2, and corresponding values of arrays bytes1[] and bytes2[] are equal.

Class CL_ABAP_RANDOM (or its variants) should not be initialized with a tainted argument. Doing so allows an attacker to control the value used to seed the pseudorandom number generator, and therefore predict the sequence of values produced by calls to methods including but not limited to: GET_NEXT, INT, FLOAT, PACKED.

Functions that generate random or pseudorandom values (such as rand()), which are passed a seed (such as srand()); should not be called with a tainted argument. Doing so allows an attacker to control the value used to seed the pseudorandom number generator, and therefore predict the sequence of values (usually integers) produced by calls to the pseudorandom number generator.

Functions that generate pseudorandom values, such as ed25519.NewKeyFromSeed(), should not be called with a tainted argument. Doing so allows an attacker to control the value used to seed the pseudorandom number generator, and then can predict the sequence of values produced by calls to the pseudorandom number generator.

Random.setSeed() should not be called with a tainted integer argument. Doing so allows an attacker to control the value used to seed the pseudorandom number generator, and therefore predict the sequence of values (usually integers) produced by calls to Random.nextInt(), Random.nextLong(), Random.nextDouble(), or returned by Random.nextBoolean(), or set in Random.nextBytes(ByteArray).

Functions that generate pseudorandom values (such as random.randint()); should not be called with a tainted argument. Doing so allows an attacker to control the value used to seed the pseudorandom number generator, and hence be able to predict the sequence of values (usually integers) produced by calls to the pseudorandom number generator.

Random.setSeed() should not be called with a tainted integer argument. Doing so allows an attacker to control the value used to seed the pseudorandom number generator, and therefore predict the sequence of values (usually integers) produced by calls to Random.nextInt(), Random.nextShort(), Random.nextLong(), or returned by Random.nextBoolean(), or set in Random.nextBytes(byte[]).

The lack of a proper source of entropy for use by the random or pseudorandom number generator may lead to denial of service or generation of predictable sequences of numbers. If the random or pseudorandom number generator uses the source of entropy that runs out, the program may pause or even crash, leading to denial of service. Alternatively, the random or pseudorandom number generator may produce predictable numbers. A weak source of random numbers may lead to vulnerabilities such as easy-to-guess temporary passwords, predictable cryptographic keys, session hijacking, and DNS spoofing.

Example 1: The following code uses the system clock as the entropy source:

...
import time
import random

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

Since system clock generates predictable values, it is not a good source of entropy. Same goes for other non-hardware-based sources of randomness, including system/input/output buffers, user/system/hardware/network serial numbers or addresses, as well as user input.

The public key infrastructure (PKI) is based on trusted Ceritficate Authorities (CAs), however the increasing number of compromised Certificate Authorities means their root certificates can no longer be trusted and therefore no certificates that are signed by this CA can either. Attackers in possession of these compromised certificates will be able to intercept all the SSL/TLS traffic trusting these CAs.

Certificate Authorities signatures are necessary for general purpose network communication tools such as browsers that connect to arbitrary network endpoints and have no advance knowledge of which CAs sign the SSL/TLS certificates for those endpoints. Mobile applications that connect to a limited number of backend servers can benefit from knowing a shortlist of trusted CAs that these servers may use in signing their certificates and "pin" these certificates/public keys in the applications so that trust is reduced to the certificates the application expects.

Example 1: The following example establishes an SSL/TLS connection using the default pre-loaded system CAs.

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

Since the underlying SSLSocketFactory used by the URLConnection has not been changed, it will use the default one that will trust all the CAs present in the Android default keystore.

The public key infrastructure (PKI) is based on trusted Ceritficate Authorities (CAs), however the increasing number of compromised Certificate Authorities means their root certificates can no longer be trusted and therefore no certificates that are signed by this CA can either. Attackers in possession of these compromised certificates will be able to intercept all the SSL/TLS traffic trusting these CAs.

Certificate Authorities signatures are necessary for general purpose network communication tools such as browsers that connect to arbitrary network endpoints and have no advance knowledge of which CAs sign the SSL/TLS certificates for those endpoints. Mobile applications that connect to a limited number of backend servers can benefit from knowing a shortlist of trusted CAs that these servers may use in signing their certificates and "pin" these certificates/public keys in the applications so that trust is reduced to the certificates the application expects.

Example 1: The following example establishes an SSL/TLS connection using the default pre-loaded system CAs.

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];

Since there is no NSURLConnectionDelegate methods defined to handle certificate verification, it will use the system ones that will trust all the CAs present in the iOS default keystore.

The public key infrastructure (PKI) is based on trusted Ceritficate Authorities (CAs), however the increasing number of compromised Certificate Authorities means their root certificates can no longer be trusted and therefore no certificates that are signed by this CA can either. Attackers in possession of these compromised certificates will be able to intercept all the SSL/TLS traffic trusting these CAs.

Certificate Authorities signatures are necessary for general purpose network communication tools such as browsers that connect to arbitrary network endpoints and have no advance knowledge of which CAs sign the SSL/TLS certificates for those endpoints. Mobile applications that connect to a limited number of backend servers can benefit from knowing a shortlist of trusted CAs that these servers may use in signing their certificates and "pin" these certificates/public keys in the applications so that trust is reduced to the certificates the application expects.

Example 1: The following example establishes an SSL/TLS connection using the default pre-loaded system CAs.

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)!;

Since there is no NSURLConnectionDelegate methods defined to handle certificate verification, it will use the system ones that will trust all the CAs present in the iOS default keystore.