deserialization 중에 readObject()는 생성자로 사용되므로 이 함수가 종료될 때까지는 개체 초기화가 완료되지 않습니다. 따라서 Serializable 클래스의 readObject() 함수가 오버라이드 가능 함수를 호출하면 개체가 완전히 초기화되기 전에 오버라이드 메서드가 개체 상태에 접근할 수 있습니다.

예제 1: 다음 readObject() 함수는 오버라이드할 수 있는 메서드를 호출합니다.

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

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

checkStream() 함수와 이 함수를 포함하는 클래스는 final 및 public이 아니므로 함수를 오버라이드할 수 있습니다. 이로 인해 공격자는 checkStream() 함수를 오버라이드하여 역직렬화 중에 개체에 접근할 수 있습니다.

getter 전용 속성에서 private readonly 목록 변수를 반환하면 호출 코드가 목록의 콘텐트를 수정할 수 있기 때문에 사실상 목록 쓰기 액세스 권한을 부여하게 되어 private readonly로 선언한 프로그래머의 의도와는 반대가 됩니다.

예제 1: 다음 코드에는 private readonly로 선언된 _item 목록이 포함되어 있습니다.

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

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

첫 번째 호출이 완료되기 전에 악의적인 계약이 호출 계약을 다시 호출하면 재진입 공격이 발생합니다. 취약한 계약에서 현재 호출의 결과를 로컬에 적용하기 전에 외부 계약과 상호 작용하는 함수를 노출하면 이러한 공격이 진행됩니다. 그러면 외부 계약이 상호 작용의 제어 흐름을 통제하게 될 수 있습니다.

악의적인 계약에서 피해자가 노출한 함수를 호출하여 해당 함수가 호출 계약과 안전하지 않은 방식으로 상호 작용하는 경우, 공격 계약이 폴백 함수 등을 통해 상호 작용을 수신하여 처리한 후 피해자가 노출한 함수를 즉시 다시 호출함으로써 호출-상호 작용-호출 루프 상태를 야기합니다. 이와 같은 재귀 상태에서는 피해자가 추가 코드를 실행할 수 없게 되며, 상호 작용의 특성에 따라 자산이나 값 중 일부 또는 전체가 유출될 수 있습니다.

Checks-Effects-Interaction 패턴은 보통 스마트 계약에서 잘못된 논리를 방지하는 데 사용됩니다. 해당 패턴은 코드가 필수 조건을 먼저 확인하고 관련 상태 변경(효과)을 수행한 후에 마지막으로 해당 효과와 관련된 외부 계약과 상호 작용을 하도록 지정합니다.

예제 1: 다음 예에서는 Checks-Effects-Interaction 패턴을 준수하지 않고 확인, 상호 작용, 효과 적용을 차례로 수행하므로 재진입 공격이 허용됩니다.

각 코드가 수행하는 작업은 다음과 같습니다.

1. 보낸 사람의 잔액을 확인합니다(Checks).
2. msg.sender.call.value를 통해 호출자에게 Ether를 전송합니다(상호 작용).
3. 보낸 사람의 잔액을 차감하여 상태 변경을 수행합니다(확인).

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

Example 1의 코드는 Checks-Effects-Interaction 패턴을 중단하기 위해 Checks-Interaction-Effects를 대신 수행합니다. 따라서 공격 스마트 계약이 폴백 함수에서 Ether를 수신한 직후 withdraw를 다시 호출하는 경우 재진입이 진행될 수 있으며, 그러면 Ether가 유출되는 재귀 상황이 발생합니다. 잔액을 차감(효과)하는 코드 줄은 실행되지 않기 때문입니다.

재귀를 사용하는 것은 연결된 데이터 구조를 만들고 관리하기 위한 필수 요소입니다. 데이터가 순환 링크를 포함하는 경우 재귀는 무한정 처리될 위험이 있으며, 이는 차례로 스택을 고갈시키고 프로그램을 중단시킵니다.

예제 1: 다음 코드 조각은 Apache Log4j2를 사용하여 이 취약점을 보여줍니다.

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

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

자식이 재귀적 처리 메서드가 포함된 toString()을 호출할 때 스택 오버플로 예외(스택 소진)를 트리거합니다. 이 예외는 자식과 부모 간의 순환 링크로 인해 발생합니다.

부동 소수점 값을 String 개체에 비교하려면 먼저 해당 값을 String 개체로 변경해야 합니다. 일반적으로 Double.toString()과 같은 함수를 통해 변경합니다. 부동 소수점 변수의 값과 유형에 따라 String 개체로 변환할 때 해당 값은 "NaN", "Infinity", "-Infinity"가 되거나, 0이 포함된 후행 소수점을 일정 수만큼 포함하거나, 지수 필드를 포함할 수 있습니다. 16진수 문자열로 변환하는 경우에도 표현이 매우 달라질 수 있습니다.

예제 1: 다음 코드는 부동 소수점 변수를 String과 비교합니다.

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

Windows Azure SQL 데이터베이스는 SQL Server 인증만 지원합니다. Windows 인증(통합 보안)은 지원되지 않습니다. 사용자는 Windows Azure SQL 데이터베이스에 연결할 때마다 자격 증명(로그인 및 암호)을 제공해야 합니다. Microsoft Windows Azure SQL 데이터베이스 일반 지침 및 제한 사항에 따르면 admin, administrator, guest, root, sa와 같은 계정 이름은 사용할 수 없습니다.

주변의 코드가 이 문의 실행을 불가능하게 합니다.

예제: 두 번째 if 문에 대한 조건을 만족할 수 없습니다. s에 null이 아닌 값을 지정할 수 있는 경로에서만, return 문이 있는 동안 s가 null이 아닌 값이어야 합니다.

String s = null;

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

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