다음과 같은 경우 파일 공개가 발생합니다.
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에서 view resolver는 보기 이름을 실제 렌더링 기술로 변환하는 데 사용됩니다. 일반적으로 view resolver는 접두사 및 접미사를 사용하여 파일의 유형 및 위치를 제한합니다. 그러나 요청 매개 변수를 사용하면 보기 이름이 이 메커니즘을 회피하도록 지정됩니다.
예제 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" 접미사를 경로 매개 변수로 변환할 수 있습니다. 이 공격은 웹 응용 프로그램 루트 아래 임의의 파일을 공개하는 데 사용될 수 있습니다.

다음과 같은 경우 파일 공개가 발생합니다.
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에서 이 함수는 스텁(stub)으로 구현되며 아무런 영향을 끼치지 않습니다.

이 클래스는 JCIP 주석 패키지의 Immutable 주석으로 주석 추가되었습니다. 그러나 클래스의 변경 가능한 필드 중 하나는 구성자 및 소멸자 외부에서 변화하는 메서드를 호출했습니다.

예제 1: Immutable 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: Immutable 클래스에 대한 다음 코드는 실수로 필드를 final이 아닌 public으로 선언합니다.

@Immutable
public class ImmutableInteger {
public int value;

}