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?

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.

Android applications can be configured to produce debug binaries. These binaries give detailed debugging messages and should not be used in production environments. The debuggable attribute of the <application> tag defines whether compiled binaries should include debugging information.

The use of debug binaries causes an application to provide as much information about itself as possible to the user. Debug binaries are meant to be used in a development or testing environment and can pose a security risk if they are deployed to production. Attackers may leverage the additional information they gain from debugging output to mount attacks targeted on the framework, database, or other resources used by the 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;
   }
}

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.

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

Setting the certificate validation mode to None disables the entire certification validation process, which exposes the application to Man-in-the-Middle attacks. This mode should never be used in production environments.

Cookies are often used to store important information about users, such as personal information, authentication tokens and a history of their activity. If this information is stored in plain text, anyone with access to machines used to interact with the application will have access to the information stored in the cookie. Worse yet, if attackers are allowed to arbitrarily modify the data stored in cookies, they can falsify information provided to the application and potentially alter its behavior to their advantage.

In many cases, an application can validate input from cookies programmatically according to the context in which it is used, but the ASP.NET validation framework provides an excellent way to both protect the contents of the cookie and to verify that the cookie has not been modified unexpectedly. Without this approach, it is difficult, and often impossible, to establish with a high level of confidence that all input is validated.