During deserialization, readObject() acts like a constructor, so object initialization is not complete until this function ends. Therefore when a readObject() function of a Serializable class calls an overridable function, this may provide the overriding method access to the object's state prior to it being fully initialized.

Example 1: The following readObject() function calls a method that can be overridden.

  ...
  private void readObject(final ObjectInputStream ois) throws IOException, ClassNotFoundException {
    checkStream(ois);
    ois.defaultReadObject();
  }

  public void checkStream(ObjectInputStream stream){
    ...
  }

Since the function checkStream() and its enclosing class are not final and public, it means that the function can be overridden, which may mean that an attacker may override the checkStream() function in order to get access to the object during deserialization.

Returning a private readonly list variable from a getter-only property allows the calling code to modify the contents of the list, effectively giving the list write access and contradicting the intentions of the programmer who made it private readonly.

Example 1: The following code contains a list _item which is declared as private readonly.

       class Order
      {
          private readonly List<string> _item = new List<string>();
          public IEnumerable<string> Item { get { return _item; } }
          
          public Order()
          {
              /*class initialize            */
          }

          /*some important function......*/
      }
    

A reentrancy attack occurs when a malicious contract calls back into the calling contract before the first invocation is finished. This happens when the vulnerable contract exposes a function that interacts with external contracts before locally carrying out the effect of the current call. This can lead to the external contract taking over the control flow of the interaction.

If a malicious contract calls the exposed function of a victim that unsafely interacts back with the calling contract, then the attacking contract will receive and process the interaction (via a fallback function for example) and immediately call back the victim's exposed function again in order to enter a call-interact-call loop. This recursive state prevents any further code in the victim to be executed and can lead to partial or total draining of assets or values depending on the nature of the interaction.

The Checks-Effects-Interaction pattern is commonly used in smart contracts to prevent incorrect logic. The pattern designates that the code first check any required conditions, then carry out the related state change (the effect) and finally interact with the external contract in relation to that effect.

Example 1: The following example allows a reentrancy attack by performing a check, interaction, and then effect, not adhering to the Checks-Effects-Interaction pattern.

The code:

1. Checks the balance of the sender (Checks).
2. Sends out Ether to the caller via msg.sender.call.value (Interaction).
3. Performs a state change by decreasing the balance of the sender (Effects).

function withdraw(uint amount) public{
    if (credit[msg.sender] >= amount) {
        require(msg.sender.call.value(amount)());
        credit[msg.sender]-=amount;
    }
}

The code in Example 1 breaks the Checks-Effects-Interaction pattern by doing Checks-Interaction-Effects instead. This can lead to reentrancy if an attacking smart contract receives the Ether in a fallback function and immediately calls back withdraw, creating a recursive situation where Ether is drained because the line of code that decreases the balance (aka the Effect) never gets executed.

Using recursion is a staple for creating and managing linked data structures. Recursion also runs the risk of processing indefinitely if the data incorporates a circular link, which in turn will exhaust the stack and crash the program.

Example 1: The following code snippet demonstrates this vulnerability using Apache Log4j2.

Marker child = MarkerManager.getMarker("child");
Marker parent = MarkerManager.getMarker("parent");

child.addParents(parent);
parent.addParents(child); 
        
String toInfinity = child.toString();

When child calls toString(), which includes a recursive processing method, it triggers a stack overflow exception (stack exhaustion). This exception occurs due to the circular link between child and parent.

In order to compare a floating-point value to a String object, it must first be changed into a String object, typically via a function such as Double.toString(). Depending on the type and value of the floating-point variable, when converted to a String object, it could be "NaN", "Infinity", "-Infinity", have a certain amount of trailing decimal places containing zeroes, or may contain an exponent field. If converted to a hexadecimal String, the representation may differ greatly as well.

Example 1: The following compares a floating-point variable with a String.

  ...
  int initialNum = 1;
  ...
  String resultString = Double.valueOf(initialNum/10000.0).toString();
  if (s.equals("0.0001")){
    //do something
    ...
  }
  ...

Windows Azure SQL Database supports only SQL Server Authentication. Windows Authentication (integrated security) is not supported. Users must provide credentials (login and password) every time they connect to Windows Azure SQL Database. Per Microsoft Windows Azure SQL Database General Guidelines and Limitations, the following account names are not available: admin, administrator, guest, root, sa.

The surrounding code makes it impossible for this statement to ever be executed.

Example: The condition for the second if statement is impossible to satisfy. It requires that the variable s be non-null, while on the only path where s can be assigned a non-null value there is a return statement.

String s = null;

if (b) {
   s = "Yes";
   return;
}

if (s != null) {
   Dead();
}