内部 Intent は、内部コンポーネントによって定義されたカスタム アクションを使用します。暗黙的なインテントを使用すると、特定のコンポーネントを知らなくても、外部コンポーネントからのインテントの呼び出しが容易になります。この 2 つを組み合わせることで、アプリケーションは、目的のアプリケーション コンテキストの外部から、特定の内部使用のために指定されたインテントにアクセスできるようになります。

外部アプリケーションから内部 Intent を処理できることにより、情報漏洩や Denial of Service からリモート コード実行に至るまで、Intent で指定された内部アクションのキャパシティに応じて、さまざまな深刻度の中間者攻撃が可能になります。

例 1: 次のコードは、暗黙的な内部 Intent を使用しています。

...
val imp_internal_intent_action = Intent("INTERNAL_ACTION_HERE")
startActivity(imp_internal_intent_action)
...

Android インテントは、特定のコンポーネントが実行するアクションについての指示を提供することにより、アプリケーションとアプリケーション コンポーネントをバインドするために使用されます。ペンディング インテントは、後で Intent を提供するために作成されます。暗黙的インテントは、一般的な名前やフィルタを使用して実行を決定することで、外部コンポーネントからのインテントの呼び出しを容易にします。

暗黙的な Intent が PendingIntent として作成されると、Intent が、想定される一時的なコンテキスト外で実行されている、意図しないコンポーネントに送信される可能性があります。その結果、システムが、Denial of Service、個人情報やシステム情報の漏洩、特権昇格などの攻撃にさらされることになります。

例 1: 次のコードは、暗黙的な PendingIntent を使用しています。

...
val imp_intent = Intent()
val flag_mut = PendingIntent.FLAG_MUTABLE
val pi_flagmutable_impintintent = PendingIntent.getService(
    this,
    0,
    imp_intent,
    flag_mut
)
...

PendingIntent の基盤となる Intent の変更を、作成後に許可すると、システムが攻撃にさらされやすくなります。これは主に、基盤となる Intent の全体的な機能に依存します。ほとんどの場合、PendingIntent フラグを FLAG_IMMUTABLE に設定することが、潜在的な問題を防ぐためのベスト プラクティスです。

例 1: 以下には、フラグ値 FLAG_MUTABLE を使用して作成された PendingIntent が含まれています。

...
val intent_flag_mut = Intent(Intent.ACTION_GTALK_SERVICE_DISCONNECTED, Uri.EMPTY, this, DownloadService::class.java)
val flag_mut = PendingIntent.FLAG_MUTABLE

val pi_flagmutable = PendingIntent.getService(
    this,
    0,
    intent_flag_mut,
    flag_mut
)
...

Redirection intent manipulation の問題が発生するのは、次の条件に一致した場合です。
1.エクスポートされたコンポーネントは、外部提供による Intent の Extras Bundle にネスト化された任意の Intent を受け入れます。

2.エクスポートされたコンポーネントは、startActivity、startService、または sendBroadcast を呼び出すことで、任意の Intent を使用してコンポーネントを起動します。

攻撃者は、これらの条件が存在する場合、本来は許可されなかったはずの権限を取得できる可能性があります。
例 1: 次のコードでは、外部ソースからのネスト化された Intent を受け入れ、その Intent を使用してアクティビティを開始しています。

...
Intent nextIntent = (Intent) getIntent().getParcelableExtra("next-intent");
startActivity(nextIntent);
...

J2EE 標準でリソースへの接続を確立するためには、コンテナのリソース管理機能をアプリケーションが使用する必要があります。

たとえば、J2EE アプリケーションは次のようにデータベース接続を取得します。

ctx = new InitialContext();
datasource = (DataSource)ctx.lookup(DB_DATASRC_REF);
conn = datasource.getConnection();

また、次のような方法での接続の取得は避けてください。

conn = DriverManager.getConnection(CONNECT_STRING);

主要な Web アプリケーションコンテナでは、リソース管理フレームワークの一部として、データベース接続管理が提供されています。アプリケーションにおいてこの機能を複製することは難しく、エラーが発生しやすくなるため、J2EE 標準で禁止されている理由の一つになっています。

セッションが開いている時間が長ければ、それだけ、ユーザーアカウントが侵害される機会が長くなります。セッションがアクティブになっていると、攻撃者は、ユーザーのパスワードに Brute-Force 攻撃を仕掛けたり、ユーザーのワイヤレス暗号鍵を解読したり、あるいは開いているブラウザからセッションを乗っ取ったりできるようになる可能性があります。また、セッションタイムアウトを長くしているとメモリが解放されず、大量のセッションが作成される場合に Denial of Service となる場合があります。

例 1: 次の例では、コードが最大非アクティブ間隔に負の値を設定しており、セッションが永続的にアクティブ状態になります。

...
HttpSession sesssion = request.getSession(true);
sesssion.setMaxInactiveInterval(-1);
...

Web アプリケーションでアプリケーションコンテナをシャットダウンすることは決していい方法ではありません。終了メソッドのコールは、おそらく Leftover Debug Code または非 J2EE アプリケーションからインポートされたコードの一部です。

一般的な開発方法では、アプリケーションで配布または実装されることのないデバッグまたはテスト用の「裏口」コードを追加します。この種のデバッグコードが誤ってアプリケーションに残された場合、アプリケーションは意図しない相互作用に対して開放されていることになります。これらの裏口エントリポイントは、設計やテスト中に想定されるアプリケーションの操作状況で考慮されていないため、セキュリティリスクを発生させることになります。

忘れられているデバッグコードで最も一般的な例が、Web アプリケーションに表示される main() メソッドです。これは製品開発中に認められる方法ですが、製品版 J2EE アプリケーションの一部であるクラスは main() を定義しません。

J2EE アプリケーションはアプリケーションの信頼性と性能を向上させるために複数の JVM を使用します。複数の JVM を単一アプリケーションとしてエンドユーザーに見せるため、J2EE コンテナは HttpSession オブジェクトを複数の JVM にわたって複製します。こうすることで、1 つの JVM が利用できなくなった場合でも、アプリケーションを中断させることなく別の JVM が取って代わることができます。

セッションが作業を複製するために、セッションの属性としてアプリケーションが保存する値は Serializable インターフェイスを実装しなければなりません。

例 1: 以下のクラスはセッションに追加されますが、シリアライズ可能なクラスではないため、セッションを複製できなくなります。

public class DataGlob {
   String globName;
   String globValue;

   public void addToSession(HttpSession session) {
     session.setAttribute("glob", this);
   }
}

J2EE 標準は、より上位のプロトコルを利用できない場合、レガシシステムでの通信目的にのみ Use of Sockets を許可します。自身の通信プロトコルを認証するには、以下を含めて難しいセキュリティ上の課題に取り組む必要があります。

- 帯域内信号と帯域外信号

- プロトコルのバージョン間の互換性

- チャネルのセキュリティ

- エラーの取り扱い

- ネットワークの制約 (ファイアウォール)

- セッション管理

セキュリティ専門家による十分な監視が行わなければ、カスタム通信プロトコルはセキュリティ問題に悩まされる可能性が高くなります。

同様の多くの問題が標準プロトコルのカスタム実装に当てはまります。標準プロトコルの実装に関連したセキュリティ問題に取り組む多くのリソースがありますが、これらのリソースは攻撃者も利用できます。

Web アプリケーションのスレッド管理は J2EE 標準によって禁止されており、エラーが発生する可能性が常に高くなります。スレッドの管理は難しく、アプリケーションコンテナの動作に予測不能な方法で干渉する可能性が高いと言えます。コンテナに干渉しなくとも、スレッド管理は通常、デッドロック、Race Condition、その他の同期エラーなど、検出や診断が難しいバグにつながります。

ほとんどの Web アプリケーションは、セッション ID を使用してユーザーを一意に識別します。これは通常 cookie に保存され、サーバーと Web ブラウザー間で透過的に送信されます。


セッション ID を cookie に保存しないアプリケーションは、HTTP リクエスト パラメーターとして、または URL の一部としてセッション ID を送信することがあります。URL で指定されたセッション ID を受け入れると、攻撃者はセッション ID 固定化攻撃を実行しやすくなります。

URL にセッション ID を含めると、アプリケーションに対するセッション ハイジャック攻撃の成功率も高くなります。セッション ハイジャック攻撃は、攻撃者が被害者のアクティブなセッションまたはセッション ID を制御すると発生します。Web サーバー、アプリケーション サーバー、および Web プロキシが要求された URL を保存するのは一般的な動作です。セッション ID が URL に含まれている場合、それらはログにも記録されます。セッション ID が表示および保存される場所が増えると、攻撃者に侵害される可能性も高くなります。

Tomcat を使用して認証を実行している場合、Tomcat 配置ディスクリプタファイルで、認証に使用される「レルム (Realm)」が指定されます。次のようになります。

例 1:

  <Realm className="org.apache.catalina.realm.JAASRealm"
         appName="SRN"
         userClassNames="com.srn.security.UserPrincipal"
         roleClassNames="com.srn.security.RolePrincipal"/>

この Realm タグでは、ログレベルを示す debug と呼ばれる属性をオプションで使用できます。数字が大きいほど、ログメッセージが詳細になります。デバッグレベルに非常に高い数字が設定されると、Tomcat ではログファイルにすべてのユーザー名とパスワードが平文で書き込まれます。Tomcat の JAASRealm に関連するデバッグメッセージの境界は 3 (3 以上は不適切、2 以下は適切) ですが、Tomcat で提供される他の種類のレルムでは、この境界が異なることがあります。

Struts や Spring などの Web フレームワークを使用して構築されたアプリケーションで Java Server Pages (JSP) に直接アクセスし、アクションまたはサーブレットを使用してリクエストを JSP に委任すると、未処理の例外やシステム情報の漏洩が発生する可能性があります。実装や設定が不十分なアプリケーション サーバーは、http://host/page.jsp%00 や http://host/page.js%2570 などの特別に細工されたリクエストを介して、ソース コードの詳細情報の漏洩に利用されてきました。さらに悪いことに、ユーザーによる任意のファイルのアップロードをアプリケーションが許可していると、攻撃者はこのメカニズムを使用して悪意のあるコードを JSP の形式でアップロードし、アップロードされたページに、悪意のあるコードをサーバー上で実行するように要求する可能性があります。

例 1: 次の例は、ロール名に "*" を含む JSP への直接アクセスを明示的に許可する、不十分な構成のセキュリティ制約を示しています。これは、対応する Web リソースへのアクセスをすべてのユーザーに許可することを示しています。

<security-constraint>
    <web-resource-collection>
        <web-resource-name>JSP Access for Everyone!</web-resource-name>
        <description>Allow any user/role access to JSP</description>
        <url-pattern>*.jsp</url-pattern>
    </web-resource-collection>
    <auth-constraint>
        <role-name>*</role-name>
    </auth-constraint>
</security-constraint>

セキュリティ ロールの重複には意味がありません。特定のセキュリティ ロールの最後の定義のみが適用されるためです。
例 1:web.xml ファイルのエントリは、2 つの admin ロールを定義します。

<security-constraint>
    <web-resource-collection>
        <web-resource-name>AdminPage</web-resource-name>
        <description>Admin only pages</description>
        <url-pattern>/auth/noaccess/*</url-pattern>
    </web-resource-collection>
    <auth-constraint>
        <description>Administrators only</description>
        <role-name>admin</role-name>
    </auth-constraint>
</security-constraint>
...
<security-role>
    <description>Administrator</description>
    <role-name>admin</role-name>
</security-role>

<security-role>
    <description>Non-Administrator</description>
    <role-name>admin</role-name>
</security-role>

サーブレット マッピングの重複には意味がありません。複数のサーブレット マッピングで同じ URL パターンが使用されていても、最後のエントリのみが適用されるためです。

例 1: 次の例では、2 つの異なるサーブレット マッピングで、URL パターン /servletA/* が使用されます。

<servlet-mapping>
    <servlet-name>ServletA</servlet-name>
    <url-pattern>/servletA/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
    <servlet-name>ServletB</servlet-name>
    <url-pattern>/servletA/*</url-pattern>
</servlet-mapping>

単一のサーブレットにマップされている複数の URL パターンは、サーブレットが実行する機能が多すぎることを示している場合があります。

例 1: 次の例では、5 つの URL パターンが 1 つのサーブレットにマップされています。

<servlet>
    <servlet-class>com.class.MyServlet</servlet-class>
    <load-on-startup>1</load-on-startup>
</servlet>

<servlet-mapping>
    <servlet-name>MyServlet</servlet-name>
    <url-pattern>/myservlet</url-pattern>
</servlet-mapping>

<servlet-mapping>
    <servlet-name>MyServlet</servlet-name>
    <url-pattern>/helloworld*</url-pattern>
</servlet-mapping>

<servlet-mapping>
    <servlet-name>MyServlet</servlet-name>
    <url-pattern>/servlet*</url-pattern>
</servlet-mapping>

<servlet-mapping>
    <servlet-name>MyServlet</servlet-name>
    <url-pattern>/mservlet*</url-pattern>
</servlet-mapping>

<servlet-mapping>
    <servlet-name>MyServlet</servlet-name>
    <url-pattern>/*</url-pattern>
</servlet-mapping>

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

例 1: セッション タイムアウトがゼロまたはゼロ未満の場合、セッションは期限切れになりません。次の例は、セッション タイムアウトが -1 に設定されていることを示しています。これにより、セッションは無期限でアクティブのままになります。

<session-config>
    <session-timeout>-1</session-timeout>
</session-config>

<session-timeout> タグは、Web アプリケーションのすべてのセッションを対象とした、デフォルトのセッション タイムアウト間隔を定義します。<session-timeout> タグがない場合、デフォルトのタイムアウトの設定はコンテナーに任されます。

攻撃者が Web サイトの脆弱性を探す場合、サイトが提供する情報の量が、攻撃の試みが最終的に成功するか失敗するかを左右します。アプリケーションが攻撃者にスタックト レースを表示すると、攻撃者の仕事を大幅に容易にする情報が漏れてしまいます。たとえば、スタックト レースは、無効な形式の SQL クエリ文字列、使用されているデータベースのタイプ、およびアプリケーション コンテナーのバージョンを攻撃者に見せてしまう可能性があります。こうした情報を利用することで、攻撃者は、これらのコンポーネントの既知の脆弱性を標的にすることができます。

アプリケーションが攻撃者にエラー メッセージを漏らさないようにするために、アプリケーション設定ではデフォルトのエラー ページを指定する必要があります。標準の HTTP エラー コードの処理は、優れたセキュリティ プラクティスであることに加えて、便利でユーザー フレンドリーです。また、適切な設定により、アプリケーションによってスローされる可能性のある例外をキャッチする、ラストチャンス エラー ハンドラーも定義されます。

アプリケーションが SSL を使用してクライアント ブラウザーとの機密通信を保証する場合、アプリケーション設定によって、SSL なしでアクセス制御されたページを表示できないようにする必要があります。

SSL がバイパスされる一般的な状況は 3 つあります。

- ユーザーが手動で URL を入力し、「HTTPS」ではなく「HTTP」と入力する。

- 攻撃者が意図的にユーザーを安全でない URL に送信する。

- プログラマがアプリケーション内のページへの相対リンクを誤って作成し、HTTP から HTTPS への切り替えに失敗する(これは、リンクが Web サイトのパブリック エリアとセキュリティで保護されたエリアの間を移動するときに、特に発生しがちです)。