多くのアプリケーションは、cookie を使用してユーザーのセッション ID を伝達します。アプリケーションが HTTPS 経由でアクセスされる場合、cookie は保護されます (攻撃者は cookie を盗聴できません)。ただし、開発者が、アプリケーションの機密性の低い部分への HTTP アクセスを許可すると、セッション ID が盗まれる可能性があります。ユーザーがサイトの保護されていない部分を閲覧すると、セッション ID を含む cookie が平文で送信されます。攻撃者は、トラフィックの盗聴時にセッション ID を閲覧し、それを使用してユーザーのセッションを制御します。


次の例は、安全でないチャネルと安全なチャネルが混在した設定を示しています。

  <property name="filterInvocationDefinitionSource">
    <value>
      CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
      \A/secure/.*\Z=REQUIRES_SECURE_CHANNEL
      \A/acegilogin.jsp.*\Z=REQUIRES_SECURE_CHANNEL
      \A/j_acegi_security_check.*\Z=REQUIRES_SECURE_CHANNEL
      \A.*\Z=REQUIRES_INSECURE_CHANNEL
    </value>
  </property>

Acegi Security では、セキュア オブジェクトのコールバック フェーズ中に、SecurityContext の Authentication オブジェクトを一時的に置き換えることができます。これは、元の Authentication オブジェクトが AuthenticationManager および AccessDecisionManager によって正常に処理された場合にのみ発生します。RunAsManager はこの認証オブジェクトを作成します。
通常開発者は、メソッド呼び出しの間、RunAsManager を使用して、認証済みユーザー用に 1 つ以上の追加のロールを設定します。これは、リモート アプリケーションへのアクセスが必要なセキュア Bean に役立ちます。リモート アプリケーションは異なる資格情報を要求する場合があるため、これにより、呼び出し元のロールとリモート アプリケーションに必要なロールを変換して、リモート アクセスを成功させることができます。新しい Authentication オブジェクト (RunAsUserToken と呼ばれる) は、それ以上の認証または承認のチェックを受けずに、有効な Authentication オブジェクトとしてそのまま受け入れられます。
新しい Authentication オブジェクトに新しいロールまたは特権を追加すると、ユーザーの特権が一時的に引き上げられ、ユーザーが不正なアクションを実行できるようになる可能性があります。
次の設定は、RunAsManager を使用してロール "ROLE_PEON" を持つユーザーにロール "UBER_BOSS" を追加することで、このユーザーの権限を一時的にマネージャー特権に引き上げます。これにより、すべての Peon が PrivateCatalog からデータを取得できるようになります。

<bean id="bankManagerSecurity" class="org.acegisecurity.intercept.method.aopalliance.MethodSecurityInterceptor">
...
 <property name="objectDefinitionSource">
   <value>
     com.example.service.PrivateCatalog.getData=ROLE_PEON,RUN_AS_UBER_BOSS
...
   </value>
 </property>
</bean>

コンテンツ プロバイダーに対して読み取り権限と書き込み権限を個別に定義することをお勧めしますが、writePermission のみを定義すると誤解を招く可能性があります。SQL の性質上、真の書き込み専用クエリを生成することは一般的に不可能です。ユーザーがデータに直接アクセスできない場合でも、攻撃者が where 句を操作して保存されたデータを再構築する可能性があります。

例 1:writePermission のみを使用して宣言されたコンテンツプロバイダの例を次に示します。

 <provider android:name=".ContentProvider" android:writePermission="content.permission.WRITE_CONTENT"/> 

ブロードキャストの送信者の権限を指定せずに登録された受信者は、すべてのブロードキャストの送信者からのメッセージを受信できます。これらのメッセージに悪意のあるデータが含まれる場合や、悪意のあるブロードキャスト送信者からメッセージが送信されると、アプリケーションが危険にさらされる可能性があります。

例 1: 次のコードは、ブロードキャスト送信者の権限を指定せずに受信者を登録しています。

...
context.registerReceiver(broadcastReceiver, intentFilter);
...

すべてのアプリケーションが、マニフェスト定義でアクセス許可が明示的に割り当てられていないパブリック コンポーネントにアクセスできます。

Android アプリケーションのアクティビティ、レシーバー、およびサービスコンポーネントの exported 属性のデフォルト値は、intent-filter の有無に依存します。intent-filter が存在している場合、コンポーネントでは外部使用が意図されていることを意味しているため、exported 属性には true が設定されます。このコンポーネントは、Android プラットフォーム上の他のどのアプリケーションからもアクセスできるようになります。

例 1:intent-filter は設定されているが明示的なアクセス権限は設定されていない場合の Android アクティビティの例を次に示します。

 <activity android:name=".AndroidActivity"/> 

   <intent-filter android:label="activityName"/> 

    <action android:name=".someFunAction"/> 

   </intent-filter> 

    ... 

 </activity> 

このアクティビティは、悪意のあるアプリケーションによって悪用される可能性があります。

すべてのアプリケーションが、マニフェスト定義でアクセス許可が明示的に割り当てられていないパブリック コンポーネントにアクセスできます。android:minSdkVersion または android:targetSdkVersion を "16" またはそれ以前に設定するアプリケーションの場合、Android コンテンツ プロバイダーはデフォルトでエクスポートされます。これらの属性のいずれかを "17" またはそれ以降に設定するアプリケーションの場合、デフォルトは "false" です。

例 1: 明示的なアクセス権限もエクスポートされたフラグもなしで宣言された Android コンテンツプロバイダの例を次に示します。

 <provider android:name=".ContentProvider"/> 

Android は、安全なネットワーク通信の実現のため、セキュリティ プロバイダーに依存しています。ただし、デフォルトのセキュリティ プロバイダーに脆弱性が見つかることがあります。これらの脆弱性に対処するため、Google Play サービスは、デバイスのセキュリティ プロバイダーを自動的に更新して、既知のエクスプロイトから保護する手段を提供しています。Google Play サービスのメソッドを呼び出すことで、最新のアップデートが適用されたデバイスでアプリが実行され、既知のエクスプロイトから保護されていることを保証できます。

ネットワーク セキュリティ設定機能により、アプリは、アプリ コードを変更せずに、安全な宣言型設定ファイルでネットワーク セキュリティ設定をカスタマイズできます。これらの設定は、特定のドメインおよび特定のアプリについて設定できます。この機能の主な機能は次のとおりです。
- カスタム信頼アンカー: アプリの安全な接続のため、どの証明機関 (CA) を信頼するかをカスタマイズします。たとえば、特定の自己署名証明書だけを信頼したり、アプリが信頼するパブリック CA のセットを制限します。
- デバッグのみのオーバーライド: インストール ベースのリスクを高めることなく、アプリ内で安全な接続を安全にデバッグします。
- クリアテキスト トラフィックのオプトアウト: クリアテキスト トラフィックの誤った使用からアプリを保護します。
- 証明書のピン留め: アプリの安全な接続を特定の証明書に制限します。

受信者の権限を設定せずに送信されたブロードキャストはすべての受信者がアクセスできます。これらのブロードキャストに重要なデータが含まれる、あるいは不正な受信者にアクセスする場合には、アプリケーションが危険にさらされる可能性があります。

例 1: 次のコードは、受信者の権限を指定せずにブロードキャストを送信しています。

...
context.sendBroadcast(intent);
...

システム ブロードキャストはプライベート コンポーネントに送信できます。サードパーティからの非システム ブロードキャストを受信するには、コンポーネントをパブリックにする必要があります。システム ブロードキャストと非システム ブロードキャストの両方を単一のコンポーネントで受信するように登録すると、コンポーネントの機能の一部 (システム部分) が不必要にサードパーティに公開されます。

カスタム権限を宣言する場合、権限の保護レベルを指定するための 4 つのオプションがあります: normal、dangerous、signature、および signature or system。Normal 権限は、それらを要求するすべてのアプリケーションに付与されます。Dangerous 権限は、ユーザーの確認後にのみ付与されます。Signature 権限は、権限を定義するパッケージと同じ開発者キーによって署名されたアプリケーションにのみ付与されます。Signature or system 権限は signature 権限と似ていますが、Android システム イメージのパッケージにも付与されます。

例 1:normal 保護レベルで宣言されたカスタム権限の例を次に示します。

 <permission android:name="custom.PERMISSION"
                     android:label="@string/label_permission"
                     android:description="@string/desc_permission"
                     android:protectionLevel="normal">
      </permission>

読み取りと書き込みの permission を組み合わせて宣言されたコンテンツ プロバイダーには、そのプロバイダーに読み取りまたは書き込みアクセスを要求するエンティティがアクセスできるようになります。しかし、多くの場合、ファイル システム上のファイルの場合と同様に、プロバイダーによって保存されたデータへの読み取りアクセスを必要とするエンティティに、データの変更を許可すべきではありません。permission 属性を設定した場合、データ ユーザーとデータの整合性に影響を与える相互作用を区別できません。

例 1: 読み取りおよび書き込みを組み合わせたアクセス permission をコンテンツプロバイダで宣言した例を次に示します。

 <provider android:name=".ContentProvider" android:permission="content.permission.READ_AND_WRITE_CONTENT"/> 

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

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

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

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

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

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

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

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
            }
        }
    };
    

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() メソッドはコールされることがなく、プログラムは引き続き偽装されたセキュリティコンテキストを使用することになります。