デシリアライゼーションの間、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 ではなくパブリックであるため、関数がオーバーライドできるようになります。つまり、攻撃者は checkStream() 関数をオーバーライドし、デシリアライゼーションの間、オブジェクトにアクセスできるようになります。

private readonly リスト変数を getter-only プロパティから戻すと、呼び出し元のコードはリストのコンテンツを変更でき、実質的にリストに書き込みアクセスを許可するので、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......*/
      }
    

リエントランシー攻撃は、最初の呼び出しが終了する前に、悪意のあるコントラクトが呼び出し元コントラクトにコールバックするときに発生します。これは、脆弱なコントラクトが、現在の呼び出しのエフェクトをローカルで実行する前に、外部コントラクトとインタラクションを行う関数を公開するときに発生します。これにより、外部コントラクトがインタラクションの制御フローを引き継ぐ可能性があります。

悪意のあるコントラクトが、呼び出し元コントラクトと安全でない方法で対話している被害者の公開済み関数を呼び出すと、攻撃者のコントラクトはそのインタラクションを (たとえばフォールバック関数経由で) 受信して処理し、call-interact-call ループに入るためにすぐに被害者の公開済み関数をコールバックします。この再帰的な状態になると、被害者側ではそれ以上コードを実行できなくなり、その結果、インタラクションの性質に応じて資産や価値が部分的または全体的に流出する可能性があります。

Checks-Effects-Interaction パターンは、誤ったロジックを防ぐためにスマート コントラクトでよく使用されます。このパターンは、コードがまず必要な条件をチェックし、続いて関連する状態変更を実行し (エフェクト)、最後にそのエフェクトに関連して外部コントラクトとのインタラクションを行うことを指定しています。

例 1: 次の例は、Checks-Effects-Interaction パターンに従わずに、チェック、インタラクション、エフェクトを実行することにより、リエントランシー攻撃を許可しています。

コード:

1.送信者の残高を確認します (チェック)。
2.msg.sender.call.value 経由で呼び出し元にイーサを送信します (インタラクション)。
3.送信者の残高を減らすことで状態変化を行います (エフェクト)。

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

Example 1 のコードは、Checks-Interaction-Effects を実行するのではなく、Checks-Effects-Interaction パターンを壊しています。これは、攻撃するスマート コントラクトがフォールバック関数でイーサを受け取り、すぐに withdraw をコールバックした場合に、リエントランシーにつながるおそれがあります。これにより、残高を減らすコード行 (エフェクト) が実行されないためにイーサが流出するという再帰的な状況が作られます。

再帰の使用は、リンクされたデータ構造を作成および管理するために不可欠な要素です。また、データに循環リンクが組み込まれている場合、再帰によって処理が無期限に行われるリスクがあります。これにより、スタックが使い果たされ、プログラムがクラッシュします。

例 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"、ゼロを含む一定の小数値を持つ値、または指数フィールドを含む値になる場合があります。16 進数の String に変換された場合も、表現が大幅に異なることがあります。

例 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 の各アカウント名は使用できません。

このステートメントは、周辺のコードによって実行されてないようになっています。

例: 2 つ目の if ステートメントで条件が満たされることはありません。変数 s には NULL 以外の値が求められていますが、一方で、s に NULL 以外の値を割り当てることができるパスには、return ステートメントが記述されています。

String s = null;

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

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