J2EE 표준은 더 높은 수준의 프로토콜을 사용할 수 없을 때 레거시 시스템과의 통신을 위해서만 Use of Sockets를 허용합니다. 자체적으로 통신 프로토콜을 제작하려면 다음과 같은 어려운 보안 문제와 씨름해야 합니다.

- 대역 내 및 대역 외 시그널(signal) 처리

- 프로토콜 버전 간 호환성

- 채널 보안

- 오류 처리

- 네트워크 제약 조건(방화벽)

- 세션 관리

사용자 지정 통신 프로토콜은 보안 전문가의 정밀 검사 없이는 보안 문제가 발생할 가능성이 큽니다.

표준 프로토콜의 사용자 지정 구현도 마찬가지로 수많은 동일한 이슈가 적용됩니다. 일반적으로 표준 프로토콜 구현 관련 보안 문제를 다루는 데 사용 가능한 리소스가 많지만 이들 리소스는 공격자도 사용할 수 있습니다.

J2EE 표준은 일부 경우에 웹 응용 프로그램의 스레드 관리를 금지하는데 스레드 관리는 항상 오류 발생 가능성이 높습니다. 스레드 관리는 어려운 작업이고 예상치 못한 방식으로 응용 프로그램 컨테이너의 동작을 방해할 가능성이 큽니다. 컨테이너를 방해하지 않는 경우에도, 스레드 관리는 보통 발견하기 어렵고 교착 상태, 경쟁 조건(race condition), 및 기타 동기화 오류 등으로 진단되는 버그를 일으킵니다.

대부분의 웹 응용 프로그램은 일반적으로 쿠키에 저장되고 서버와 웹 브라우저 사이에서 투명하게 전송되는 세션 ID를 사용하여 사용자를 고유하게 식별합니다.


쿠키에 세션 ID를 저장하지 않은 응용 프로그램은 때때로 HTTP 요청 매개변수 또는 URL의 일부로서 세션 ID를 전송합니다. URL에 지정된 세션 ID를 수락하면 공격자가 Session Fixation 공격을 손쉽게 수행할 수 있습니다.

세션 ID를 URL에 배치하면 응용 프로그램에 대한 세션 하이재킹(Session Hijacking) 공격이 성공할 가능성도 높아집니다. 세션 하이재킹(Session Hijacking)은 공격자가 피해자의 활성 세션 또는 세션 ID 제어권을 가져갈 때 발생합니다. 일반적으로 웹 서버, 응용 프로그램 서버 및 웹 프록시는 요청된 URL을 저장합니다. 세션 ID가 URL에 포함되면 ID가 기록됩니다. 세션 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이 제공하는 다른 유형의 영역(realm)에 따라 변할 수 있습니다.

작업 또는 서블릿을 사용하여 JSP(Java Server Page)에 요청을 위임하는 웹 프레임워크로 구축된 Struts 또는 Spring과 같은 응용 프로그램에서 JSP에 직접 액세스하면 처리되지 않은 예외 및 시스템 정보 누출이 발생할 수 있습니다. 불완전하게 구현되거나 구성된 응용 프로그램 서버는 http://host/page.jsp%00 또는 http://host/page.js%2570과 같이 특수하게 고안된 요청을 사용하여 소스 코드 세부 정보를 유출하는 데 악용되어 왔습니다. 더 심한 경우, 응용 프로그램에서 사용자가 임의의 파일을 업로드하도록 허용할 경우, 공격자는 이 메커니즘을 사용하여 JSP의 형태로 악성 코드를 업로드하고 업로드한 페이지에서 악성 코드가 서버에서 실행되도록 요청할 수 있습니다.

예제 1: 다음 예제는 잘못 구성된 보안 제약 조건을 보여줍니다. 이 보안 제약 조건은 해당하는 웹 리소스에 모든 사용자가 액세스하는 것을 허용함을 나타내는 ‘*’를 사용하여 역할 이름에 JSP에 대한 직접 액세스를 명시적으로 허용합니다.

<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: 다음 예제에서 /servletA/* URL 패턴은 2개의 서로 다른 서블릿 매핑에 사용됩니다.

<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 패턴을 단일 서블릿에 매핑합니다.

<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: 세션 시간 초과가 0 또는 0 미만일 경우, 세션은 만료되지 않습니다. 다음 예는 -1로 설정된 세션 시간 초과를 보여주며 이로 인해 세션은 무기한으로 활성화 상태가 됩니다.

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

<session-timeout> 태그는 웹 응용 프로그램의 모든 세션에 대해 기본 세션 시간 초과 간격을 정의합니다. <session-timeout> 태그가 누락된 경우, 기본 시간 초과를 설정하도록 컨테이너에 맡겨집니다.

공격자가 웹 사이트에서 취약점을 찾기 위해 탐색할 때 사이트가 제공하는 정보의 양이 공격 시도의 성패를 결정짓는 핵심 요소입니다. 응용 프로그램이 공격자에게 스택 추적을 보여주면 공격자의 공격을 아주 쉽게 만드는 정보를 제공하는 셈이 됩니다. 예를 들어, 스택 추적은 공격자에게 잘못된 SQL 쿼리 문자열, 사용 중인 데이터베이스 유형 및 응용 프로그램 컨테이너 버전을 보여줄 수 있습니다. 공격자는 이 정보를 사용하여 이 구성 요소의 알려진 취약점을 공략합니다.

응용 프로그램 구성은 응용 프로그램이 오류 메시지를 공격자에게 누출하지 않는다는 것을 보장하기 위해 기본 오류 페이지를 지정해야 합니다. 표준 HTTP 오류 코드를 처리하는 것은 바람직한 보안 관행일 뿐만 아니라 유용하고 사용자 친화적입니다. 또한 응용 프로그램에서 발생할 수 있는 예외를 포착하는 마지막 오류 처리기도 정의해야 좋은 구성이라고 할 수 있습니다.

응용 프로그램에서 SSL을 사용하여 클라이언트 브라우저와의 기밀 통신을 보장하는 경우 이 응용 프로그램 구성은 SSL 없이는 Access Control 페이지를 볼 수 없도록 해야 합니다.

SSL을 우회하는 일반적인 방법에는 3가지가 있습니다.

- 사용자가 수동으로 URL을 입력하고 "HTTPS"가 아닌 "HTTP"를 입력합니다.

- 공격자가 의도적으로 사용자를 안전하지 않은 URL로 보냅니다.

프로그래머가 실수로 응용 프로그램의 페이지의 상대 링크를 만들어 HTTP에서 HTTPS로 전환하지 못합니다. (이는 특히 링크가 웹 사이트의 공개 영역과 보안 영역 사이를 이동할 때 발생되기 쉽습니다.)

WebLogic 배포 설명자는 최소 24바이트 길이의 세션 ID를 지정해야 합니다. 이보다 짧은 세션 ID를 사용하면 응용 프로그램이 무차별 대입 공격에 취약해집니다. 공격자가 인증된 사용자의 세션 ID를 알아내면 사용자의 세션을 가로챌 수 있습니다. 이 글의 나머지 부분에서는 24바이트 세션 ID가 필요한 이유를 자세히 설명합니다.

세션 ID는 62개 영숫자의 의사 난수 선택으로 구성되어 있습니다. 이는 문자열이 실질적으로 무작위 방식으로 구성되었을 경우, 각 바이트는 최대 6비트의 엔트로피를 만들 수 있음을 의미합니다.

올바른 세션 ID를 추측하는 데 필요한 예상 시간(초)은 다음 식으로 구할 수 있습니다.

(2^B+1) / (2*A*S)

관련 설명:

- B는 세션 ID의 엔트로피의 비트 수입니다.

- A는 공격자가 1초에 시도할 수 있는 추측의 횟수입니다.

- S는 임의의 시간에 추측할 수 있는 유효한 세션 ID의 개수입니다.

세션 ID의 엔트로피의 비트 수는 항상 세션 ID의 총 비트 수보다 작습니다. 예를 들어, 세션 ID가 오름차순이라면 ID의 길이에 관계없이 세션 ID 엔트로피 비트 수가 0에 가까울 것입니다. 우수한 난수 발생기를 사용하여 세션 ID를 생성한다고 가정하면 세션 ID의 엔트로피의 비트 수는 세션 ID의 총 비트 수의 절반이 됩니다. 실제 ID 길이의 경우, 이것이 가능하지만 낙관적인 감이 있습니다.

공격자가 수백 또는 수천 대의 무인 컴퓨터를 가지고 봇네트(botnet)를 사용한다면 초당 수만 개의 추측을 시도한다고 가정하는 것이 타당합니다. 해당 웹 사이트가 대형 인기있는 웹 사이트라면 한동안 대량 무차별 대입을 발견하지 못할 수 있습니다.

추측할 수 있는 유효한 세션 ID 수의 하한(lower bound)은 임의의 순간에 사이트를 사용하고 있는 사용자 수입니다. 하지만 로그아웃하지 않고 세션을 떠난 사용자 때문에 이 수가 늘어납니다. (이는 비활성 세션 제한 시간을 짧게 하는 이유 중 하나입니다.)

64비트 세션 ID의 경우 32비트 엔트로피를 가정합니다. 대형 웹 사이트의 경우, 공격자가 초당 1,000번의 추측을 시도할 수 있고 임의의 순간에 10,000개의 유효한 세션 ID가 있다고 가정합니다. 이렇게 가정하면, 공격자가 유효한 세션 ID를 알아내는 데 성공하기 위한 예상 시간은 4분 미만입니다.

이번에는 128비트 세션 ID에서 64비트 엔트로피를 제공한다고 가정합니다. 초대형 웹 사이트에서 공격자는 초당 10,000번의 추측을 시도할 수 있고 추측할 수 있는 유효한 세션 ID는 100,000개입니다. 이렇게 가정하면, 공격자가 유효한 세션 ID를 알아내는 데 성공하는 예상 시간은 292년이 넘습니다.

비트에서 바이트로 역방향 작업을 하는 세션 ID는 128/6이어야 합니다. 이는 약 21바이트를 생성합니다. 그뿐만 아니라, 경험 상, 테스트를 해 보면 세션 ID의 첫 3바이트가 무작위로 생성되지 않음을 보여줍니다. 이는 원하는 64비트 엔트로피를 얻으려면 세션 ID 24바이트 길이를 사용하도록 WebLogic을 구성해야 함을 의미합니다.

web.xml에서 누락되거나 중복된 서블릿 이름은 오류입니다. 모든 서블릿에는 고유한 이름(servlet-name)과 해당하는 매핑(servlet-mapping)이 있어야 합니다.

예제 1:web.xml의 다음 항목은 몇 가지 잘못된 서블릿 정의를 보여줍니다.

<!-- No <servlet-name> specified: -->
    <servlet>
        <servlet-class>com.class.MyServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>

<!-- Empty <servlet-name> node: -->
    <servlet>
        <servlet-name/>
        <servlet-class>com.class.MyServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>

<!-- Duplicate <servlet-name> nodes: -->
    <servlet>
        <servlet-name>MyServlet</servlet-name>
        <servlet-name>Servlet</servlet-name>
        <servlet-class>com.class.MyServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>

이러한 오류는 의도하지 않은 서블릿 액세스 거부를 유발할 수 있습니다.

<login-config> 요소는 사용자가 응용 프로그램에 인증하는 방법을 구성하는 데 사용됩니다. 인증 방법이 없으면 누구도 로그인할 수 없으므로 응용 프로그램에서 권한 부여 제약 조건을 적용하는 방법을 알지 못합니다. 인증 방법은 <login-config>의 하위 항목인 <auth-method> 태그를 사용하여 지정됩니다.

인증 방법에는 4가지가 있습니다. 즉, BASIC, FORM, DIGEST 및 CLIENT_CERT입니다.

BASIC은 HTTP 기본 인증을 나타냅니다.
FORM은 양식 기반 인증을 나타냅니다.
DIGEST는 기본 인증과 같습니다. 그러나 DIGEST에서는 암호가 암호화됩니다.
CLIENT_CERT는 클라이언트에 공개 키 인증서가 있어야 하고 SSL/TLS를 사용할 것을 요구합니다.

예제 1: 다음 구성은 로그인 구성을 지정하지 않습니다.

<web-app>

    <!-- servlet declarations -->
    <servlet>...</servlet>

    <!-- servlet mappings-->
    <servlet-mapping>...</servlet-mapping>

    <!-- security-constraints-->
    <security-constraint>...</security-constraint>

    <!-- login-config goes here -->

    <!-- security-roles -->
    <security-role>...</security-role>

</web-app>

web.xml 보안 제약 조건은 일반적으로 RBAC(Role-Based Access Control)에 사용되지만 선택적 user-data-constraint 요소로 콘텐트의 안전하지 않은 전송을 차단하는 전송 보증을 지정할 수 있습니다.

<user-data-constraint> 태그 안에서 <transport-guarantee> 태그는 통신의 처리 방법을 정의합니다. 전송 보증에는 3가지 수준이 있습니다.

1) NONE은 응용 프로그램에서 전송 보증을 요구하지 않음을 의미합니다.
2) INTEGRAL은 응용 프로그램에서 클라이언트와 서버 간에 전송되는 데이터를 전송 중에 변경할 수 없는 방식으로 전송할 것을 요구함을 의미합니다.
3) CONFIDENTIAL은 응용 프로그램에서 다른 엔티티가 전송 내용을 관찰할 수 없는 방식으로 데이터를 전송할 것을 요구함을 의미합니다.



대부분의 상황에서 INTEGRAL 또는 CONFIDENTIAL의 사용은 SSL/TLS가 필요함을 의미합니다. <user-data-constraint> 및 <transport-guarantee> 태그가 생략된 경우 전송 보증은 기본적으로 NONE으로 설정됩니다.

예제 1: 다음 보안 제약 조건은 전송 보증을 지정하지 않습니다.

<security-constraint>
    <web-resource-collection>
        <web-resource-name>Storefront</web-resource-name>
        <description>Allow Customers and Employees access to online store front</description>
        <url-pattern>/store/shop/*</url-pattern>
    </web-resource-collection>
    <auth-constraint>
        <description>Anyone</description>
        <role-name>anyone</role-name>
    </auth-constraint>
</security-constraint>

공격자가 웹 사이트에서 취약점을 찾기 위해 탐색할 때 사이트가 제공하는 정보의 양이 공격 시도의 성패를 결정짓는 핵심 요소입니다. 응용 프로그램이 공격자에게 스택 추적을 보여주면 공격자의 공격을 아주 쉽게 만드는 정보를 제공하는 셈이 됩니다. 예를 들어, 스택 추적은 공격자에게 잘못된 SQL 쿼리 문자열, 사용 중인 데이터베이스 유형 및 응용 프로그램 컨테이너 버전을 보여줄 수 있습니다. 공격자는 이 정보를 사용하여 이 구성 요소의 알려진 취약점을 공략합니다.

응용 프로그램 구성은 응용 프로그램이 오류 메시지를 공격자에게 누출하지 않는다는 것을 보장하기 위해 기본 오류 페이지를 지정해야 합니다. 표준 HTTP 오류 코드를 처리하는 것은 바람직한 보안 관행일 뿐만 아니라 유용하고 사용자 친화적입니다. 또한 응용 프로그램에서 발생할 수 있는 예외를 포착하는 마지막 오류 처리기도 정의해야 좋은 구성이라고 할 수 있습니다.

모든 필터 매핑은 유효한 필터 정의와 일치해야 적용됩니다.

예제 1: 다음 예제는 존재하지 않는 필터인 AuthenticationFilter를 참조하는 필터 매핑을 보여줍니다. 정의가 누락되었기 때문에 AuthenticationFilter 필터는 지정된 URL 패턴 /secure/*에 적용되지 않으며 런타임 예외를 야기할 수 있습니다.

<filter>
    <description>Compresses images to 64x64</description>
    <filter-name>ImageFilter</filter-name>
    <filter-class>com.ImageFilter</filter-class>
</filter>

<!-- AuthenticationFilter is not defined -->
<filter-mapping>
    <filter-name>AuthenticationFilter</filter-name>
    <url-pattern>/secure/*</url-pattern>
</filter-mapping>

<filter-mapping>
    <filter-name>ImageFilter</filter-name>
    <servlet-name>ImageServlet</servlet-name>
</filter-mapping>

auth-constraint에 정의된 role-name에 대한 security-role이 없으면 구성이 오래된 것일 수 있습니다.

예제 1: 다음 예제는 role-name을 지정하지만 security-role에서 역할 이름을 정의하지 않습니다.

<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>

    <user-data-constraint>
        <transport-guarantee>INTEGRAL</transport-guarantee>
    </user-data-constraint>
</security-constraint>

유효한 서블릿 매핑이 없으면 매핑되지 않은 서블릿에 대한 모든 액세스가 차단됩니다.

예제 1:web.xml의 다음 항목은 ExampleServlet을 정의하지만 해당하는 서블릿 매핑을 정의하지 않습니다.

<web-app
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
    version="2.4">

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

</web-app>

원격 인터페이스를 노출하는 엔터티 빈은 응용 프로그램의 공격 접점의 일부가 됩니다. 성능상의 이유로 응용 프로그램이 원격 엔터티 빈을 사용하는 경우가 아주 드물기 때문에 원격 엔터티 빈 선언이 오류가 될 가능성이 큽니다.

예제 1: 다음 엔터티 빈 선언에는 원격 인터페이스가 포함됩니다.

<ejb-jar>
<enterprise-beans>
<entity>
<ejb-name>EmployeeRecord</ejb-name>
<home>com.wombat.empl.EmployeeRecordHome</home>
<remote>com.wombat.empl.EmployeeRecord</remote>
...
</entity>
...
</enterprise-beans>
</ejb-jar>