.NET では、BinaryFormatter クラスを使用して、オブジェクトを、オブジェクト自体と、デシリアライズ中にオブジェクトを再構築するために必要なメタデータの両方を含むバイナリ ストリームに変換することができます。

BinaryFormatter クラスを使用すると、攻撃者が任意のコードを実行したり、アプリケーション ロジックを悪用したり、Denial of Service 状態をトリガーしたりする可能性のある、安全でないデシリアライゼーション シナリオを引き起こす可能性があります。

BinaryFormatter 型の使用は危険であり、安全性が確立できないため、データ処理には推奨されません。

例 1: runtimeConfig.json ファイルで config プロパティ EnableUnsafeBinaryFormatterSerialization を true に設定することによって、アプリケーションは安全でない BinaryFormatter クラスの使用を有効にします。

...
AppContext.SetSwitch("System.Runtime.Serialization.EnableUnsafeBinaryFormatterSerialization", true);
...

AccessibleObject API によって、プログラマは Java アクセス指定子によって行われる Access Control チェックを回避できます。特に、これによってプログラマは、反映されたオブジェクトが Java Access Control を迂回することでプライベートフィールドの値を変更するかまたはプライベートメソッドを呼び出せるようにすることができます。通常これらは許可されない挙動です。

通常の JSF アプリケーションでは、UI コンポーネントで指定されたコンバーターとバリデーターを使用して、値が変換および検証されます。変換と検証自体は、ページが送信されたときに行われます。Fusion アプリケーションでブックマーク可能なビューを使用すると、ページが送信されないため、デフォルトでは同様の変換や検証は実行されません。

例 1: 次の設定ファイル スニペットは、paramName URL パラメーターの変換または検証を実行しないように設定された、ブックマーク可能なビューのサンプルを示しています。

...
    <bookmark>
        <method>#{paramHandler.handleParams}</method>
        <url-parameter>
            <name>paramName</name>
            <value>#{requestScope.paramName}</value>
        </url-parameter>
    </bookmark>
...

開発者がドキュメントに記載されていない、または非表示の API を使用してアプリケーションを構築することはお勧めしません。 Google がこれらの API を今後削除または変更しないという保証がないため、使用を避ける必要があります。そのようなメソッドやフィールドを使用すると、アプリケーションが破壊されるリスクが高くなります。

このコードは、Camera オブジェクトがすでに解放された後でこのオブジェクトの使用を試みます。リソースを再取得しないまま Camera オブジェクトをさらに参照すると例外が発生し、この例外がキャッチされない場合にはアプリケーションがクラッシュする可能性があります。

例 1: 次のコードは、トグル ボタンを使用してカメラのプレビューをオン/オフしています。ユーザーがこのボタンを 1 度押すと、カメラのプレビューは停止し、カメラのリソースは解放されます。ただし、再びボタンを押すと、以前に解放された Camera オブジェクトで startPreview() がコールされます。

public class ReuseCameraActivity extends Activity {
  private Camera cam;

  ...
  private class CameraButtonListener implements OnClickListener {
      public void onClick(View v) {
          if (toggle) {
              cam.stopPreview();
              cam.release();
          }
          else {
              cam.startPreview();
          }
          toggle = !toggle;
      }
  }
  ...
}

このコードは、メディアオブジェクトがすでに解放された後でこのオブジェクトの使用を試みます。リソースを再取得しないままこのメディアオブジェクトをさらに参照すると例外が発生し、この例外がキャッチされない場合にはアプリケーションがクラッシュする可能性があります。

例 1: 次のコードは、一時停止ボタンを使用してメディアの再生を切り替えています。ユーザーがこのボタンを 1 度押すと、楽曲または動画の再生が一時停止し、カメラ リソースは解放されます。ただし、再びボタンを押すと、以前に解放されたメディア リソースで start() がコールされます。

public class ReuseMediaPlayerActivity extends Activity {
  private MediaPlayer mp;

  ...
  private class PauseButtonListener implements OnClickListener {
      public void onClick(View v) {
          if (paused) {
              mp.pause();
              mp.release();
          }
          else {
              mp.start();
          }
          paused = !paused;
      }
  }
  ...
}

このコードは、Android SQLite データベースハンドラがすでに閉じられた後でこのオブジェクトの使用を試みます。データベース接続を再確立しないままハンドラをさらに参照すると例外が発生し、この例外がキャッチされない場合にはアプリケーションがクラッシュする可能性があります。

例 1: 次のコードは、ユーザー値を一時的にメモリにキャッシュするプログラムの一部だと考えられますが、ディスクへの変更をコミットするために flushUpdates() をコールすることができます。このメソッドは、データベースに更新を書き込んだ後、データベース ハンドラを適切に閉じます。しかし、再び flushUpdates() がコールされると、再初期化の前にデータベース オブジェクトが再び参照されます。

public class ReuseDBActivity extends Activity {
  private myDBHelper dbHelper;
  private SQLiteDatabase db;

  @Override
  public void onCreate(Bundle state) {
      ...
      db = dbHelper.getWritableDatabase();
      ...
  }
  ...

  private void flushUpdates() {
      db.insert(cached_data);     // flush cached data
      dbHelper.close();
  }
  ...
}

Android Class Loading Hijacking の脆弱性には、次の 2 つの形態があります。

- プログラムがクラスをロードするために検索するディレクトリの名前を攻撃者が変更可能である。攻撃者は、プログラムに自分が制御するディレクトリへのパスを参照させることで、クラスが検索されるパスを明示的に制御することになります。

- クラスがロードされる環境を攻撃者が変更可能である。攻撃者はパス名の意味を暗黙的に制御することになります。

この場合は 1 つ目の状況が最も懸念されます。攻撃者は、ロードするクラスが検索されるディレクトリを制御できる可能性があります。このタイプの Android Class Loading Hijacking の脆弱性が発生するのは、次の場合です。

1.信頼できないソースからアプリケーションにデータが入り込んだ場合。



2.データが、ロードするクラスが検索されるライブラリ ディレクトリを表す文字列 (またはその一部) として使用された場合。



3.アプリケーションがライブラリ パスのコードを実行することにより、本来付与されないはずの権限や能力を攻撃者に与えられた場合。

例 1: 次のコードでは、ユーザーが変更可能な userClassPath を使用して、ロードするクラスが検索されるディレクトリを決定します。

...
  productCategory = this.getIntent().getExtras().getString("userClassPath");
  DexClassLoader dexClassLoader = new DexClassLoader(productCategory, optimizedDexOutputPath.getAbsolutePath(), null, getClassLoader());
  ...

このコードでは、攻撃者は、制御している別のパスを参照するように userClassPath の結果を変更できるため、ライブラリをロードしてアプリケーションの任意のコードを昇格された権限で実行できます。このプログラムは環境から読み取った値の検証を行わないので、攻撃者は、userClassPath の値を制御できれば、元のアプリケーションと同じ権限を使用し、アプリケーションを操作して制御するディレクトリを参照させることで、自分が定義したクラスをロードできます。

例 2: 次のコードでは、ユーザーが変更可能な userOutput を使用して、Optimized DEX ファイルを書き込むディレクトリを決定します。

...
  productCategory = this.getIntent().getExtras().getString("userOutput");
  DexClassLoader dexClassLoader = new DexClassLoader(sanitizedPath, productCategory, null, getClassLoader());
...

このコードでは、攻撃者が Optimized DEX (ODEX) ファイルの出力ディレクトリを指定できます。その結果、悪意のあるユーザーが userOutput の値を、外部ストレージなど、攻撃者が制御するディレクトリに変更できます。これが実行された後は、出力される ODEX ファイルを悪意のある ODEX ファイルに置き換えるだけで、元のアプリケーションと同じ権限でこれを実行できるようになります。

Android アプリケーションは、デバッグ バイナリを生成するように設定できます。これらのバイナリは詳細なデバッグ メッセージを提供するため、実運用環境では使用しないでください。debuggable 属性 (<application> タグの属性) は、コンパイルされたバイナリにデバッグ情報を含めるかどうかを定義します。

デバッグ バイナリを使用すると、アプリケーションが、それ自体に関するできるだけ多くの情報をユーザーに提供します。デバッグ バイナリは、開発環境またはテスト環境で使用することを目的としており、実運用環境にデプロイするとセキュリティ リスクを引き起こす可能性があります。攻撃者はデバッグ出力から得た追加情報を利用して、フレームワークやデータベースなど、アプリケーションで使用されるリソースを標的に攻撃を仕掛けることがあります。

Zip パス トラバーサル脆弱性が発生するのは、悪意のある攻撃者が特定の Zip ファイル内の Zip ファイル エントリ名を指定できる場合です。Zip ファイル エントリ名が悪意を持って指定されると、攻撃者は対応する Zip ファイルが展開されたときに重要なシステム ファイルの内容を上書きできます。攻撃者は、../ や / などのパス トラバーサル イディオムを使用して、プログラム領域外にあるシステム ファイルにアクセスする可能性があります。Android 14 以降を対象とする Android アプリケーションは、Zip ファイルの抽出中に ../ や / などのイディオムが検出されると、デフォルトで例外を発生させることができます。このセキュリティ機能は、上書きしたり、完全に無効にしたりすることができます。

例 1: 次のコードは、Zip Entry Overwrite 保護を無効にします。

...
dalvik.system.ZipPathValidator.clearCallback();
...

縮小化によってファイルサイズが減少するため、JavaScript ファイルを含むアプリケーションのページロード回数が向上します。縮小化とは、不用な空白、コメント、セミコロン、カッコを削除して、ローカル変数の名前を短縮し、使用しないコードを削除するプロセスです。

例 1: 次の ASPX コードには、Microsoft の jQuery ライブラリの縮小されていないバージョンが含まれています。

...
<script src="http://applicationserver.application.com/lib/jquery/jquery-1.4.2.js" type="text/javascript"></script>
...

検証できない入力は、ASP.NET Web API サービスの主な脆弱性の 1 つです。Cross-Site Scripting、Process Control、Access Control や SQL Injection などのさまざまな脆弱性の原因は入力の未検証です。ASP.NET Web API サービスは通常、メモリ破壊攻撃には影響を受けませんが、ASP.NET Web API サービスが配列境界チェックを行わないネイティブ コードを呼び出す場合には、攻撃者が ASP.NET Web API サービスの入力脆弱性を利用して Buffer overflow 攻撃を仕掛ける可能性があります。

そのような攻撃を防止するためには、以下の手順を実行します。
1. ASP.NET Web API サービス アクションへのパラメーターまたはモデルバインド オブジェクト パラメーターのメンバーの検証チェックを、検証属性を使用してプログラム的にチェックする。
2. ModelState.IsValid を使用してモデル検証の合否をチェックする。

証明書の検証モードを None に設定すると、証明書の検証プロセス全体が無効になり、アプリケーションを中間者 (Man-in-the-Middle) 攻撃の危険にさらすことになります。このモードは、実運用環境では使用しないでください。

cookie は通常、個人情報、認証トークン、ユーザーのアクティビティの履歴など、ユーザーに関する重要な情報を保存するために使用されます。この情報が平文で保存されていると、アプリケーションとの対話に使用されるマシンにアクセスできる人であれば、誰でも cookie に保存されている情報にアクセスできます。さらに、攻撃者が cookie に保存されているデータを任意に変更することを許可されている場合、攻撃者はアプリケーションに提供された情報を改ざんし、その動作を思いどおりに変更できてしまいます。

多くの場合、アプリケーションは cookie からの入力を、使用されるコンテキストに応じてプログラミングで検証できますが、ASP.NET の検証フレームワークは、cookie の内容を保護し、cookie に想定外の変更が加えられていないことを確認するための優れた手法を提供します。このアプローチがなければ、すべての入力が検証されていることを高いレベルの信頼性で確立することは困難であり、多くの場合不可能です。

ASP.NET アプリケーションは、デバッグ バイナリを生成するように設定できます。これらのバイナリは詳細なデバッグ メッセージを提供するため、実運用環境では使用しないでください。debug 属性 (<compilation> タグの属性) は、コンパイルされたバイナリにデバッグ情報を含めるかどうかを定義します。

デバッグ バイナリを使用すると、アプリケーションが、それ自体に関するできるだけ多くの情報をユーザーに提供します。デバッグ バイナリは、開発環境またはテスト環境で使用することを目的としており、実運用環境にデプロイするとセキュリティ リスクを引き起こす可能性があります。攻撃者はデバッグ出力から得た追加情報を利用して、フレームワークやデータベースなど、アプリケーションで使用されるリソースを標的に攻撃を仕掛けることがあります。

セッションを開いたままの時間が長いほど、攻撃者がユーザー アカウントを侵害するチャンスは増えます。セッションをアクティブなままにしておくと、攻撃者がユーザーのパスワードを総当たり攻撃で盗んだり、ユーザーのワイヤレス暗号鍵を解読したり、開いているブラウザーからセッションを乗っ取る可能性があります。認証タイムアウトが長くなると、メモリが解放されなくなり、作成されるセッションが多くなりすぎて最終的に Denial of Service 攻撃が発生する可能性があります。

例 1: 次の例は、認証タイムアウトが 1 時間に設定された ASP.NET MVC を示しています。

...
<configuration>
  <system.web>
  <authentication>
    <forms
      timeout="60" />
  </authentication>
  </system.web>
</configuration>
...

タイムアウト属性が指定されていない場合、認証タイムアウトのデフォルト値は 30 分です。

プログラムは、3 つの方法のいずれかで X.509 証明書を検証するように設定できます。デフォルトでは、証明書は信頼チェーンを介して検証され、信頼されたルート機関に戻ります。この設定は ChainTrust と呼ばれ、証明書が有効であることを最大レベルで保証します。デフォルトでは、すべての証明書は ChainTrust を使用して検証されます。

信頼されたルート機関が発行したものではない証明書を利用するには、PeerTrust または PeerOrChainTrust を設定することで、ピアが発行した証明書を信頼するようにプログラムを設定できます。これらの設定は、証明書によって付与されるセキュリティのレベルを大幅に低下させるため、実運用環境では使用しないでください。

cookie は通常、個人情報、認証トークン、ユーザーのアクティビティの履歴など、ユーザーに関する重要な情報を保存するために使用されます。この情報が平文で保存されていると、アプリケーションとの対話に使用されるマシンにアクセスできる人であれば、誰でも cookie に保存されている情報にアクセスできます。さらに、攻撃者が cookie に保存されているデータを任意に変更することを許可されている場合、攻撃者はアプリケーションに提供された情報を改ざんし、その動作を思いどおりに変更できてしまいます。

多くの場合、アプリケーションは cookie からの入力を、使用されるコンテキストに応じてプログラミングで検証できますが、ASP.NET の検証フレームワークは、cookie の内容を保護し、cookie に想定外の変更が加えられていないことを確認するための優れた手法を提供します。このアプローチがなければ、すべての入力が検証されていることを高いレベルの信頼性で確立することは困難であり、多くの場合不可能です。

web.config にある configuration/system.web/authentication/forms 要素の cacheRolesInCookie 属性が true に設定されている場合、各ユーザーのロールは cookie にキャッシュされます。この情報が平文で保存されていると、アプリケーションとの対話に使用されるマシンにアクセスできる人であれば、誰でも cookie に保存されている情報にアクセスできます。さらに、攻撃者が cookie に保存されているデータを任意に変更することを許可されている場合、攻撃者はアプリケーションに提供された情報を改ざんし、その動作を思いどおりに変更できてしまいます。

多くの場合、アプリケーションは cookie からの入力を、使用されるコンテキストに応じてプログラミングで検証できますが、ASP.NET の検証フレームワークは、cookie に想定外の変更が加えられていないことを確認するための優れた手法を提供します。このアプローチがなければ、すべての入力が検証されていることを高いレベルの信頼性で確立することは困難であり、多くの場合不可能です。

ASP.NET Web サービスは、Web サービスとの通信方法を説明するドキュメントを自動的に生成することにより、Web サービス クライアントの開発を容易にします。

ドキュメント プロトコルが有効になっている Web サービスは、ブラウザーのリクエストを受信すると HTML 形式のページを生成します。

この HTML 形式のページでは、次の情報について説明しています。
1.サポートされている操作
2.各操作が受け入れるパラメーター
3.これらのパラメーターで渡される必要があるデータのタイプ

ドキュメント プロトコルは、XML 形式の Web サービス記述言語 (WSDL) ファイルも生成します。このファイルは、アプリケーションが Web サービスへのリクエストを構造化する方法を理解できるように設計されています。この情報は、開発者、特にパブリック Web サービスのクライアントを作成する開発者にとって非常に役立ちます。しかし、プライベート Web サービスの機能に関する詳細情報を公開すると、悪意のある攻撃者が Web サービスを悪用するリスクが高まります。ドキュメント プロトコルは、Web サービスのすべての関数とパラメーターを必ず記述します。これは、それらの関数のサブセットのみをパブリック アクセス可能にすることが意図されている場合も同じです。