Sticky ブロードキャストは、権限を設定してセキュリティを確保することはできないため、あらゆる受信者がアクセスできるようになります。これらのブロードキャストに重要なデータが含まれる、あるいは不正な受信者にアクセスする場合には、アプリケーションが危険にさらされる可能性があります。

例 1: 次のコードは、Sticky ブロードキャストを使用しています。

...
context.sendStickyBroadcast(intent);
...

android.permission 名前空間に新しい権限を定義すると、OS の更新時に予期しない結果が発生する場合があります。新しいバージョンの OS がまったく同じ権限を定義すると、Android Package Management Service (PMS) は、ユーザーに確認することなく、アプリに対してサイレントに権限を付与するため、権限昇格攻撃のチャンスを与えることになります。

このコンポーネントは、システムからブロードキャスト メッセージを受信することのみを想定しています。他のコンポーネントからの受信は想定していないため、プライベートにする必要があります (他のコンポーネントからはアクセスできません)。

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

開発者がドキュメントに記載されていない、または非表示の 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();
  }
  ...
}

ハードウェアおよびデバイスの固有IDは、データを消去したり、出荷時の状態に初期化しても、変化しません。ユーザーの認可または認証で使用される一意の ID を生成する場合、データ消去や初期化に依存しないでください。

また、個人情報を伴う可能性があるUUIDをリークさせると、ユーザーのプライバシーおよびセキュリティに脅威を与えます。

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

AngularJS などの特定のフレームワークでは、他のサイトおよび画像のリンクに設定できるプロトコルが制限されます。これは主に、インライン JavaScript の実行を防止して、アプリケーション内でCross-site Scriptingの脆弱性が高まらないようにするためのものです。

例 1: 次の例では、AngularJS 内のプロトコルからなるデフォルトの許可リストを変更して、画像 HTML の要素からもインライン JavaScript を許可できるようにします。

myModule.config(function($compileProvider){
    $compileProvider.imgSrcSanitizationWhitelist(/^(http(s)?|javascript):.*/);
});

Strict Contextual Escaping (SCE) は、AngularJS アプリケーションのメカニズムであり、攻撃者からアプリケーションを保護するのに役立ちます。これにより、さまざまな種類の脆弱性を対象とした数々の攻撃を防ぐことができます。最も突出した保護は、特定の種類の Cross-Site Scripting 攻撃に対するものです。このアプリケーションでは、この保護メカニズムが明確に無効になっています。

例 1: この例では、モジュール上で SCE を無効にしています。

myModule.config(function($sceProvider){
  $sceProvider.enabled(false);
});

アプリケーションは、暗号化された接続を介した圧縮を可能にする permessage-deflate WebSocket 拡張機能を有効にするコードを使用します。このタイプの圧縮を有効にすると、アプリケーションは CRIME タイプや BREACH タイプの攻撃を受ける危険にさらされます。

例 1: 次のコードは、"per-message-deflate" 拡張機能を有効にするために、DangerousEnableCompression を true に設定します。

    app.Run(async context => {
        using var websocket = await context.WebSockets.AcceptWebSocketAsync(new WebSocketAcceptContext() { DangerousEnableCompression = true });
        await websocket.SendAsync(...);
        await websocket.ReceiveAsync(...);
        await websocket.CloseAsync(WebSocketCloseStatus.NormalClosure, null, default);
    });
    

例 2: 次のコードは、DangerousDeflateOptions を使用して、"per-message-deflate" 拡張機能のオプションを設定します。

    using ClientWebSocket ws = new() {
        Options = {
            CollectHttpResponseDetails = true,
            DangerousDeflateOptions = new WebSocketDeflateOptions() {
                ClientMaxWindowBits = 10,
                ServerMaxWindowBits = 10
            }
        }
    };
    

デフォルトでは、ASP.NET サーバーでは HttpSessionState オブジェクト、その属性、および参照するすべてのオブジェクトがメモリに保存されます。この処理モデルでは、アクティブセッションの状態が 1 台のマシンのシステムメモリに保存できる範囲に制限されます。これらの制限を取り除き、容量を拡張するために、複数のサーバーに対して永続的なセッション状態情報が設定される場合がよくあります。これにより容量が拡張され複数のマシン間における複製が許可されるため、全体的なパフォーマンスが向上します。セッション状態を保持するために、サーバーは HttpSessionState オブジェクトをシリアライズする必要があり、このオブジェクトをシリアライズするためには、保存されるすべてのオブジェクトがシリアライズ可能である必要があります。

セッションが正しくシリアライズされるために、セッションの属性としてアプリケーションが保存するすべてのオブジェクトで [Serializable] 属性を宣言する必要があります。さらに、オブジェクトで独自のシリアライズメソッドが必要となる場合には、ISerializable インターフェイスを実装する必要があります。

例 1: 次のクラスは自分自身をセッションに追加しますが、シリアライズ可能ではないため、セッションを正しくシリアライズすることはできません。

public class DataGlob {
   String GlobName;
   String GlobValue;

   public void AddToSession(HttpSessionState session) {
     session["glob"] = this;
   }
}

縮小化によってファイルサイズが減少するため、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 を使用してモデル検証の合否をチェックする。

Microsoft ASP.NET アプリケーションでは、昇格された権限で操作を実行するために、現在のユーザーやプロセスのセキュリティコンテキストを偽装できます。必要となる Authentication 試行の総回数の削減など、コンテキストの偽装は有用な各種の目的に使用できますが、昇格した権限が不適切にそのままとなってしまうプログラムでは、システム全体のセキュリティリスクが高まることになります。プログラムが別のセキュリティコンテキストで実行しているときに、攻撃者がこのプログラムの別の脆弱性を悪用すると、攻撃者が実行する許可されていない操作すべてが、昇格した権限で実行されます。

例 1: 次のコード例は、システムに常に WindowsIdentity.Impersonate() メソッドを使用して認証情報を偽装する通常の使用パターンを示しています。

using System.Security.Principal;
...

//Get the identity of the current user
IIdentity contextId = HttpContext.Current.User.Identity;
WindowsIdentity userId = (WindowsIdentity)contextId;

//Temporarily impersonate
WindowsImpersonationContext imp = userId.Impersonate();

//Perform tasks using the caller's security context
DoSecuritySensitiveTasks();

//Clean up and restore our old security context
impersonate.Undo();

Example 1 のコードは、現在のユーザーのセキュリティコンテキストを偽装して、昇格した操作を実行するためにこの偽装した権限を使用しています。DoSecuritySensitiveTasks() をコールした後、コードは元のセキュリティコンテキストに戻そうとしますが、DoSecuritySensitiveTasks() で例外が発生する場合、Undo() メソッドはコールされることがなく、プログラムは引き続き偽装されたセキュリティコンテキストを使用することになります。

正しい順序でミドルウェア パイプラインに追加されていない 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();
...