ファイルの開示は、次のような状況で発生します。
1. 信頼できないソースからデータがプログラムに入り込んだ場合。


2. データがパスの動的な構築に使用された場合。

例 1: 次のコードは、信頼できないデータを受け取って、サーバーサイド転送で使用されるパスの構築にそのデータを使用しています。

...
	String returnURL = request.getParameter("returnURL");
	return new ModelAndView(returnURL);
	...

攻撃者が重要なファイルが保存されている場所と一致するリクエストパラメーターを付けた URL を指定すると、これらのファイルが表示されてしまいます。たとえば、"http://www.yourcorp.com/webApp/logic?returnURL=WEB-INF/applicationContext.xml" が指定されると、アプリケーションの applicationContext.xml が表示されます。
攻撃者が applicationContext.xml を入手してしまうと、applicationContext.xml で参照されている他の設定ファイルや、クラスや jar ファイルも検索され、ダウンロードされる場合があります。この攻撃によって、アプリケーションに関する重要な情報が盗み出され、他の攻撃に悪用される恐れがあります。

Spring Webflow では、ビュー リゾルバーを使用してビュー名を実際のレンダリング テクノロジーに変換します。通常、ビュー リゾルバーは、プレフィックスとサフィックスを使用してファイルのタイプと場所を制限します。しかし、リクエスト パラメーターを使用してビュー名を指定すると、このメカニズムを回避できます。
例 1: 次の Spring Webflow 設定では、リクエスト パラメーターを使用してビュー名を指定します。

<webflow:end-state id="finalStep" view="${requestParameters.url}"/>
<webflow:view-state id="showView" view="${requestParameters.test}">

デフォルトの Spring Webflow ビュー リゾルバーは、「/WEB-INF/views/」内の jsp ファイルのみを解決できるようにすることを目的としています。

<bean class="org.springframework.web.servlet.view.
               InternalResourceViewResolver">
    <property name="prefix" value="/WEB-INF/views/" />
    <property name="suffix" value=".jsp" />
</bean>

攻撃者が次の URL を使用して applicationContext.xml ファイルを表示する可能性があります。"http://www.yourcorp.com/webApp/logic?url=../applicationContext.xml;x="
InternalResourceViewResolver は、設定されているプレフィックスを取得し、ビュー属性で渡された値を連結し、最後にサフィックスを追加します。
結果の相対 URL "/WEB-INF/views/../applicationContext.xml;x=.jsp" がサーバー側のリクエスト ディスパッチャーに渡されます。セミコロンを使用すると、攻撃者は .jsp サフィックスをパス パラメーターに変換できます。この攻撃は、Web アプリのルートの下にあるファイルを開示するために使用される可能性があります。

ファイルの開示は、次のような状況で発生します。
1. 信頼できないソースからデータがプログラムに入り込んだ場合。


2. データがパスの動的な構築に使用された場合。

例 1: 次のコードは、信頼できないデータを受け取って、サーバーサイド転送で使用されるパスの構築にそのデータを使用しています。

...
	String returnURL = request.getParameter("returnURL");
	return new ActionForward(returnURL);
	...

攻撃者が重要なファイルが保存されている場所と一致するリクエストパラメーターを付けた URL を指定すると、これらのファイルが表示されてしまいます。たとえば、「http://www.yourcorp.com/webApp/logic?returnURL=WEB-INF/applicationContext.xml」が指定されると、アプリケーションの applicationContext.xml が表示されます。
攻撃者が applicationContext.xml を入手してしまうと、applicationContext.xml で参照されている他の設定ファイルや、クラスや jar ファイルも検索され、ダウンロードされる場合があります。この攻撃によって、アプリケーションに関する重要な情報が盗み出され、他の攻撃に悪用される恐れがあります。

パスワードや暗号鍵のような機密性の高いデータが、メモリから削除されないために攻撃者の目に触れる可能性がある場合に Heap Inspection の脆弱性が発生します。

realloc() 関数は、割り当てられたメモリのブロックサイズを増やす際によく使用されます。この操作は多くの場合、古いメモリブロックの内容を新しい大きなブロックにコピーする操作を必要とします。この操作は、元のブロックの内容をそのまま保持してプログラムからアクセスできないようにするため、プログラムは機密性が高いデータをメモリから消し去ることができません。攻撃者が後でメモリダンプの内容をチェックできる場合、機密性が高いデータが攻撃者の目に触れる可能性があります。

例: 次のコードは、機密性の高いデータがあるバッファで realloc() をコールしています。

plaintext_buffer = get_secret();
...
plaintext_buffer = realloc(plaintext_buffer, 1024);
...
scrub_memory(plaintext_buffer, 1024);

機密性が高いデータをメモリから消去しようと試みられていますが、realloc() が使用されているため、最初に plaintext_buffer に割り当てられたメモリにデータのコピーが残り、人目に触れる危険があります。

パスワードや暗号鍵のような機密性の高いデータが、メモリから削除されないために攻撃者の目に触れる可能性がある場合に Heap Inspection の脆弱性が発生します。

VirtualLock 関数は、メモリ内のページをロックしてディスクにページングされるのを防止するために使用されます。しかし、Windows 95/98/ME では、この関数はスタブとしてのみ実装されており効果がありません。

このクラスには、JCIP アノテーションパッケージのアノテーション Immutable が付けられています。しかし、このクラスの可変フィールドの 1 つには、コンストラクタおよびデストラクタの外側でコールされ変更されるメソッドが存在します。

例 1: 次の不変の final クラスのコードは、Set を private および final と宣言し、Set を変更するメソッドを誤って作成しています。

@Immutable
public final class ThreeStooges {
  private final Set stooges = new HashSet>();
  ...

  public void addStooge(String name) {
    stooges.add(name);
  }
  ...
}

このクラスには、JCIP アノテーション パッケージのアノテーション Immutable が付けられています。final 以外のフィールドは、値が変更されるのを許可するため、クラスの不変性が侵害されます。

例 1: 次の不変クラスのコードは、フィールドを final と宣言するのではなく、誤って public に宣言しています。

@Immutable
public class ImmutableInteger {
public int value;

}