Never hardcode credentials, including usernames, passwords, API keys, API secrets, and API Tokens. Not only are hardcoded credentials visible to all of the project developers, they are extremely difficult to update. After the code is in production, the credentials cannot be changed without patching the software. If the credentials are compromised, the organization must choose between security and system availability.

Never hardcode credentials, including usernames, passwords, API keys, API secrets, and API Tokens. Not only are hardcoded credentials visible to all of the project developers, they are extremely difficult to update. After the code is in production, the credentials cannot be changed without patching the software. If the credentials are compromised, the organization must choose between security and system availability.

It is never a good idea to hardcode a username. Not only does hardcoding a username allow all of the project's developers to view the username, it also makes fixing the problem extremely difficult. After the code is in production, the username cannot be changed without patching the software. If the account protected by the username is compromised, the owners of the system must choose between security and availability.
Example 1: The following code uses a hardcoded username to connect to a database:

...
<cfquery name = "GetSSNs" dataSource = "users"
 username = "scott" password = "tiger">
SELECT   SSN
FROM     Users
</cfquery>
...

This code will run successfully, but anyone who has access to it will have access to the username. After the program ships, there is likely no way to change the database user "scott" with a password of "tiger" unless the program is patched. An employee with access to this information can use it to break into the system.

File permission manipulation errors occur when any of the following conditions are met:

1. An attacker might specify a path used in an operation that modifies permissions on the file system.

2. An attacker might specify the permissions assigned by an operation on the file system.

Example 1: The following code uses input from system environment variables to set file permissions. If attackers can alter the system environment variables, they might use the program to gain access to files manipulated by the program. If the program is also vulnerable to path manipulation, an attacker might use this vulnerability to access arbitrary files on system.

    permissions := strconv.Atoi(os.Getenv("filePermissions"));
    fMode := os.FileMode(permissions)
    os.chmod(filePath, fMode);
    ...

File permission manipulation errors occur when any of the following conditions are met:

1. An attacker is able to specify a path used in an operation that modifies permissions on the file system.

2. An attacker is able to specify the permissions assigned by an operation on the file system.

Example 1: The following code is designed to set proper file permissions for users uploading Web pages through FTP. It uses input from an HTTP request to mark a file as viewable for external users.

	$rName = $_GET['publicReport'];
	chmod("/home/". authenticateUser . "/public_html/" . rName,"0755");
...

However, if an attacker provides a malicious value for publicReport, such as "../../localuser/public_html/.htpasswd", the application will make the specified file readable to the attacker.

Example 2: The following code uses input from a configuration file to set the default permission mask. If attackers can alter the configuration file, they can use the program to gain access to files manipulated by the program. If the program is also vulnerable to path manipulation, an attacker may use this vulnerability to access arbitrary files on system.

...
$mask = $CONFIG_TXT['perms'];
chmod($filename,$mask);
...

File permission manipulation errors occur when any of the following conditions are met:

1. An attacker is able to specify a path used in an operation that modifies permissions on the file system.

2. An attacker is able to specify the permissions assigned by an operation on the file system.

Example 1: The following code uses input from system environment variables to set file permissions. If attackers can alter the system environment variables, they may use the program to gain access to files manipulated by the program. If the program is also vulnerable to path manipulation, an attacker may use this vulnerability to access arbitrary files on system.

    permissions = os.getenv("filePermissions");
    os.chmod(filePath, permissions);
    ...

File permission manipulation errors occur when any of the following conditions are met:

1. An attacker is able to specify a path used in an operation that modifies permissions on the file system.

2. An attacker is able to specify the permissions assigned by an operation on the file system.

Example 1: The following code is designed to set proper file permissions for users uploading Web pages through FTP. It uses input from an HTTP request to mark a file as viewable for external users.

...
  rName = req['publicReport']
  File.chmod("/home/#{authenticatedUser}/public_html/#{rName}", "0755")
...

However, if an attacker provides a malicious value for publicReport, such as "../../localuser/public_html/.htpasswd", the application will make the specified file readable to the attacker.

Example 2: The following code uses input from a configuration file to set the default permission mask. If attackers can alter the configuration file, they may use the program to gain access to files manipulated by the program. If the program is also vulnerable to path manipulation, an attacker may use this vulnerability to access arbitrary files on system.

...
mask = config_params['perms']
File.chmod(filename, mask)
...

An application's authentication and authorization mechanisms can be bypassed with HTTP verb tampering when:
1) It uses a security control that lists HTTP verbs.
2) The security control fails to block verbs that are not listed.
3) The application updates its state based on GET requests or other arbitrary HTTP verbs.



The following configuration is vulnerable to HTTP Verb Tampering:

    <authorization>
        <allow verbs="GET,POST" users="admin"/>
        <deny verbs="GET,POST"users="*" />
    </authorization>

By default, the .NET framework allows all HTTP verbs, so even though this configuration denies GETs and POSTs to all users, it does not prevent HEAD requests. It might be possible for an attacker to exercise administrative functionality by substituting GET or POST requests with HEAD requests. In other words, this code satisfies the previously mentioned conditions 1 and 2. All that remains for HEAD requests to exercise administrative functionality is for the application to carry out commands based on requests that use verbs other than POST.

At its core, this vulnerability is the result of an attempt to create a deny list--a policy that specifies what users are not allowed to do. Deny lists rarely achieve their intended effect.

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.