MIME sniffing, is the practice of inspecting the content of a byte stream to attempt to deduce the file format of the data within it.

If MIME sniffing is not explicitly disabled, some browsers can be manipulated into interpreting data in a way that is not intended, allowing for cross-site scripting attacks.

For each page that could contain user controllable content, you should use the HTTP Header X-Content-Type-Options: nosniff.

MIME sniffing is the practice of inspecting the content of a byte stream to attempt to deduce the file format of the data within it.

If MIME sniffing is not explicitly disabled, some browsers can be manipulated into interpreting data in a way that is not intended, allowing for cross-site scripting attacks.
When writing a web application, use the HTTP header X-Content-Type-Options: nosniff for each page that could contain user-controllable content.
When writing a client application, you should not use the MIME sniffing algorithm to determine the server's response Content-Type.

Example: The following code uses net.http.DetectContentType() to determine the response Content-Type:

    ...
    resp, err := http.Get("http://example.com/")
    if err != nil {
        // handle error
    }
    defer resp.Body.Close()
    body, err := ioutil.ReadAll(resp.Body)

    content_type := DetectContentType(body)
    ...

MIME sniffing is the practice of inspecting the content of a byte stream to attempt to deduce the file format of the data within it.

If MIME sniffing is not explicitly disabled, some browsers can be manipulated into interpreting data in a way that is not intended, allowing for cross-site scripting attacks.

For each page that could contain user-controllable content, you should use the HTTP header X-Content-Type-Options: nosniff.

MIME sniffing is the practice of inspecting the content of a byte stream to attempt to deduce the file format of the data within it.

If MIME sniffing is not explicitly disabled, some browsers can be manipulated into interpreting data in a way that is not intended, allowing for cross-site scripting attacks.

For each page that could contain user-controllable content, you should use the HTTP header X-Content-Type-Options: nosniff.

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: 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[]).

Windows provides a large number of utility functions that manipulate buffers containing filenames. In most cases, the result is returned in a buffer that is passed in as input. (Usually the filename is modified in place.) Most functions require the buffer to be at least MAX_PATH bytes in length, but you should check the documentation for each function individually. If the buffer is not large enough to store the result of the manipulation, a buffer overflow can occur.

Example:

char *createOutputDirectory(char *name) {
	char outputDirectoryName[128];
	if (getCurrentDirectory(128, outputDirectoryName) == 0) {
		return null;
	}
	if (!PathAppend(outputDirectoryName, "output")) {
		return null;
	}
	if (!PathAppend(outputDirectoryName, name)) {
		return null;
	}
	if (SHCreateDirectoryEx(NULL, outputDirectoryName, NULL)
        != ERROR_SUCCESS) {
		return null;
	}
	return StrDup(outputDirectoryName);
}

In this example the function creates a directory named "output\<name>" in the current directory and returns a heap-allocated copy of its name. For most values of the current directory and the name parameter, this function will work properly. However, if the name parameter is particularly long, then the second call to PathAppend() could overflow the outputDirectoryName buffer, which is smaller than MAX_PATH bytes.

Certain identified functions are known to blindly follow symbolic links. When this happens, your application will open, read, or write data to the file that the symbolic link points to instead of the representation of the symbolic link. An attacker may fool the application into writing to alternate or critical system files or provide compromised data to the application.

Example 1: The following code utilizes functions which follow symbolic links:

...
	struct stat output;
	int ret = stat(aFilePath, &output);
	// error handling omitted for this example
	struct timespec accessTime = output.st_atime;
...

The umask() man page begins with the false statement:

"umask sets the umask to mask & 0777"

Although this behavior would better align with the usage of chmod(), where the user provided argument specifies the bits to enable on the specified file, the behavior of umask() is in fact opposite: umask() sets the umask to ~mask & 0777.

The umask() man page goes on to describe the correct usage of umask():

"The umask is used to set initial file permissions on a newly-created file. Specifically, permissions in the umask are turned off from the mode argument (so, for example, the common umask default value of 022 results in new files being created with permissions 0666 & ~022 = 0644 = rw-r--r-- in the usual case where the mode is specified as 0666)."

Many APIs will minimize the risk of data loss by completely writing to a temporary file, then copy the complete file to the target destination. Make sure the identified method does not work on files or paths in public or temporary directories as an attacker may replace the temporary file the instant before it is written to the targeted file. This allows the attacker to control the content of files used by the application in public directories.

Example 1: The following code writes the active transactionId to a temporary file in the application Documents directory using a vulnerable method:

...
//get the documents directory:
let documentsPath = NSSearchPathForDirectoriesInDomains(.DocumentDirectory, .UserDomainMask, true)[0]
//make a file name to write the data to using the documents directory:
let fileName = NSString(format:"%@/tmp_activeTrans.txt", documentsPath)
// write data to the file
let transactionId = "TransactionId=12341234"
transactionId.writeToFile(fileName, atomically:true)
...

Just about every serious attack on a software system begins with the violation of a programmer's assumptions. After the attack, the programmer's assumptions seem flimsy and poorly founded, but before an attack many programmers would defend their assumptions well past the end of their lunch break.

Two dubious assumptions that are easy to spot in code are "this method call can never fail" and "it doesn't matter if this call fails". When a programmer ignores an exception, they implicitly state that they are operating under one of these assumptions.

Example 1: The following code excerpt ignores a rarely-thrown exception from doExchange().

try {
    doExchange();
}
catch (RareException e) {
    // this can never happen
}

If a RareException were to ever be thrown, the program would continue to execute as though nothing unusual had occurred. The program records no evidence indicating the special situation, potentially frustrating any later attempt to explain the program's behavior.

Just about every serious attack on a software system begins with the violation of a programmer's assumptions. After the attack, the programmer's assumptions seem flimsy and poorly founded, but before an attack many programmers would defend their assumptions well past the end of their lunch break.

Two dubious assumptions that are easy to spot in code are "this method call can never fail" and "it doesn't matter if this call fails". When programmers ignore exceptions, they implicitly state that they are operating under one of these assumptions.

Example 1: The following code excerpt ignores a rarely-thrown exception from DoExchange().

try {
  DoExchange();
}
catch (RareException e) {
  // this can never happen
}

If a RareException were to ever be thrown, the program would continue to execute as though nothing unusual had occurred. The program records no evidence indicating the special situation, potentially frustrating any later attempt to explain the program's behavior.

Just about every serious attack on a software system begins with the violation of a programmer's assumptions. After the attack, the programmer's assumptions seem flimsy and poorly founded, but before an attack many programmers would defend their assumptions well past the end of their lunch break.

Two dubious assumptions that are easy to spot in code are "this method call can never fail" and "it doesn't matter if this call fails". When a programmer ignores an exception, they implicitly state that they are operating under one of these assumptions.

Example 1: The following code excerpt ignores a rarely-thrown exception from doExchange().

try {
  doExchange();
}
catch (exception $e) {
  // this can never happen
}

If a RareException were to ever be thrown, the program would continue to execute as though nothing unusual had occurred. The program records no evidence indicating the special situation, potentially frustrating any later attempt to explain the program's behavior.

Just about every serious attack on a software system begins with the violation of a programmer's assumptions. After the attack, the programmer's assumptions seem flimsy and poorly founded, but before an attack many programmers would defend their assumptions well past the end of their lunch break.

Two dubious assumptions that are easy to spot in code are "this method call can never fail" and "it doesn't matter if this call fails". When a programmer ignores an exception, they implicitly state that they are operating under one of these assumptions.

Example 1: The following code excerpt ignores a rarely-thrown exception from open().

try:
    f = open('myfile.txt')
    s = f.readline()
    i = int(s.strip())
except:
   # This will never happen
   pass

If a RareException were to ever be thrown, the program would continue to execute as though nothing unusual had occurred. The program records no evidence indicating the special situation, potentially frustrating any later attempt to explain the program's behavior.

Different operating systems use different characters as file separators. For example, Microsoft Windows systems use "\", while UNIX systems use "/". When applications have to run on different platforms, the use of hardcoded file separators can lead to incorrect execution of application logic and potentially a denial of service.

Example 1: The following code uses a hardcoded file separator to open a file:

...
var file:File = new File(directoryName + "\\" + fileName);
...

Different operating systems use different characters as file separators. For example, Microsoft Windows systems use "\", while UNIX systems use "/". When applications have to run on different platforms, the use of hardcoded file separators can lead to incorrect execution of application logic and potentially a denial of service.

Example 1: The following code uses a hardcoded file separator to open a file:

...
FileStream f = File.Create(directoryName + "\\" + fileName);
...

Different operating systems use different characters as file separators. For example, Microsoft Windows systems use "\", while UNIX systems use "/". When applications have to run on different platforms, the use of hardcoded file separators can lead to incorrect execution of application logic and potentially a denial of service.

Example 1: The following code uses a hardcoded file separator to open a file:

...
os.open(directoryName + "\\" + fileName);
...

It is never a good idea to use an empty salt. Not only does using an empty salt make it significantly easier to determine the hashed values, it also makes fixing the problem extremely difficult. After the code is in production, the salt cannot be easily changed. If attackers figure out that values are hashed with an empty salt, they can compute "rainbow tables" for the application and more easily determine the hashed values.

Example 1: The following code uses an empty salt:

...
CCKeyDerivationPBKDF(kCCPBKDF2,
                     password,
                     passwordLen,
                     "",
                     0,
                     kCCPRFHmacAlgSHA256,
                     100000,
                     derivedKey,
                     derivedKeyLen);
...

This code will run successfully, but anyone who has access to it will have access to the (empty) salt. After the program ships, there is likely no way to change the empty salt. An employee with access to this information can use it to break into the system.

It is never a good idea to use an empty salt. Not only does using an empty salt make it significantly easier to determine the hashed values, it also makes fixing the problem extremely difficult. After the code is in production, the salt cannot be easily changed. If attackers figure out that values are hashed with an empty salt, they can compute "rainbow tables" for the application and more easily determine the hashed values.

Example 1: The following code uses an empty salt:

...
$hash = hash_pbkdf2('sha256', $password, '', 100000);
...

This code will run successfully, but anyone who has access to it will have access to the (empty) salt. After the program ships, there is likely no way to change the empty salt. An employee with access to this information can use it to break into the system.

It is never a good idea to use an empty salt. Not only does using an empty salt make it significantly easier to determine the hashed values, it also makes fixing the problem extremely difficult. After the code is in production, the salt cannot be easily changed. If attackers figure out that values are hashed with an empty salt, they can compute "rainbow tables" for the application and more easily determine the hashed values.

Example 1: The following code uses an empty salt:

from hashlib import pbkdf2_hmac
...
dk = pbkdf2_hmac('sha256', password, '', 100000)
...

This code will run successfully, but anyone who has access to it will have access to the (empty) salt. After the program ships, there is likely no way to change the empty salt. An employee with access to this information can use it to break into the system.

It is never a good idea to use an empty salt. Not only does using an empty salt make it significantly easier to determine the hashed values, it also makes fixing the problem extremely difficult. After the code is in production, the salt cannot be easily changed. If attackers figure out that values are hashed with an empty salt, they can compute "rainbow tables" for the application and more easily determine the hashed values.

Example 1: The following code uses an empty salt:

...
dk = OpenSSL::PKCS5.pbkdf2_hmac(password, "", 100000, 256, digest)
...

This code will run successfully, but anyone who has access to it will have access to the (empty) salt. After the program ships, there is likely no way to change the empty salt. An employee with access to this information can use it to break into the system.

It is never a good idea to use an empty salt. Not only does using an empty salt make it significantly easier to determine the hashed values, it also makes fixing the problem extremely difficult. After the code is in production, the salt cannot be easily changed. If attackers figure out that values are hashed with an empty salt, they can compute "rainbow tables" for the application and more easily determine the hashed values.

Example 1: The following code uses an empty salt:

...
let ITERATION = UInt32(100000)
...
CCKeyDerivationPBKDF(CCPBKDFAlgorithm(kCCPBKDF2),
password,
passwordLength,
"",
0,
CCPseudoRandomAlgorithm(kCCPRFHmacAlgSHA256),
ITERATION,
derivedKey,
derivedKeyLength)

This code will run successfully, but anyone who has access to it will have access to the (empty) salt. After the program ships, there is likely no way to change the empty salt. An employee with access to this information can use it to break into the system.