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

The values of attributes for Oracle ADF Faces components can ordinarily be set only on the server. However, a number of components allow the developer to define a list of attributes that can be set on the client. unsecure attribute of these components can specify such a list.

Currently, the only attribute that can appear inside the unsecure attribute is disabled, and it allows the client to define which components are enabled and which ones are not. It is never a good idea to let the client control the values of attributes that should only be settable on the server.

Example 1: The following code demonstrates an inputText component that collects password information from the user and uses the unsecure attribute.

...
    <af:inputText id="pwdBox"
                  label="#{resources.PWD}"
                  value=""#{userBean.password}
                  unsecure="disabled"
                  secret="true"
                  required="true"/>
...

Cookies are strictly a HTTP mechanism as per RFC 2109. There should be no reasonable expectation for them to work for protocols other than HTTP, including file://. It is not clear what their behavior should be, and what rules of security compartmentalization should apply. For example, should HTML files downloaded to local disk from the Internet share the same cookies as any HTML code installed locally?

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

By default, ASP.NET servers store the HttpSessionState object, its attributes and any objects they reference in memory. This model limits active session state to what can be accommodated by the system memory of a single machine. In order to expand capacity beyond these limitations, servers are frequently configured to persistent session state information, which both expands capacity and permits the replication across multiple machines to improve overall performance. In order to persist its session state, the server must serialize the HttpSessionState object, which requires that all objects stored in it be serializable.

In order for the session to be serialized correctly, all objects the application stores as session attributes must declare the [Serializable] attribute. Additionally, if the object requires custom serialization methods, it must also implement the ISerializable interface.

Example 1: The following class adds itself to the session, but since it is not serializable, the session cannot be serialized correctly.

public class DataGlob {
   String GlobName;
   String GlobValue;

   public void AddToSession(HttpSessionState session) {
     session["glob"] = this;
   }
}

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.

ASP.NET Core middleware that is not added to the middleware pipeline in the correct order will not function as intended, leaving an application open to a variety of security issues.

Example 1: The UseCookiePolicy() method adds the cookie policy middleware to the middleware pipeline, allowing for customized cookie policies. When specified in the wrong order as shown, any cookie policy stated by the programmer will be ignored.

...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    ...
}

app.UseCookiePolicy();
...

ASP.NET Core middleware that is not added to the middleware pipeline in the correct order will not function as intended, leaving an application open to a variety of security issues.

Example 1: The UseHttpsRedirection() method adds HTTPS redirection middleware to the middleware pipeline, which allows for redirection of insecure HTTP requests to a secure HTTPS request. When specified in the wrong order as shown, no meaningful HTTPS redirection will occur before processing the request through the middleware listed before the redirect. This will allow for HTTP requests to be processed by the application before being redirected to the secure HTTPS connection.

...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    ...
}

app.UseHttpsRedirection();
...

ASP.NET Core middleware that is not added to the middleware pipeline in the correct order will not function as intended, leaving an application open to a variety of security issues.

Example 1: The UseHttpLogging() method adds HTTP logging middleware to the middleware pipeline which allows middleware components to log. When specified in the wrong order as shown, no middleware added to the pipeline before the call to UseHttpLogging() will log.

...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    ...
}

app.UseHttpLogging();
...

Example 2: The UseWC3Logging() method adds W3C logging middleware to the middleware pipeline which allows middleware components to log. When specified in the wrong order as shown, no middleware added to the pipeline before the call to UseWC3Logging() will log.

...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    ...
}

app.UseWC3Logging();
...

ASP.NET MVC controller actions that modify data by writing, updating, or deleting could benefit from being restricted to accept one of the following HTTP verbs: Post, Put, Patch, or Delete. This increases the difficulty of cross-site request forgery because accidental clicking of links will not cause the action to execute.

The following controller action by default accepts any verb and may be susceptible to cross-site request forgery:

public ActionResult UpdateWidget(Model model)
{
  // ... controller logic
}

Using a model class that has properties that are required (as marked with the [Required] attribute) and properties that are optional (as not marked with the [Required] attribute) can lead to problems if an attacker communicates a request that contains more data than is expected.

The ASP.NET MVC framework will try to bind request parameters to model properties.

Having mixed requiredness without explicitly communicating which parameters are to be model-bound may indicate that there are model properties for internal use but can be controlled by attacker.

The following code defines a possible model class that has properties that have [Required] and properties that do not have [Required]:

public class MyModel
{
    [Required]
    public String UserName { get; set; }

    [Required]
    public String Password { get; set; }

    public Boolean IsAdmin { get; set; }
}

If any optional parameters can change the behavior of an application, then an attacker may be able to actually change that behavior by communicating an optional parameter in a request.

Using a model class that has non-nullable properties that are required (as marked with the [Required] attribute) can lead to problems if an attacker communicates a request that contains less data than is expected.

The ASP.NET MVC framework will try to bind request parameters to model properties.

If a model has a required non-nullable parameter and an attacker does not communicate that required parameter in a request -- that is, the attacker uses an under-posting attack -- then the property will have the default value (usually zero) which will satisfy the [Required] validation attribute. This may produce unexpected application behavior.

The following code defines a possible model class that has a required enum, which is non-nullable:

public enum ArgumentOptions
{
    OptionA = 1,
    OptionB = 2
}

public class Model
{
    [Required]
    public String Argument { get; set; }

    [Required]
    public ArgumentOptions Rounding { get; set; }
}

If a model class has required property and is the type of an optional member of a parent model class, it may be susceptible to under-posting attacks if an attacker communicates a request that contains less data than is expected.

The ASP.NET MVC framework will try to bind request parameters to model properties, including submodels.

If a submodel is optional -- that is, the parent model has a property without the [Required] attribute -- and if an attacker does not communicate that submodel, then the parent property will have a null value and the required fields of the child model will not be asserted by model validation. This is one form of an under-posting attack.

Consider the following the model class definitions:

public class ChildModel
{
    public ChildModel()
    {
    }

    [Required]
    public String RequiredProperty { get; set; }
}

public class ParentModel
{
    public ParentModel()
    {
    }

    public ChildModel Child { get; set; }
}

If an attacker does not communicate a value for the ParentModel.Child property, then the ChildModel.RequiredProperty property will have a [Required] which is not asserted. This may produce unexpected and undesirable results.

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

According to Apple's policy, the application should always explain to users why their fingerprints are required. Failing to do so may confuse the user or even get your app rejected from the AppStore.

Example 1: The following code uses Touch ID to authenticate the user but fails to provide a localized reason that explains why the authentication is required:

    [context evaluatePolicy:LAPolicyDeviceOwnerAuthenticationWithBiometrics localizedReason:nil
        reply:^(BOOL success, NSError *error) {
            if (success) {
                NSLog(@"Auth was OK");
            } 
    }];

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