Unused parameters represent data that is processed by the application code but is not made available to the users through any of the request parameters. The purpose of such parameters could be to aid in debugging tasks, enable privileged functionality known only to the programmers or administrators of the web site or act as a backdoor. If discovered by an attacker, such parameters could lead to unauthorized access to privileged functionality or inject arbitrary code into the application. Programmers sometimes leave behind functionality in product code that was only meant to exist for debugging purposes and incorrectly assume they can successfully hide privileged functionality by not exposing it through publicly accessible interfaces.

Presence of unused parameters could expose an application to certain risks:
- It can indicate dead code in an application which is not exposed to legitimate application users. However, a malicious user may get access to functionality in dead code by supplying brute force parameter name/value pairs (e.g. debug=true). If such code is accessing sensitive resources such as databases and file IO, it can threaten overall security of the application.
- It can indicate a backdoor into the application planted by a developer with malicious intent which can be used later to gain unlawful access to application data or perform serious attacks against the application.

Double free errors occur when free() is called more than once with the same memory address as an argument.



Calling free() twice on the same value can lead to a buffer overflow. When a program calls free() twice with the same argument, the program's memory management data structures become corrupted. This corruption can cause the program to crash or, in some circumstances, cause two later calls to malloc() to return the same pointer. If malloc() returns the same value twice and the program later gives the attacker control over the data that is written into this doubly-allocated memory, the program becomes vulnerable to a buffer overflow attack.

Example 1: The following code shows a simple example of a double free vulnerability.

	char* ptr = (char*)malloc (SIZE);
	...
	if (abrt) {
	  free(ptr);
	}
	...
	free(ptr);

Double free vulnerabilities have two common (and sometimes overlapping) causes:

- Error conditions and other exceptional circumstances.

- Confusion over which part of the program is responsible for freeing the memory.

Although some double free vulnerabilities are not much more complicated than the previous example, most are spread out across hundreds of lines of code or even different files. Programmers seem particularly susceptible to freeing global variables more than once.

Source code that contains Unicode bidirectional override control characters can be a sign of an insider threat attack. Such an attack can be leveraged through the supply chain for programming languages such as C, C++, C#, Go, Java, JavaScript, Python, and Rust. Several variant attacks are already published by Nicholas Boucher and Ross Anderson, including the following: Early Returns, Commenting-Out, and Stretched Strings.
Example 1: The following code exhibits a control character, present in a C source code file, which leads to an Early Return attack:

#include <stdio.h>

int main() {
	/* Nothing to see here; newline RLI /*/ return 0 ;
	printf("Do we get here?\n");
	return 0;
}

The Right-to-Left Isolate (RLI) Unicode bidirectional control character, in Example 1, causes the code to be viewed as the following:

#include <stdio.h>

int main() {
	/* Nothing to see here; newline; return 0 /*/
	printf("Do we get here?\n");
	return 0;
}

Of particular note is that a developer who performs a code review, in a vulnerable editor/viewer, would not visibly see what a vulnerable compiler will process. Specifically, the early return statement that modifies the program flow.

This library is considered experimental and should not be used in production environments unless you know what you are doing.

Buffer overflow is probably the best known form of software security vulnerability. Most software developers know what a buffer overflow vulnerability is, but buffer overflow attacks against both legacy and newly-developed applications are still quite common. Part of the problem is due to the wide variety of ways buffer overflows can occur, and part is due to the error-prone techniques often used to prevent them.

In a classic buffer overflow exploit, the attacker sends data to a program, which it stores in an undersized stack buffer. The result is that information on the call stack is overwritten, including the function's return pointer. The data sets the value of the return pointer so that when the function returns, it transfers control to malicious code contained in the attacker's data.

Although this type of stack buffer overflow is still common on some platforms and in some development communities, there are a variety of other types of buffer overflow, including heap buffer overflows and off-by-one errors among others. There are a number of excellent books that provide detailed information on how buffer overflow attacks work, including Building Secure Software [1], Writing Secure Code [2], and The Shellcoder's Handbook [3].

At the code level, buffer overflow vulnerabilities usually involve the violation of a programmer's assumptions. Many memory manipulation functions in C and C++ do not perform bounds checking and can easily exceed the allocated bounds of the buffers they operate upon. Even bounded functions, such as strncpy(), can cause vulnerabilities when used incorrectly. The combination of memory manipulation and mistaken assumptions about the size or makeup of a piece of data is the root cause of most buffer overflows.

In this case, an improperly constructed format string causes the program to access values outside the bounds of allocated memory.

Example: The following reads arbitrary values from the stack because the number of format specifiers does not align with the number of arguments passed to the function.

void wrongNumberArgs(char *s, float f, int d) {
   char buf[1024];
   sprintf(buf, "Wrong number of %.512s");
}

Buffer overflow is probably the best known form of software security vulnerability. Most software developers know what a buffer overflow vulnerability is, but buffer overflow attacks against both legacy and newly-developed applications are still quite common. Part of the problem is due to the wide variety of ways buffer overflows can occur, and part is due to the error-prone techniques often used to prevent them.

In a classic buffer overflow exploit, the attacker sends data to a program, which it stores in an undersized stack buffer. The result is that information on the call stack is overwritten, including the function's return pointer. The data sets the value of the return pointer so that when the function returns, it transfers control to malicious code contained in the attacker's data.

Although this type of stack buffer overflow is still common on some platforms and in some development communities, there are a variety of other types of buffer overflow, including heap buffer overflows and off-by-one errors among others. There are a number of excellent books that provide detailed information on how buffer overflow attacks work, including Building Secure Software [1], Writing Secure Code [2], and The Shellcoder's Handbook [3].

At the code level, buffer overflow vulnerabilities usually involve the violation of a programmer's assumptions. Many memory manipulation functions in C and C++ do not perform bounds checking and can easily exceed the allocated bounds of the buffers they operate upon. Even bounded functions, such as strncpy(), can cause vulnerabilities when used incorrectly. The combination of memory manipulation and mistaken assumptions about the size or makeup of a piece of data is the root cause of most buffer overflows.

In this case, an improperly constructed format string causes the program to improperly convert data values or to access values outside the bounds of allocated memory.

Example: The following code incorrectly converts f from a float using a %d format specifier.

void ArgTypeMismatch(float f, int d, char *s, wchar *ws) {
   char buf[1024];
   sprintf(buf, "Wrong type of %d", f);
   ...
}

An internal Intent uses a custom action as defined by an internal component. Implicit intents can facilitate the calling of intents from any given external component without knowledge of the specific component. Combining the two allows for an application to access intents specified for a specific internal use from outside of the desired application context.

The ability to process an internal Intent from an external application can enable for a wide variety of man-in-the-middle exploits ranging in severity from information leakage and denial of service to remote code execution, depending on the capacity of the internal action specified by the Intent.

Example 1: The following code uses an implicit internal Intent.

...
val imp_internal_intent_action = Intent("INTERNAL_ACTION_HERE")
startActivity(imp_internal_intent_action)
...