.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>
...

Oracle ADF Faces コンポーネントの属性値は、通常は、サーバーでのみ設定できます。ただし、多数のコンポーネントにより開発者はクライアント上で設定可能な属性のリストを定義できます。これらのコンポーネントの unsecure 属性によりこのようなリストを指定できます。

現在、unsecure 属性内に表示できる属性は、disabled のみです。この属性を使用して、クライアントはどのコンポーネントを有効または無効にするかを定義できるようになります。本来サーバーでのみ設定可能にする必要がある属性値を、クライアントが制御できるようにするのは良いアイデアではありません。

例 1: 次のコードは、ユーザーからパスワード情報を収集して unsecure 属性を使用する inputText コンポーネントを示しています。

...
    <af:inputText id="pwdBox"
                  label="#{resources.PWD}"
                  value=""#{userBean.password}
                  unsecure="disabled"
                  secret="true"
                  required="true"/>
...

Cookie は、RFC 2109 による厳格な HTTP メカニズムです。 Cookie が file:// を含む HTTP 以外のプロトコルに対して動作するはずがありません。 それらのプロトコルの動作や適用されるセキュリティ区分化のルールは不明です。 たとえば、インターネットからローカル ディスクにダウンロードされた HTML ファイルは、ローカルにインストールされた HTML コードと同じ cookie を共有するのでしょうか?

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();
...

検証できない入力は、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 を使用してモデル検証の合否をチェックする。

正しい順序でミドルウェア パイプラインに追加されていない ASP.NET Core ミドルウェアは、意図したとおりに機能せず、その結果、アプリケーションはさまざまなセキュリティの問題にさらされたままになります。

例 1:UseCookiePolicy() メソッドは、Cookie ポリシー ミドルウェアをミドルウェア パイプラインに追加します。これにより、カスタマイズした Cookie ポリシーが許可されます。ここに示すように、間違った順序で指定されると、プログラマーによって指定された Cookie ポリシーはすべて無視されます。

...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    ...
}

app.UseCookiePolicy();
...

正しい順序でミドルウェア パイプラインに追加されていない ASP.NET Core ミドルウェアは、意図したとおりに機能せず、その結果、アプリケーションはさまざまなセキュリティの問題にさらされたままになります。

例 1:UseHttpsRedirection() メソッドは、HTTPS リダイレクション ミドルウェアをミドルウェア パイプラインに追加します。これにより、安全でない HTTP リクエストを安全な HTTPS リクエストにリダイレクトすることが可能になります。ここに示すように、間違った順序で指定されると、リダイレクト前にリストされたミドルウェアを介したリクエスト処理の前に、意味のある HTTPS のリダイレクションは行われません。これにより、HTTP リクエストを、安全な HTTPS 接続にリダイレクトされる前にアプリケーションで処理できるようになります。

...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    ...
}

app.UseHttpsRedirection();
...

正しい順序でミドルウェア パイプラインに追加されていない ASP.NET Core ミドルウェアは、意図したとおりに機能せず、その結果、アプリケーションはさまざまなセキュリティの問題にさらされたままになります。

例 1:UseHttpLogging() メソッドは、HTTP ロギング ミドルウェアをミドルウェア パイプラインに追加します。これにより、ミドルウェア コンポーネントによるログ記録が可能になります。ここに示すように、間違った順序で指定されると、UseHttpLogging() への呼び出しの前にパイプラインに追加されたミドルウェアはログを記録しません。

...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    ...
}

app.UseHttpLogging();
...

例 2:UseWC3Logging() メソッドは、W3C ロギング ミドルウェアをミドルウェア パイプラインに追加します。これにより、ミドルウェア コンポーネントによるログ記録が可能になります。ここに示すように、間違った順序で指定されると、UseWC3Logging() への呼び出しの前にパイプラインに追加されたミドルウェアはログを記録しません。

...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    ...
}

app.UseWC3Logging();
...

証明書の検証モードを 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 サービスのすべての関数とパラメーターを必ず記述します。これは、それらの関数のサブセットのみをパブリック アクセス可能にすることが意図されている場合も同じです。