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

Heap inspection vulnerabilities occur when sensitive data, such as a password or an encryption key, can be exposed to an attacker because they are not removed from memory.

The realloc() function is commonly used to increase the size of a block of allocated memory. This operation often requires copying the contents of the old memory block into a new and larger block. This operation leaves the contents of the original block intact but inaccessible to the program, preventing the program from being able to scrub sensitive data from memory. If an attacker can later examine the contents of a memory dump, the sensitive data could be exposed.

Example 1: The following code calls realloc() on a buffer containing sensitive data:

plaintext_buffer = get_secret();
...
plaintext_buffer = realloc(plaintext_buffer, 1024);
...
scrub_memory(plaintext_buffer, 1024);

There is an attempt to scrub the sensitive data from memory, but realloc() is used, so a copy of the data can still be exposed in the memory originally allocated for plaintext_buffer.

Heap inspection vulnerabilities occur when sensitive data, such as a password or an encryption key, can be exposed to an attacker because they are not removed from memory.

The VirtualLock function is intended to lock pages in memory to prevent them from being paged to disk. However, on Windows 95/98/ME the function is implemented as stub only and has no effect.

Local Storage Objects (LSO) are a mechanism provided by the Flash platform to persistently store data on the client machine. By default, the Flash security model restricts access to a shared object based on the domain hosting the SWF file that created it, the path of the SWF file, and whether the creating SWF file was hosted on HTTP or HTTPS. The localpath property on a shared object specifies the path of the SWFs that have access to a shared object. For example, a shared object created by http://www.example.com/dir1/dir2/sample.swf can be configured to be accessible by any SWF at http://www.example.com/dir1 by setting its localPath property to http://www.example.com/dir1.
Setting the localPath value to "/", gives all SWF files on that domain access to the shared object. On a domain hosting SWF applications from multiple parties, such a setting might lead to unauthorized data access.

If an application uses "/" to set the localPath inside a SharedObject.getLocal() call, the shared object is configured to be accessible by all SWFs on the domain, which exposes the application to information theft risks.