This variable's value is not used. After the assignment, the variable is either assigned another value or goes out of scope.

Example 1: The following code excerpt assigns to the variable r and then overwrites the value without using it.

  r = getName();
  r = getNewBuffer(buf);

In .Net, static variables are initialized to its default values, however usage of those variables without initializing may lead to business logic based issues or may be used to execute a Denial of Service (DoS) attack. Programs should never use the default value of a variable.

It is not uncommon for programmers to use an uninitialized variable in code that handles errors or other rare and exceptional circumstances. Uninitialized variable warnings can sometimes indicate the presence of a typographic error in the code.

Example 1: The following code will get compiled by the .Net compiler without any error. However, the following statement int a = (Int32)i + (Int32)j; throws an unhandled exception and crashes the application at runtime.

    class Program
        {
            static int? i = j;
            static int? j;
            static void Main(string[] args)
            {
                j = 100;
                int a = (Int32)i + (Int32)j;

                Console.WriteLine(i);
                Console.WriteLine(j);
                Console.WriteLine(a);
            }
        }
    

Most uninitialized variable issues result in general software reliability problems, but if attackers can intentionally trigger the use of an uninitialized variable, they might be able to launch a denial of service attack by crashing the program.

The umask() man page begins with the false statement:

"umask sets the umask to mask & 0777"

Although this behavior would better align with the usage of chmod(), where the user provided argument specifies the bits to enable on the specified file, the behavior of umask() is in fact opposite: umask() sets the umask to ~mask & 0777.

The umask() man page goes on to describe the correct usage of umask():

"The umask is used by open() to set initial file permissions on a newly-created file. Specifically, permissions in the umask are turned off from the mode argument to open(2) (so, for example, the common umask default value of 022 results in new files being created with permissions 0666 & ~022 = 0644 = rw-r--r-- in the usual case where the mode is specified as 0666)."

Antiquated encryption algorithms such as DES no longer provide sufficient protection for use with sensitive data. Encryption algorithms rely on key size as one of the primary mechanisms to ensure cryptographic strength. Cryptographic strength is often measured by the time and computational power needed to generate a valid key. Advances in computing power have made it possible to obtain small encryption keys in a reasonable amount of time. For example, the 56-bit key used in DES posed a significant computational hurdle in the 1970s when the algorithm was first developed, but today DES can be cracked in less than a day using commonly available equipment.

Any area of a website or web application that contains sensitive information or privileged functionality such as a remote administration panel must require authentication to access. If this is not the case, an attacker can take control of or steal sensitive information from a target website or web application by simply browsing to the sensitive page.

Transport layer protections are essential in addition to secure coding and program configuration to fully secure the application against compromises. Enforcing SSL/TLS access to sensitive application resources and functionality is a crucial transport security control that protects applications against unauthorized access. In addition to configuring secure access, it is equally important to disallow connections to these resources that are established over non secure channels.

Allowing both HTTP and HTTPS connections to the server leaves the application susceptible to the same degree of compromise as when secure access is disabled. An attacker can use this weakness to potentially intercept sensitive data including usernames and passwords, customer account information, or similar information.

Appending user-controlled data to a StringBuilder or StringBuffer instance initialized with the default backing character array size (16) can cause the application to consume large amounts of heap memory while resizing the underlying array to fit user's data. When data is appended to a StringBuilder or StringBuffer instance, the instance will determine if the backing character array has enough free space to store the data. If the data does not fit, the StringBuilder or StringBuffer instance will create a new array with a capacity of at least double the previous array size, and the old array will remain in the heap until it is garbage collected. Attackers can use this implementation detail to execute a Denial of Service (DoS) attack.

Example 1: User-controlled data is appended to a StringBuilder instance initialized with the default constructor.

    ...
    StringBuilder sb = new StringBuilder();
    final String lineSeparator = System.lineSeparator();
    String[] labels = request.getParameterValues("label");
    for (String label : labels) {
        sb.append(label).append(lineSeparator);
    }
    ...

Unsafe JSNI errors occur when a GWT application uses JSNI to call javascript code.
Example 1: The following Java code defines a class named Redirect. The class declares one native JavaScript method, which uses JavaScript to change the document location.

import com.google.gwt.user.client.ui.UIObject;

class MyDiv {

    ...

    public static void changeName(final UIObject object, final String name) {
        changeName(object.getElement(), url);
    }

    public static native void changeName(final Element e, final String name) /*-{
        $wnd.jQuery(e).html(name);
    }-*/;

    ...
}

In this example, passing untrusted data to the JSNI function may result in a DOM-based Cross-Site Scripting.

Unsafe Native Invoke errors occur when a managed application uses P/Invoke to call native (unmanaged) code written in another programming language.

Example 1: The following C# code defines a class named Echo. The class declares one native method that uses C to echo commands entered on the console back to the user.

class Echo
{
  [DllImport("mylib.dll")]
  internal static extern void RunEcho();

  static void main(String[] args)
  {
    RunEcho();
  }
}

The following C code defines the native method implemented in the Echo class:

#include <stdio.h>

void __stdcall RunEcho()
{
  char* buf = (char*) malloc(64 * sizeof(char));
  gets(buf);
  printf(buf);
}

Because the Echo is implemented in managed code, it may appear that it is immune to memory issues like buffer overflow vulnerabilities. Although the managed environment does do a good job of making memory operations safe, this protection does not extend to vulnerabilities occurring in native code accessed using P/Invoke. Despite the memory protections offered in the managed runtime environment, the native code in this example is vulnerable to a buffer overflow because it makes use of gets(), which does not perform any bounds checking on its input. As well, buf is allocated but not freed and therefore is a memory leak.

The vulnerability in Example 1 could easily be detected through a source code audit of the native method implementation. This may not be practical or possible depending on the availability of source code and the way the project is built, but in many cases it may suffice. However, the ability to share objects between the managed and native environments expands the potential risk to much more insidious cases where improper data handling in managed code may lead to unexpected vulnerabilities in native code or to unsafe operations in native code corrupting data structures in managed code.

Vulnerabilities in native code accessed through a managed application are typically exploited in the same manner as they are in applications written in the native language. The only challenge to such an attack is for the attacker to identify that the managed application uses native code to perform certain operations. This can be accomplished in a variety of ways, including identifying specific behaviors that are often implemented with native code or by exploiting a system information leak in the managed application that exposes its use of P/Invoke.

CAPTCHAs are commonly used by web applications to prevent automated form submissions that can have an adverse effect on their operation. Poorly written CAPTCHA implementations can provide a false sense of security. Attackers can fingerprint for implementations with known vulnerabilities and use this information to bypass an application's anti-automation protections. CAPTCHA implementations can be identified by:
1. Matching against known client-side code patterns. For instance, HTML tags and attributes with specific values.
2. Matching against textual content identifying the CAPTCHA implementation

Example 1: Powered by Animated Gif Captcha
3. Matching against references to known resources and image files

Using fingerprinting probes, attackers can often identify the web server used to host the target application. This information can be used to:
1. Devise attacks focused on exploiting known vulnerabilities reported against the detected server
2. Test for default configuration properties that could lead to security weaknesses

Example 1: Directory listing enabled
3. Exploit known services exposed by the server

Example 2: WebDAV enabled on IIS
4. Customize attacks for the detected server
5. Enumerate known sensitive resources such as installation, setup, and configuration files

The mobile application includes data that matches the pattern of a Universally Unique Identifier (UUID) in a request to an external host. UUIDs are used by a mobile application to uniquely identify a single user. This helps the mobile device to sync accounts, personalize content, etc., specific to the user.

UUIDs are recommended to track user-specific workflows, but should not be sent to external vendors or third-party apps for tracking. UUIDs are specifically created to personalize the user's experience within the app. Do not share personally identifiable information (PII) with external entities without the user's consent. Doing so is considered a privacy violation.

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.

Storing vector embeddings without encryption or proper access controls can lead to unauthorized access and data leakage. Embeddings often represent sensitive information, and their exposure can compromise data confidentiality and integrity.
Example 1: In the following code snippet, a FAISS index containing embeddings is written to a file named `index.faiss`.

import faiss
...

# Generate random embeddings
embeddings = get_llm_embedding()

# Create a FAISS index
index.add(embeddings)

# Write the index to a file
faiss.write_index(index, "index.faiss")
 

If this file is stored without encryption, it becomes susceptible to unauthorized access, potentially exposing sensitive data.

Using a CDN to serve an application's dependent JavaScript offers many advantages over serving JavaScript from the application's own server. These benefits include increased performance and less code maintenance for the application owner. However, the application assumes that the CDN will deliver safe content to the browser. If an attacker compromises a CDN, the CDN will deliver malicious code to the user's browser. The user's browser is now executing code that the application cannot control or detect as malicious.

Example 1: The following ASPX code includes Microsoft's jQuery code by referencing the Microsoft CDN:

...
<script src="http://ajax.microsoft.com/ajax/jquery/jquery-1.4.2.min.js" type="text/javascript"></script>
...

Example 2: The following ASPX code enables the automatic redirect of all ASP.NET framework script requests to the Microsoft Ajax CDN:

...
<asp:ScriptManager
   ID="ScriptManager1"
   EnableCdn="true"
   Runat="Server" />
...

In Example 2, the ScriptManager control configures its ASPX page to automatically redirect any script requests to the appropriate CDN.

Just about every serious attack on a software system begins with the violation of a programmer's assumptions. After the attack, the programmer's assumptions seem flimsy and poorly founded, but before an attack many programmers would defend their assumptions well past the end of their lunch break.

Two dubious assumptions that are easy to spot in code are "this method call can never fail" and "it doesn't matter if this call fails". When a programmer ignores a condition, they implicitly state that they are operating under one of these assumptions.

Example 1: The following code excerpt ignores an error condition that might happen during a CICS transaction.

...
EXEC CICS
  INGNORE CONDITION ERROR
END-EXEC.
...

If a transaction were to ever fail with this error condition, the program would continue to execute as though nothing unusual had occurred. The program records no evidence indicating the special situation, potentially frustrating any later attempt to explain the program's behavior.

Declaring a method to throw Exception or Throwable makes it difficult for callers to do good error handling and error recovery. Java's exception mechanism is set up to make it easy for callers to anticipate what can go wrong and write code to handle each specific exceptional circumstance. Declaring that a method throws a generic form of exception defeats this system.

Example 1: The following method throws three types of exceptions.

public void doExchange()
  throws IOException, InvocationTargetException,
         SQLException {
  ...
}

While it might seem tidier to write

public void doExchange()
  throws Exception {
  ...
}

doing so hampers the caller's ability to understand and handle the exceptions that occur. Further, if a later revision of doExchange() introduces a new type of exception that should be treated differently than previous exceptions, there is no easy way to enforce this requirement.

Programmers typically catch NullPointerException under three circumstances:

1. The program contains a null-pointer dereference. Catching the resulting exception was easier than fixing the underlying problem.

2. The program explicitly throws a NullPointerException to signal an error condition.

3. The code is part of a test harness that supplies unexpected input to the classes under test.

Of these three circumstances, only the last is acceptable.

Example 1: The following code mistakenly catches a NullPointerException.

  try {
    mysteryMethod();
  }
  catch (NullPointerException npe) {
  }

Programmers typically catch NullReferenceException under three circumstances:

1. The program contains a null-pointer dereference. Catching the resulting exception was easier than fixing the underlying problem.

2. The program explicitly throws a NullReferenceException to signal an error condition.

3. The code is part of a test harness that supplies unexpected input to the classes under test.

Of these three circumstances, only the last is acceptable.

Example 1: The following code mistakenly catches a NullReferenceException.

  try {
    MysteryMethod();
  }
  catch (NullReferenceException npe) {
  }

In Java, finally blocks are always executed after their corresponding try-catch blocks and are often used to free allocated resources, such as file handles or database cursors. Throwing an exception in a finally block can bypass critical cleanup code since normal program execution will be disrupted.

Example 1: In the following code, the call to stmt.close() is bypassed when the FileNotFoundException is thrown.

public void processTransaction(Connection conn) throws FileNotFoundException
{
    FileInputStream fis = null;
    Statement stmt = null;
    try
    {
        stmt = conn.createStatement();
        fis = new FileInputStream("badFile.txt");
        ...
    }
    catch (FileNotFoundException fe)
    {
        log("File not found.");
    }
    catch (SQLException se)
    {
        //handle error
    }
    finally
    {
        if (fis == null)
        {
            throw new FileNotFoundException();
        }

        if (stmt != null)
        {
            try
            {
                stmt.close();
            }
            catch (SQLException e)
            {
                log(e);
            }
        }
    }
}