Modern frameworks allow developers to automatically bind HTTP request parameters from both request query and body into model objects for ease of development and increase of productivity. If the binder is not correctly configured to control which HTTP request parameters are bound to which model attributes, an attacker may be able to abuse the model binding process and set any other attributes that should not be exposed to user control. This binding is possible even if the model attributes do not appear in the web forms or API contracts.

Example 1: The following ASP.NET MVC controller method (Register) is accessed from a web form that asks the users to register an account by providing their name and password:

public ActionResult Register(RegisterModel model)
{
    if (ModelState.IsValid)
    {
        try
        {
            return RedirectToAction("Index", "Home");
        }
        catch (MembershipCreateUserException e)
        {
            ModelState.AddModelError("", "");
        }
    }
    return View(model);
}

Where RegisterModel class is defined as:

public class RegisterModel
{
    [BindRequired]
    [Display(Name = "User name")]
    public string UserName { get; set; }

    [BindRequired]
    [DataType(DataType.Password)]
    [Display(Name = "Password")]
    public string Password { get; set; }

    [DataType(DataType.Password)]
    [Display(Name = "Confirm password")]
    public string ConfirmPassword { get; set; }

    public Details Details { get; set; }

    public RegisterModel()
    {
        Details = new Details();
    }
}

and Details class is defined as:

public class Details
{
    public bool IsAdmin { get; set; }
    ...
}

Given the scenario in Example 1, an attacker may be able to explore the application and discover that there is a Details attribute in the RegisterModel model. If this is the case, the attacker may then attempt to overwrite the current values assigned to their attributes.
If an attacker can find out these internal attributes, and the framework binder is not correctly configured in order to disallow binding of these attributes, then the attacker would be able to register an administrator account by sending the following request:

name=John&password=****&details.is_admin=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 function call can never fail" and "it doesn't matter if this function call fails". When a programmer ignores the return value from a function, they implicitly state that they are operating under one of these assumptions.
Example 1: The following code does not check to see if the string returned by the Item property is null before calling the member function Equals(), potentially causing a null dereference.

string itemName = request.Item(ITEM_NAME);
	if (itemName.Equals(IMPORTANT_ITEM)) {
		...
	}
	...

The traditional defense of this coding error is:

"I know the requested value will always exist because.... If it does not exist, the program cannot perform the desired behavior so it doesn't matter whether I handle the error or simply allow the program to die dereferencing a null value."

But attackers are skilled at finding unexpected paths through programs, particularly when exceptions are involved.

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 function call can never fail" and "it doesn't matter if this function call fails". When a programmer ignores the return value from a function, they implicitly state that they are operating under one of these assumptions.
Example 1: The following code does not check to see if memory allocation succeeded before attempting to use the pointer returned by malloc().

    buf = (char*) malloc(req_size);
    strncpy(buf, xfer, req_size);

The traditional defense of this coding error is:

"If my program runs out of memory, it will fail. It doesn't matter whether I handle the error or simply allow the program to die with a segmentation fault when it tries to dereference the null-pointer."

This argument ignores three important considerations:

- Depending upon the type and size of the application, it may be possible to free memory that is being used elsewhere so that execution can continue.

- It is impossible for the program to perform a graceful exit if required. If the program performs an atomic operation, it can leave the system in an inconsistent state.

- The programmer has lost the opportunity to record diagnostic information. Did the call to malloc() fail because req_size was too large or because there were too many requests being handled at the same time? Or was it caused by a memory leak that has built up over time? Without handling the error, there is no way to know.

The application fails to validate the type of data received from a web form. It is a good practice to validate that the received data satisfy the requirements defined for the expected data.


Example 1: The following code defines a form but fails to validate the data against the expected requirements:

  def form = Form(
    mapping(
      "name" -> text,
      "age" -> number
    )(UserData.apply)(UserData.unapply)
  )

Most successful attacks begin with a violation of the programmer's assumptions. By accepting an XML document without validating it against a DTD or XML schema, the programmer leaves a door open for attackers to provide unexpected, unreasonable, or malicious input. It is not possible for an XML parser to validate all aspects of a document's content; a parser cannot understand the complete semantics of the data. However, a parser can do a complete and thorough job of checking the document's structure and therefore guarantee to the code that processes the document that the content is well-formed.

Most successful attacks begin with a violation of the programmer's assumptions. By accepting an XML document without validating it against a DTD or XML schema, the programmer leaves a door open for attackers to provide unexpected, unreasonable, or malicious input. It is not possible for an XML parser to validate all aspects of a document's content; a parser cannot understand the complete semantics of the data. However, a parser can do a complete and thorough job of checking the document's structure and therefore guarantee to the code that processes the document that the content is well-formed.

NoSQL injection vulnerabilities in DynamoDB can occur when:

1. Data enters a program from an untrusted source.



2. The data is used to dynamically construct a DynamoDB query.

Example 1: The following code dynamically constructs and executes a DynamoDB query that searches for a user given their email address or username, along with their password.

    ...
        // "type" parameter expected to be either: "Email" or "Username"
        string type = request["type"];
        string value = request["value"];
        string password = request["password"];
        
        var ddb = new AmazonDynamoDBClient();
    
        var attrValues = new Dictionary<string,AttributeValue>();
        attrValues[":value"] = new AttributeValue(value);
        attrValues[":password"] = new AttributeValue(password);
    
        var scanRequest = new ScanRequest();
        scanRequest.FilterExpression = type + " = :value AND Password = :password";
        scanRequest.TableName = "users";
        scanRequest.ExpressionAttributeValues = attrValues;
    
        var scanResponse = await ddb.ScanAsync(scanRequest);
    ...
    

The query intends to execute the following code:

Email = :value AND Password = :password

or

Username = :value AND Password = :password

However, because the query is constructed dynamically by concatenating a constant base query string and a user input string, the query only behaves correctly if type only contains any of the expected values. If an attacker provides a type value such as :value = :value OR :value, then the query becomes the following:

:value = :value OR :value = :value AND Password = :password

The addition of the :value = :value condition causes the where clause to always evaluate to true, so the query returns all entries stored in the users collection, regardless of the email owner.

NoSQL injection in MongoDB errors occur when:

1. Data enters a program from an untrusted source.



2. The data is used to dynamically construct a MongoDB query.

Example 1: The following code dynamically constructs and executes a MongoDB query that searches for an email with a specific ID.

...
    String userName = User.Identity.Name;
    String emailId = request["emailId"];
    var coll = mongoClient.GetDatabase("MyDB").GetCollection<BsonDocument>("emails");
    var docs = coll.Find(new BsonDocument("$where", "this.name == '" + name + "'")).ToList();
...

The query intends to execute the following code:

    this.owner == "<userName>" && this.emailId == "<emailId>"

However, because the query is constructed dynamically by concatenating a constant query string and user input, the query only behaves correctly if emailId does not contain a single-quote character. If an attacker with the user name wiley enters the string "123' || '4' != '5" for emailId, then the query becomes the following:

    this.owner == 'wiley' && this.emailId == '123' || '4' != '5'

The addition of the || '4' != '5' condition causes the where clause to always evaluate to true, so the query returns all entries stored in the emails collection, regardless of the email owner.

NoSQL injection in MongoDB errors occur when:

1. Data enters a program from an untrusted source.



2. The data is used to dynamically construct a MongoDB query.

Example 1: The following code dynamically constructs and executes a MongoDB query that searches for an email with a specific ID.

...
    userName = req.field('userName')
    emailId = req.field('emaiId')
    results = db.emails.find({"$where", "this.owner == \"" + userName + "\" && this.emailId == \"" + emailId + "\""});
...

The query intends to execute the following code:

    this.owner == "<userName>" && this.emailId == "<emailId>"

However, because the query is constructed dynamically by concatenating a constant base query string and a user input string, the query only behaves correctly if emailId does not contain a double-quote character. If an attacker with the user name wiley enters the string 123" || "4" != "5 for emailId, then the query becomes the following:

    this.owner == "wiley" && this.emailId == "123" || "4" != "5"

The addition of the || "4" != "5" condition causes the where clause to always evaluate to true, so the query returns all entries stored in the emails collection, regardless of the email owner.

Null-pointer errors are usually the result of one or more programmer assumptions being violated.

Most null-pointer issues result in general software reliability problems, but if an attacker can intentionally trigger a null-pointer dereference, the attacker may be able to use the resulting exception to bypass security logic or to cause the application to reveal debugging information that will be valuable in planning subsequent attacks.

Example 1: In the following code, the programmer assumes that the system always has a property named "cmd" defined. If an attacker can control the program's environment so that "cmd" is not defined, the program throws a null-pointer exception when it attempts to call the Trim() method.

string cmd = null;
...
cmd = Environment.GetEnvironmentVariable("cmd");
cmd = cmd.Trim();

Null-pointer exceptions usually occur when one or more of the programmer's assumptions is violated. There are at least three flavors of this problem: check-after-dereference, dereference-after-check, and dereference-after-store. A check-after-dereference error occurs when a program dereferences a pointer that can be null before checking if the pointer is null. Dereference-after-check errors occur when a program makes an explicit check for null, but proceeds to dereference the pointer when it is known to be null. Errors of this type are often the result of a typo or programmer oversight. A dereference-after-store error occurs when a program explicitly sets a pointer to null and dereferences it later. This error is often the result of a programmer initializing a variable to null when it is declared.

Most null-pointer issues result in general software reliability problems, but if an attacker can intentionally trigger a null-pointer dereference, the attacker may be able to use the resulting exception to bypass security logic in order to mount a denial of service attack, or to cause the application to reveal debugging information that will be valuable in planning subsequent attacks.

Example 1: In the following code, the programmer assumes that the variable ptr is not NULL. That assumption is made explicit when the programmer dereferences the pointer. This assumption is later contradicted when the programmer checks ptr against NULL. If ptr can be NULL when it is checked in the if statement then it can also be NULL when it dereferenced and may cause a segmentation fault.

ptr->field = val;
...
if (ptr != NULL) {
	...
}

Example 2: In the following code, the programmer confirms that the variable ptr is NULL and subsequently dereferences it erroneously. If ptr is NULL when it is checked in the if statement, then a null dereference will occur, thereby causing a segmentation fault.

if (ptr == null) {
        ptr->field = val;
        ...
}

Example 3: In the following code, the programmer forgets that the string '\0' is actually 0 or NULL, thereby dereferencing a null-pointer and causing a segmentation fault.

if (ptr == '\0') {
        *ptr = val;
        ...
}

Example 4: In the following code, the programmer explicitly sets the variable ptr to NULL. Later, the programmer dereferences ptr before checking the object for a null value.

*ptr = NULL;
...
ptr->field = val;
...
}

In general as programming languages evolve, methods occasionally become obsolete due to:

- Advances in the language
- Improved understanding of how operations should perform effectively and
securely
- Changes in the conventions that govern certain operations

Statements that are removed from a language are usually replaced by newer counterparts that perform the same task in somewhat different and hopefully better way.

In particular, SAP ABAP evolved to include ABAP Objects - the object oriented extension of ABAP and to operate in a Unicode compatible environment. As a result, stricter syntax is enforced in classes or in Unicode programs. Obsolete constructs are still available only for reasons of compatibility with older releases and they can only be used outside of classes or in non-Unicode programs. There are replacement constructions for all obsolete language elements, which improve the efficiency and readability of programs. Many implicit, ambiguous type/length/memory specifications in the obsolete syntax are required to be specified in a more precise and explicit way in the newer syntax. It is recommended to adopt the newer syntax to make programs easier to understand, more robust and easier to maintain.


Not all functions are deprecated or replaced because they pose a security risk. However, the presence of an obsolete function often indicates that the surrounding code has been neglected and may be in a state of disrepair. Software security has not been a priority, or even a consideration, for very long. If the program uses deprecated or obsolete functions, it raises the probability that there are security problems lurking nearby.

As programming languages evolve, functions occasionally become obsolete due to:

- Advances in the language
- Improved understanding of how operations should perform effectively and
securely
- Changes in the conventions that govern certain operations


Functions that are removed from a language are usually replaced by newer counterparts that perform the same task in some different and hopefully better way.
Example 1: The following code constructs a new SqlClientPermission object, which regulates how users are allowed to connect to a database. In this example, the program passes false as the second parameter to the constructor, which controls whether users are allowed to connect with blank passwords. Passing false to this parameter indicates that blank passwords should not be allowed.

...
SCP = new SqlClientPermission(pstate, false);
...

However, because the PermissionState object passed as the first parameter supersedes any value passed to the second parameter, the constructor allows blank passwords for database connections, which contradicts the second argument. To disallow blank passwords, the program should pass PermissionState.None to the first parameter of the constructor. Because of the ambiguity in its functionality, the two-parameter version of the SqlClientPermission constructor has been deprecated in favor of the single parameter version, which conveys the same degree of information without the risk of misinterpretation.

Not all functions are deprecated or replaced because they pose a security risk. However, the presence of an obsolete function often indicates that the surrounding code has been neglected and may be in a state of disrepair. Software security has not been a priority, or even a consideration, for very long. If the program uses deprecated or obsolete functions, it raises the probability that there are security problems lurking nearby.

As programming languages evolve, functions occasionally become obsolete due to:

- Advances in the language.
- Improved understanding of how operations should be performed effectively and securely.
- Changes in the conventions that govern certain operations.

Functions that are removed are usually replaced by newer counterparts that perform the same task in some different and hopefully improved way.
Example 1: The following code uses the deprecated function getpw() to verify that a plain text password matches a user's encrypted password. If the password is valid, the function sets result to 1; otherwise it is set to 0.

	...
	getpw(uid, pwdline);
	for (i=0; i<3; i++){
	cryptpw=strtok(pwdline, ":");
		pwdline=0;
	}
result = strcmp(crypt(plainpw,cryptpw), cryptpw) == 0;
	...

Although the code often behaves correctly, using the getpw() function can be problematic from a security standpoint, because it can overflow the buffer passed to its second parameter. Because of this vulnerability, getpw() has been supplanted by getpwuid(), which performs the same lookup as getpw() but returns a pointer to a statically-allocated structure to mitigate the risk.

Not all functions are deprecated or replaced because they pose a security risk. However, the presence of an obsolete function often indicates that the surrounding code has been neglected and may be in a state of disrepair. Software security has not been a priority, or even a consideration, for very long. If the program uses deprecated or obsolete functions, it raises the probability that there are security problems lurking nearby.

As programming languages evolve, methods occasionally become obsolete due to:

- Advances in the language
- Improved understanding of how operations should perform effectively and
securely
- Changes in the conventions that govern certain operations

Methods that are removed from a language are usually replaced by newer counterparts that perform the same task in some different and hopefully better way.


Not all functions are deprecated or replaced because they pose a security risk. However, the presence of an obsolete function often indicates that the surrounding code has been neglected and may be in a state of disrepair. Software security has not been a priority, or even a consideration, for very long. If the program uses deprecated or obsolete functions, it raises the probability that there are security problems lurking nearby.

As programming languages evolve, methods occasionally become obsolete due to:

- Advances in the language
- Improved understanding of how operations should perform effectively and
securely
- Changes in the conventions that govern certain operations.

Methods that are removed from a language are usually replaced by newer counterparts that perform the same task in some different and hopefully better way.
Example 1: The following code uses the Digest::HMAC stdlib, which use of is explicitly discouraged in the documentation due to accidental involvement within a release.

require 'digest/hmac'

hmac = Digest::HMAC.new("foo", Digest::RMD160)
...
hmac.update(buf)
...

In this example the Digest::HMAC class was deprecated immediately upon involvement due to accidental inclusion within a release. Due to possibility of this not working as expected because of experimental and not properly tested code, use of this is highly discouraged, especially considering the relation HMACs have in relation to cryptographic functionality.

Not all functions are deprecated or replaced because they pose a security risk. However, the presence of an obsolete function often indicates that the surrounding code has been neglected and may be in a state of disrepair. Software security has not been a priority, or even a consideration, for very long. If the program uses deprecated or obsolete functions, it raises the probability that there are security problems lurking nearby.

Due to the fast-paced nature of smart contracts, functions and operators may become deprecated with newer compiler versions and using them may lead to low quality code, unintended side effects and/or compilation errors.

Example 1: The following code obtains the hash of the current block using block.blockhash(), which has been deprecated since version 0.5.0 of the Solidity compiler.

bytes32 blockhash = block.blockhash(0);

Many DNS servers are susceptible to spoofing attacks, so you should assume that your software will someday run in an environment with a compromised DNS server. If attackers are allowed to make DNS updates (sometimes called DNS cache poisoning), they can route your network traffic through their machines or make it appear as if their IP addresses are part of your domain. Do not base the security of your system on DNS names.
Example 1: The following code sample uses a DNS lookup in order to decide whether or not an inbound request is from a trusted host. If an attacker can poison the DNS cache, they can gain trusted status.

 IPAddress hostIPAddress = IPAddress.Parse(RemoteIpAddress);
 IPHostEntry hostInfo = Dns.GetHostByAddress(hostIPAddress);
 if (hostInfo.HostName.EndsWith("trustme.com")) {
   trusted = true;
 }

IP addresses are more reliable than DNS names, but they can also be spoofed. Attackers may easily forge the source IP address of the packets they send, but response packets will return to the forged IP address. To see the response packets, the attacker has to sniff the traffic between the victim machine and the forged IP address. In order to accomplish the required sniffing, attackers typically attempt to locate themselves on the same subnet as the victim machine. Attackers may be able to circumvent this requirement by using source routing, but source routing is disabled across much of the Internet today. In summary, IP address verification can be a useful part of an authentication scheme, but it should not be the single factor required for authentication.

The getlogin() function is supposed to return a string containing the name of the user currently logged in at the terminal, but an attacker may cause getlogin() to return the name of any user logged in to the machine. Do not rely on the name returned by getlogin() when making security decisions.
Example 1: The following code relies on getlogin() to determine whether or not a user is trusted. It is easily subverted.

 pwd = getpwnam(getlogin());
 if (isTrustedGroup(pwd->pw_gid)) {
 allow();
 } else {
 deny();
 }

Regardless of the language a program is written in, the most devastating attacks often involve remote code execution, whereby an attacker succeeds in executing malicious code in the program's context. The GetChars method in Decoder & Encoding classes and the GetBytes method in Encoder & Encoding classes in the .NET Framework internally performs pointer arithmetic on the char & byte arrays to convert range of character into range of bytes and vice versa.
When performing pointer arithmetic operations, developers often override the preceding methods in a bad fashion and introduce vulnerabilities such as arbitrary code execution, application logic abuse and denial of service.

When character sets are mismatched between the operating system and applications running on the operating system, unsupported characters passed to default API methods can be best-fit mapped to dangerous characters.

Example 1: In Objective-C, the following example converts an NSString object containing a UTF-8 character to ASCII data then back:

...
unichar ellipsis = 0x2026;
NSString *myString = [NSString stringWithFormat:@"My Test String%C", ellipsis];
NSData *asciiData = [myString dataUsingEncoding:NSASCIIStringEncoding allowLossyConversion:YES];
NSString *asciiString = [[NSString alloc] initWithData:asciiData encoding:NSASCIIStringEncoding];
NSLog(@"Original: %@ (length %d)", myString, [myString length]);
NSLog(@"Best-fit-mapped: %@ (length %d)", asciiString, [asciiString length]);
// output:
// Original: My Test String... (length 15)
// Best-fit-mapped: My Test String... (length 17)
...

If you look at the output carefully, the "..." character was translated to three consecutive periods. If you had sized your output buffer based on the input buffer your application could be vulnerable to buffer overflow. Other characters can get mapped from one character to two. The Greek "fi" character will get mapped to an "f" followed by an "i". By front loading the buffer with these characters an attacker gains complete control over the number of characters used to overflow the buffer.

When character sets are mismatched between the operating system and applications running on the operating system, unsupported characters passed to default API methods can be best-fit mapped to dangerous characters.

Example 1: In Swift, the following example converts an NSString object containing a UTF-8 character to ASCII data then back:

...
let ellipsis = 0x2026;
let myString = NSString(format:"My Test String %C", ellipsis)
let asciiData = myString.dataUsingEncoding(NSASCIIStringEncoding, allowLossyConversion:true)
let asciiString = NSString(data:asciiData!, encoding:NSASCIIStringEncoding)
NSLog("Original: %@ (length %d)", myString, myString.length)
NSLog("Best-fit-mapped: %@ (length %d)", asciiString!, asciiString!.length)

// output:
// Original: My Test String ... (length 16)
// Best-fit-mapped: My Test String ... (length 18)
...

If you look at the output carefully, the "..." character was translated to three consecutive periods. If you had sized your output buffer based on the input buffer your application could be vulnerable to buffer overflow. Other characters can get mapped from one character to two. The Greek "fi" character will get mapped to an "f" followed by an "i". By front loading the buffer with these characters an attacker gains complete control over the number of characters used to overflow the buffer.

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 1:

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