Servlet 3.0 스펙에 기인한 보안 논쟁
서블릿 API에 근간한 대부분의 자바 웹 어플리케이션 프레임웍은 web.xml파일에 하나 이상의 서블릿, 필터, 리스너 등 웹 어플리케이션에 관계한 설정을 기술해야만 합니다. 의존관계에 있는 WEB-INF/lib 디렉토리의 jar들도 포함해서 말이죠.
EE6의 한 부분을 구성하는 Servlet 3.0 스펙인 JSR-315은 이것을 바꿀 방법을 모색하고 있습니다. 서블릿 3.0 스펙은 현재 Public Review 상태이면 그 내용은 아래 링크에서 확인하실 수 있습니다.
JSR-000315 JavaTM Servlet 3.0 Specification
서블릿 3.0 스펙에는 무설정(Zero Configuration) 지향과 이식성(Plugability) 향상을 목표로 다음과 같은 새로운 기능이 추가됩니다.
1. annotation의 추가 : 서블릿 3.0 스펙에는 서블릿의 url-mapping 정보를 제공하기위한 @Servlet과 같은 수 개의 새로운 어노테이션(@ServletFilter, @FilterMapping 등)이 추가됩니다.
2. web.xml의 분할(fragments) 설정 지원 : 서블릿 정의, 필터 혹은 리스너 등을 각각 지정한 설정 파일을 web.xml에 merge하는 방식을 채택해 개개의 웹 프레임워크 jar 파일들의 각자 고유한 설정을 가질 수 있도록 하였습니다.
Flag(metadata-complete)는 annotation과 fragment 모두의 스캐닝을 제어하는데 이용됩니다.
위와 같은 사양 추가로 인해 원치않는 서블릿이나 필터들의 배포로 야기될 수 있는 보안 위협에 Expert Group내에서도 적지않은 논쟁을 펼치고 있습니다. 물론, 그런 보안 위협은 제거할 수 있을만큼 충분히 유연하다는 의견도 만만치 않구요.
이에 대한 Expert Group의 잠정적인 결론은 커뮤니티의 피드백을 받아보자는 쪽인것 같습니다.
Greg Wilkins는 Automatic Scanning 과 분할된 설정파일의 merge를 예로든 그의 글을 통해 <include>라는 옵셔널 엘리먼트를 추가하는 방식을 제안했습니다.
다른 두 가지 가능성에 대해 올해 Java One Conference에서 Expert Group 사이에서 논의가 있었습니다.
한 가지 방법은 web fragments와 annotations의 스캐닝 여부를 활성화(enable/disable)하는 두 번째 flag를
metadata-complete에 추가하는 방법이 있겠습니다.
Rajiv Mordani의 요지는 어노테이션 메카니즘은 이미 web.xml 파일의 설정을 상속받을 수 있도록 구현 되었기
때문에, 이런 방법을 통해서도 원하는 수준의 제어가 가능하다는 것입니다.
마지막 방법은 아래와 유사한 방식으로 서블릿과 필터를 무효화하는 메카니즘을 web.xml에 기술하자는것
해당 이슈에 관심이 있거나 feedback을 원하는 분은 jsr-315-comments@jcp.org으로 의견을 보내실 수 있습니다.
EE6의 한 부분을 구성하는 Servlet 3.0 스펙인 JSR-315은 이것을 바꿀 방법을 모색하고 있습니다. 서블릿 3.0 스펙은 현재 Public Review 상태이면 그 내용은 아래 링크에서 확인하실 수 있습니다.
JSR-000315 JavaTM Servlet 3.0 Specification
서블릿 3.0 스펙에는 무설정(Zero Configuration) 지향과 이식성(Plugability) 향상을 목표로 다음과 같은 새로운 기능이 추가됩니다.
1. annotation의 추가 : 서블릿 3.0 스펙에는 서블릿의 url-mapping 정보를 제공하기위한 @Servlet과 같은 수 개의 새로운 어노테이션(@ServletFilter, @FilterMapping 등)이 추가됩니다.
2. web.xml의 분할(fragments) 설정 지원 : 서블릿 정의, 필터 혹은 리스너 등을 각각 지정한 설정 파일을 web.xml에 merge하는 방식을 채택해 개개의 웹 프레임워크 jar 파일들의 각자 고유한 설정을 가질 수 있도록 하였습니다.
Flag(metadata-complete)는 annotation과 fragment 모두의 스캐닝을 제어하는데 이용됩니다.
위와 같은 사양 추가로 인해 원치않는 서블릿이나 필터들의 배포로 야기될 수 있는 보안 위협에 Expert Group내에서도 적지않은 논쟁을 펼치고 있습니다. 물론, 그런 보안 위협은 제거할 수 있을만큼 충분히 유연하다는 의견도 만만치 않구요.
이에 대한 Expert Group의 잠정적인 결론은 커뮤니티의 피드백을 받아보자는 쪽인것 같습니다.
Greg Wilkins는 Automatic Scanning 과 분할된 설정파일의 merge를 예로든 그의 글을 통해 <include>라는 옵셔널 엘리먼트를 추가하는 방식을 제안했습니다.
"Without a web.xml or with a 3.0 web.xml that does not list any inclusions,Specification 리더중의 한 명인 Rajiv Mordani는 위와 같은 방법에 놀랍긴 해도 수긍할 순 없다고 하네요.
the default would be to search all of WEB-INF for annotated servlets and filters,
TLD listeners and web.xml fragments as currently proposed. If however,
a web.xml contained <include> element, then the discovery process would be
modified as the following examples illustrate:
<include src="WEB-INF/lib/dwr.jar"/>
<include src="WEB-INF/lib/cometd.jar"/>
<include src="WEB-INF/classes"/>
This include would scan only the dwr.jar and cometd.jar for annotations,
TLD fragments and web.xml fragments, the WEB-INF/classes directory would be scanned for
annotated servlets. No other jars or classes would be scanned unless listed in their
own include elsewhere in the web.xml."
"Greg Wilkins의 제안하는 방법은 의도하지 않은 서블릿과 필터들이 노출되는 것을 우려하는
곳에나 먹히는 매우 특별한 경우로 그것은 프레임워크 개발자의 문제이며 특정 컴포넌트를
노출하지 않기를 원하는 이용자의 문제는 아니라고 생각한다. 이런 경우라면 flag를 이용하여
jar의 집합으로부터 효율적으로 스캐닝을 컨트롤 할 수 있다."
다른 두 가지 가능성에 대해 올해 Java One Conference에서 Expert Group 사이에서 논의가 있었습니다.
한 가지 방법은 web fragments와 annotations의 스캐닝 여부를 활성화(enable/disable)하는 두 번째 flag를
metadata-complete에 추가하는 방법이 있겠습니다.
Rajiv Mordani의 요지는 어노테이션 메카니즘은 이미 web.xml 파일의 설정을 상속받을 수 있도록 구현 되었기
때문에, 이런 방법을 통해서도 원하는 수준의 제어가 가능하다는 것입니다.
"When you use annotations to declare servlets and Filters then you must have a url-mapping
/ FilterMapping attribute on the corresponding servlet / Filter.
In this way there is no convention by which a servlet is exposed without having an explicit mapping.
Also, as with the rest of the Java EE platform, specifically technologies like EJB and Web Services,
the deployment descriptor is used to override information that is specified via annotations....
If you didn't want any of the annotations to be processed at all by the container and wanted to specify
all the configuration via the deployment descriptor, then, like with the rest of the Java EE 5 platform,
we have the metadata-complete element in the descriptor. If the element is present and set to "true" then
the container will not process any annotations and just use the configuration specified in the descriptor.
This provides a way [to] disable the auto-scanning for those that have concerns about performance,
and security.”
마지막 방법은 아래와 유사한 방식으로 서블릿과 필터를 무효화하는 메카니즘을 web.xml에 기술하자는것
<servlet>등이 있습니다.
<servlet-name>FrameworkServlet</servlet-name>
<enabled>false</enabled>
</servlet>
해당 이슈에 관심이 있거나 feedback을 원하는 분은 jsr-315-comments@jcp.org으로 의견을 보내실 수 있습니다.
Trackback Address:이 글에는 트랙백을 보낼 수 없습니다
서블릿 3.0에서 서버 푸쉬를 지원한다고 하던데 요런 이슈도 있었군요~
건강 꼭 챙기시공 조만간 뵈용 ㅋㅋ