In .NET, you can use the BinaryFormatter class to turn an object into a binary stream that contains both the object itself and the necessary metadata to reconstruct it during deserialization.

Use of the BinaryFormatter class can lead to insecure deserialization scenarios where attackers can execute arbitrary code, abuse application logic, or trigger a denial of service condition.

Use of the BinaryFormatter type is dangerous and is not recommended for data processing, as it cannot be made secure.

Example 1: The application enables the usage of the unsafe BinaryFormatter class by setting the config property EnableUnsafeBinaryFormatterSerialization to true in the runtimeConfig.json file.

...
AppContext.SetSwitch("System.Runtime.Serialization.EnableUnsafeBinaryFormatterSerialization", true);
...

The AccessibleObject API allows the programmer to get around the access control checks provided by Java access specifiers. In particular it enables the programmer to allow a reflected object to bypass Java access controls and in turn change the value of private fields or invoke private methods, behaviors that are normally disallowed.

In a regular JSF application, values are converted and validated using converters and validators specified by the UI components. The conversion and validation itself happens when the page is submitted. A bookmarkable view in a Fusion application results in no page submission, and therefore no similar conversion or validation is performed by default.

Example 1: The following configuration file snippet shows a sample bookmarkable view that is configured to perform no conversion or validation of the paramName URL parameter.

...
    <bookmark>
        <method>#{paramHandler.handleParams}</method>
        <url-parameter>
            <name>paramName</name>
            <value>#{requestScope.paramName}</value>
        </url-parameter>
    </bookmark>
...

It is not recommended that developers build their apps using undocumented, or hidden, APIs. There are no guarantees that Google will not remove or change those APIs in the future and therefore they should be avoided therefore using such methods or fields has a high risk of breaking your app.

The code attempts to use the Camera object after the it has already been released. Any further references to the Camera object without reacquiring the resource will throw an exception, and can cause the application to crash if the exception is not caught.

Example 1: The following code uses a toggle button to toggle the camera preview on and off. After the user taps the button once, the camera preview stops and the camera resource is released. However, if she taps the button again, startPreview() is called on the previously-released Camera object.

public class ReuseCameraActivity extends Activity {
  private Camera cam;

  ...
  private class CameraButtonListener implements OnClickListener {
      public void onClick(View v) {
          if (toggle) {
              cam.stopPreview();
              cam.release();
          }
          else {
              cam.startPreview();
          }
          toggle = !toggle;
      }
  }
  ...
}

The code attempts to use the media object after the it has already been released. Any further references to that media object without reacquiring the resource will throw an exception, and can cause the application to crash if the exception is not caught.

Example 1: The following code uses a pause button to toggle the media playback. After the user taps the button once, the current song or video is paused and the camera resource is released. However, if she taps the button again, start() is called on the previously-released media resource.

public class ReuseMediaPlayerActivity extends Activity {
  private MediaPlayer mp;

  ...
  private class PauseButtonListener implements OnClickListener {
      public void onClick(View v) {
          if (paused) {
              mp.pause();
              mp.release();
          }
          else {
              mp.start();
          }
          paused = !paused;
      }
  }
  ...
}

The code attempts to use the Android SQLite database handler after the it has already been closed. Any further references to the handler without re-establishing the database connection will throw an exception, and can cause the application to crash if the exception is not caught.

Example 1: The following code might be from a program that caches user values temporarily in memory, but can call flushUpdates() to commit the changes to disk. The method properly closes the database handler after writing updates to the database. However, when flushUpdates() is called again, the database object is referenced again before reinitializing it.

public class ReuseDBActivity extends Activity {
  private myDBHelper dbHelper;
  private SQLiteDatabase db;

  @Override
  public void onCreate(Bundle state) {
      ...
      db = dbHelper.getWritableDatabase();
      ...
  }
  ...

  private void flushUpdates() {
      db.insert(cached_data);     // flush cached data
      dbHelper.close();
  }
  ...
}

Android Class Loading Hijacking vulnerabilities take two forms:

- An attacker can change the name of the directories that the program searches to load classes, thereby pointing the path to one that they have control over: the attacker explicitly controls the paths which should be searched for classes.

- An attacker can change the environment in which the class loads: the attacker implicitly controls what the path name means.

In this case, we are primarily concerned with the first scenario, the possibility that an attacker may be able to control the directories searched for classes to load. Android Class Loading Hijacking vulnerabilities of this type occur when:

1. Data enters the application from an untrusted source.



2. The data is used as or as part of a string representing a library directory to search for classes to load.



3. By executing code from the library path, the application gives the attacker a privilege or capability that the attacker would not otherwise have.

Example 1: The following code uses the user changeable userClassPath to determine the directory in which to search for classes to load.

...
  productCategory = this.getIntent().getExtras().getString("userClassPath");
  DexClassLoader dexClassLoader = new DexClassLoader(productCategory, optimizedDexOutputPath.getAbsolutePath(), null, getClassLoader());
  ...

This code allows an attacker to load a library and potentially execute arbitrary code with the elevated privilege of the app by being able to modify the result of userClassPath to point to a different path, which they control. Because the program does not validate the value read from the environment, if an attacker can control the value of userClassPath, then they can fool the application into pointing to a directory that they control and therefore load the classes that they have defined, using the same privileges as the original app.

Example 2: The following code uses the user changeable userOutput to determine the directory the optimized DEX files should be written.

...
  productCategory = this.getIntent().getExtras().getString("userOutput");
  DexClassLoader dexClassLoader = new DexClassLoader(sanitizedPath, productCategory, null, getClassLoader());
...

This code allows an attacker to specify the output directory for Optimized DEX files (ODEX). This then allows a malicious user to change the value of userOutput to a directory that they control, such as external storage. Once this is achieved, it is simply a matter of replacing the outputted ODEX file with a malicious ODEX file to have this executed with the same privileges as the original application.

Zip Path Traversal Vulnerabilities occur when a malicious actor can specify Zip file entry names in a given Zip file. When a Zip file entry name is specified maliciously, an attacker can overwrite the contents of key system files when the corresponding Zip file is expanded. Attackers might use such path traversal idioms such as ../ and / to access system files otherwise out of program scope. Android applications that target Android 14 and later can by default throw an exception when idioms such as ../ and / are detected during Zip file extraction. This security feature can be overridden or disabled entirely.

Example 1: The following code disables Zip Entry Overwrite Protection.

...
dalvik.system.ZipPathValidator.clearCallback();
...

Minification improves page load times for applications that include JavaScript files by reducing the file size. Minification refers to the process of removing unnecessary whitespace, comments, semicolons, braces, shortening the names of local variables and removing unreachable code.

Example 1: The following ASPX code includes the unminified version of Microsoft's jQuery library:

...
<script src="http://applicationserver.application.com/lib/jquery/jquery-1.4.2.js" type="text/javascript"></script>
...

Unvalidated input is one of the leading causes of vulnerabilities in ASP.NET Web API services. Unchecked input can lead to numerous vulnerabilities, including cross-site scripting, process control, access control, and SQL injection. Although ASP.NET Web API services are generally not susceptible to memory corruption attacks, if an ASP.NET Web API service calls into native code which does not perform array bounds checking, an attacker may be able to use an input validation weakness in the ASP.NET Web API service to launch a buffer overflow attack.

To prevent such attacks:
1. use validation attributes to programmatically annotate validation checks on parameters or members of model-binding object parameters to ASP.NET Web API service actions.
2. use ModelState.IsValid to check if model validation passes.

Bean property names and values need to be validated before populating any bean. Bean population functions let developers to set a bean property or a nested property. Attackers can leverage this functionality to access special bean properties such as class.classLoader that enable them to override system properties and potentially execute arbitrary code.

Example 1: The following code sets a user-controlled bean property without proper validation of the property name or value:

String prop = request.getParameter('prop');
String value = request.getParameter('value');
HashMap properties = new HashMap();
properties.put(prop, value);
BeanUtils.populate(user, properties);

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

Buffer overflow vulnerabilities typically occur in code that:

- Relies on external data to control its behavior.

- Depends upon properties of the data that are enforced outside of the immediate scope of the code.

- Is so complex that a programmer cannot accurately predict its behavior.



The following examples demonstrate all three of the scenarios.

Example 1.a: The following sample code demonstrates a simple buffer overflow that is often caused by the first scenario in which the code relies on external data to control its behavior. The code uses the gets() function to read an arbitrary amount of data into a stack buffer. Because there is no way to limit the amount of data read by this function, the safety of the code depends on the user to always enter fewer than BUFSIZE characters.

	...
	char buf[BUFSIZE];
	gets(buf);
	...

Example 1.b: This example shows how easy it is to mimic the unsafe behavior of the gets() function in C++ by using the >> operator to read input into a char[] string.

	...
	char buf[BUFSIZE];
	cin >> (buf);
	...

Example 2: The code in this example also relies on user input to control its behavior, but it adds a level of indirection with the use of the bounded memory copy function memcpy(). This function accepts a destination buffer, a source buffer, and the number of bytes to copy. The input buffer is filled by a bounded call to read(), but the user specifies the number of bytes that memcpy() copies.

	...
char buf[64], in[MAX_SIZE];
printf("Enter buffer contents:\n");
read(0, in, MAX_SIZE-1);
printf("Bytes to copy:\n");
scanf("%d", &bytes);
memcpy(buf, in, bytes);
	...

Note: This type of buffer overflow vulnerability (where a program reads data and then trusts a value from the data in subsequent memory operations on the remaining data) has turned up with some frequency in image, audio, and other file processing libraries.

Example 3: This is an example of the second scenario in which the code depends on properties of the data that are not verified locally. In this example a function named lccopy() takes a string as its argument and returns a heap-allocated copy of the string with all uppercase letters converted to lowercase. The function performs no bounds checking on its input because it expects str to always be smaller than BUFSIZE. If an attacker bypasses checks in the code that calls lccopy(), or if a change in that code makes the assumption about the size of str untrue, then lccopy() will overflow buf with the unbounded call to strcpy().

char *lccopy(const char *str) {
	char buf[BUFSIZE];
	char *p;

	strcpy(buf, str);
	for (p = buf; *p; p++) {
		if (isupper(*p)) {
			*p = tolower(*p);
		}
	}
	return strdup(buf);
}

Example 4: The following code demonstrates the third scenario in which the code is so complex its behavior cannot be easily predicted. This code is from the popular libPNG image decoder, which is used by a wide array of applications.

The code appears to safely perform bounds checking because it checks the size of the variable length, which it later uses to control the amount of data copied by png_crc_read(). However, immediately before it tests length, the code performs a check on png_ptr->mode, and if this check fails a warning is issued and processing continues. Since length is tested in an else if block, length would not be tested if the first check fails, and is used blindly in the call to png_crc_read(), potentially allowing a stack buffer overflow.

Although the code in this example is not the most complex we have seen, it demonstrates why complexity should be minimized in code that performs memory operations.

if (!(png_ptr->mode & PNG_HAVE_PLTE)) {
	/* Should be an error, but we can cope with it */
png_warning(png_ptr, "Missing PLTE before tRNS");
}
else if (length > (png_uint_32)png_ptr->num_palette) {
png_warning(png_ptr, "Incorrect tRNS chunk length");
png_crc_finish(png_ptr, length);
return;
}
...
png_crc_read(png_ptr, readbuf, (png_size_t)length);

Example 5: This example also demonstrates the third scenario in which the program's complexity exposes it to buffer overflows. In this case, the exposure is due to the ambiguous interface of one of the functions rather than the structure of the code (as was the case in the previous example).

The getUserInfo() function takes a username specified as a multibyte string and a pointer to a structure for user information, and populates the structure with information about the user. Since Windows authentication uses Unicode for usernames, the username argument is first converted from a multibyte string to a Unicode string. This function then incorrectly passes the size of unicodeUser in bytes rather than characters. The call to MultiByteToWideChar() may therefore write up to (UNLEN+1)*sizeof(WCHAR) wide characters, or
(UNLEN+1)*sizeof(WCHAR)*sizeof(WCHAR) bytes, to the unicodeUser array, which has only (UNLEN+1)*sizeof(WCHAR) bytes allocated. If the username string contains more than UNLEN characters, the call to MultiByteToWideChar() will overflow the buffer unicodeUser.

void getUserInfo(char *username, struct _USER_INFO_2 info){
WCHAR unicodeUser[UNLEN+1];
	MultiByteToWideChar(CP_ACP, 0, username, -1,
    	      			unicodeUser, sizeof(unicodeUser));
NetUserGetInfo(NULL, unicodeUser, 2, (LPBYTE *)&info);
}

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 write beyond the bounds of allocated memory.

Example 1: The following code overflows c because the double type requires more space than is allocated for c.

void formatString(double d) {
    char c;

    scanf("%d", &c)
}

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 write beyond the bounds of allocated memory.

Example 1: The following code overflows buf because, depending on the size of f, the format string specifier "%d %.1f ... " can exceed the amount of allocated memory.

void formatString(int x, float f) {
   char buf[40];
   sprintf(buf, "%d %.1f ... ", x, f);
}

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 off-by-one error is still common on some platforms and in some development communities, there are a variety of other types of buffer overflow, including stack and heap buffer overflows 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.

Example 1: The following code contains an off-by-one buffer overflow, which occurs when recv returns the maximum allowed sizeof(buf) bytes read. In this case, the subsequent dereference of buf[nbytes] will write the null byte outside the bounds of allocated memory.

void receive(int socket) {
   char buf[MAX];
   int nbytes = recv(socket, buf, sizeof(buf), 0);
   buf[nbytes] = '\0';
   ...
}

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.

Example 1: The following code attempts to prevent an off-by-one buffer overflow by checking that the untrusted value read from getInputLength() is less than the size of the destination buffer output. However, because the comparison between len and MAX is signed, if len is negative, it will be become a very large positive number when it is converted to an unsigned argument to memcpy().

void TypeConvert() {
   char input[MAX];
   char output[MAX];

   fillBuffer(input);
   int len = getInputLength();

   if (len <= MAX) {
      memcpy(output, input, len);
   }
   ...
}

The target application uses Apache Struts [1] version 1.x (pre-1.3.10) or 2.x (pre-2.3.16), which contains a remote command injection vulnerability identified as CVE-2014-0112 and CVE-2014-0114. [2, 3, 4, 5] The vulnerability results from insufficient validation performed by the ParametersInterceptor, allowing access to the getClass() method through the class parameter. This can enable an attacker to manipulate the ClassLoader and execute arbitrary Java code using crafted action parameters.

Template engines are used to render content using dynamic data. This context data is normally controlled by the user and formatted by the template to generate web pages, emails, and so on. Template engines allow powerful language expressions to be used in templates to render dynamic content, by processing the context data with code constructs such as conditionals, loops, etc. If an attacker can control the template to be rendered, they can inject expressions that expose context data and run malicious code in the browser.

Example 1: The following example shows how a template is retrieved from the URL and used to render information with AngularJS.

function MyController(function($stateParams, $interpolate){
    var ctx = { foo : 'bar' };
    var interpolated = $interpolate($stateParams.expression);
    this.rendered = interpolated(ctx);
    ...
}

In this case, $stateParams.expression will be taking potentially user-controlled data, and evaluating this as a template to be used with a specified context. This in turn may enable a malicious user to run any code they wish within the browser, retrieving information about the context it's run against, finding additional information about how the application is created, or turning this into a full blown XSS attack.

Arithmetic operations will not act in the same way on boolean values as they would on integral values, which may lead to unexpected behavior.