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

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

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

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

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

デバッグのみを目的とした API が使用されます。

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

デフォルトでは、Fusion アプリケーションのタスク フローは GET リクエストから直接アクセスできません。URL がタスク フローを呼び出そうとするたびに、HTTP 403 ステータス コードを受け取ります。しかし、暗黙的な設定に依存すると明確性に欠け、デフォルト設定が変更された場合、望ましくない動作が発生する可能性があります。

例 1: タスク フロー定義ファイルの次のスニペットは、暗黙のデフォルト url-invoke-disallowed 設定を使用して設定されたタスク フローの例を示します。

...
    <task-flow-definition id="password">
        <default-activity>PasswordPrompt</default-activity>
        <view id="PasswordPrompt">
            <page>/PasswordPrompt.jsff</page>
        </view>
        <use-page-fragments/>
    </task-flow-definition>
...

通常の 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 ファイルに置き換えるだけで、元のアプリケーションと同じ権限でこれを実行できるようになります。

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

書き込み、更新、または削除によりデータを変更する ASP.NET MVC コントローラー アクションは、以下のいずれかの HTTP 動詞のみを受け入れるように制限することでメリットが得られる可能性があります。Post、Put、Patch、または Delete。誤ってリンクをクリックしても、アクションの実行が起きないため、これによりクロスサイト リクエスト forgery の難易度が増加します。

次のコントローラアクションはデフォルトでどの動詞も許可するため、Cross-Site Request Forgery 攻撃の影響を受けやすいと考えられます。

public ActionResult UpdateWidget(Model model)
{
  // ... controller logic
}

必要な ([Required] 属性でマークされた) プロパティとオプションの ([Required] 属性でマークされていない) プロパティを持つモデルクラスは、攻撃者が想定以上のデータを含む要求を送信した場合に問題を引き起こす可能性があります。

ASP.NET MVC フレームワークは、リクエストパラメータをモデルのプロパティにバインドしようとします。

モデルバインドを行うパラメーターを明示的に通知せず、必要度が混在している場合、内部用のモデルプロパティがあるけれども、攻撃者による制御が可能であることを示す場合があります。

次のコードで定義されるモデルクラス例には、[Required] を含むプロパティと [Required] を含まないプロパティがあります。

public class MyModel
{
    [Required]
    public String UserName { get; set; }

    [Required]
    public String Password { get; set; }

    public Boolean IsAdmin { get; set; }
}

オプションのパラメーターによってアプリケーションの挙動が変わる場合は、攻撃者はオプションのパラメーターをリクエストで送信することにより実際にその挙動を変えることができます。

必須の ([Required] 属性でマークされた) non-nullable プロパティを持つモデルクラスを使用すると、攻撃者から想定より少ないデータを含んでいるリクエストが送信された場合に問題を引き起こす可能性があります。

ASP.NET MVC フレームワークは、リクエストパラメータをモデルのプロパティにバインドしようとします。

モデルに必須の non-nullable パラメーターが含まれており、攻撃者がその必須パラメーターをリクエストで送信しない場合、つまり攻撃者が under-posting 攻撃を利用する場合、プロパティにはデフォルト値 (通常はゼロ) が与えられ、[Required] 検証属性を満たします。この場合、アプリケーションが不測の挙動を起こします。

次のコードで定義されるモデルクラス例には、non-nullable の必須 enum が含まれています。

public enum ArgumentOptions
{
    OptionA = 1,
    OptionB = 2
}

public class Model
{
    [Required]
    public String Argument { get; set; }

    [Required]
    public ArgumentOptions Rounding { get; set; }
}

モデルクラスに必須のプロパティが含まれており、そのタイプが親モデルクラスのオプションメンバーの場合、攻撃者が想定より少ない量のデータを含んでいるリクエストを送信すると under-posting 攻撃の影響を受ける可能性があります。

ASP.NET MVC フレームワークは、サブモデルを含むモデルのプロパティにリクエストパラメータをバインドしようとします。

サブモデルがオプションの場合、つまり親モデルに [Required] 属性なしのプロパティが含まれる場合、攻撃者がそのサブモデルを送信しないと、親プロパティには null 値が与えられ、子モデルの必須フィールドはモデル検証によってアサートされません。これは under-posting 攻撃の 1 つの形態です。

以下のモデルクラス定義を考慮してください。

public class ChildModel
{
    public ChildModel()
    {
    }

    [Required]
    public String RequiredProperty { get; set; }
}

public class ParentModel
{
    public ParentModel()
    {
    }

    public ChildModel Child { get; set; }
}

攻撃者が ParentModel.Child プロパティの値を送信しない場合、ChildModel.RequiredProperty プロパティにはアサートされない [Required] が与えられます。この場合、問題となる不測の結果が生じる可能性があります。

デフォルトでは、EBS ボリュームは暗号化されません。
例 1: 次のテンプレートの例では、データが盗難や不正アクセスの危険にさらされます。

	Resources:
  	  EBSVOLExample:
    	Type: AWS::EC2::Volume
    	Properties:
      	  Encrypted: false