SV.EXPOSE.FIN
このエラーは、クラスが public finalize() メソッドを持つ場合に検出されます。
脆弱性とリスク
アプレットは Web ブラウザーがアプレットを含むページをリーブした後も存続できるため、アプレットを相互に保護することが重要になります。保護がない場合には、攻撃者のアプレットが第三者のアプレットを意図的に妨害することが可能になります。多くの環境では、アプレットが別のアプレットの存在を知ることさえ許可しないようにしています。Netscape Navigator 3.0 では、AppletContext.getApplets() は呼び出し元と同じ Web ページのアプレットへのハンドルのみを返します。しかし、アプレットはトップレベルの ThreadGroup へのハンドルを容易に取得できるため、別の任意のアプレットに属するスレッドを含め、システムで実行中のすべてのスレッドを列挙できます。Java ランタイムは、アプレットのクラス名をスレッド名の中に符号化するため、攻撃者のアプレットがシステムで実行中のすべてのアプレットの名前を知ることが可能になります。また、アプレットが stop() メソッドまたは setPriority() メソッドを別のアプレットのスレッド上で呼び出すことができます。SecurityManager は、アプレットがシステムスレッドの状態を変更できないことのみをチェックしていたため、アプレットが別のアプレットのスレッドを変更することについては制約がありませんでした。Netscape Navigator 4.0 では、アプレットの保護と同様の方法で、攻撃者が別の Web ページ上のアプレットに属するスレッドを見ることができないように保護しています。Internet Explorer では、アプレットは別の Web ページ上のアプレットに属するスレッドを見ることができますが、stop() や setPriority() の呼び出しは無効となります。この攻撃の悪質な形態の 1 つは、特定の被攻撃アプレットが存在するとき以外は休眠状態になる悪意あるアプレットを使用するものです。被攻撃アプレットが動作している場合、悪意あるアプレットはサービス攻撃を不規則に弱め、その代わりに被攻撃アプレットのスレッドを攻撃します。その結果、ユーザーには被攻撃アプレットの動作が遅く、動きがおかしいように見えます。攻撃者のアプレットは、セキュリティ脆弱性を利用して被攻撃アプレットの内部状態を変更できるため、メソッドおよびフィールドの可視性を可能な限り低く保ち、static フィールドを避けること、および可能な限り final を使用することが重要です。
Klocwork セキュリティ脆弱性 (SV) チェッカーは、潜在的に危険なデータを生成する呼び出しを特定します。このような呼び出しは安全でないソースと考えられます。ユーザーは攻撃者になる可能性があり、ヒューマンエラーを取り込む可能性があるため、安全でないソースはユーザーが指定した任意のデータである可能性があります。
軽減と防止
この脆弱性は、すべての finalize() メソッドを protected にすることにより緩和できます。
例 1
public void finalize() throws Throwable {
try {
close(); // close open files
} finally {
super.finalize();
}
}SV.EXPOSE.FIN が 10 行目に対して報告されています。finalize() メソッドは、public ではなく protected アクセス修飾子を使用する必要があります
