내부 Intent는 내부 구성 요소에서 정의한 대로 사용자 지정 작업을 사용합니다. 암시적 Intent는 특정 구성 요소에 대한 지식 없이도 임의의 외부 구성 요소에서 Intent 호출을 용이하게 할 수 있습니다. 이 두 가지를 결합하면 응용 프로그램이 원하는 응용 프로그램 컨텍스트 외부에서 특정 내부 사용을 위해 지정된 Intent에 액세스할 수 있습니다.

외부 응용 프로그램에서 내부 Intent를 처리하는 기능을 사용하면 심각도에 따라 Intent에 지정된 내부 작업의 용량에 따라 정보 유출 및 서비스 거부부터 원격 코드 실행까지 다양한 MiTM(Man-in-The-Middle) 공격이 가능해집니다.

예제 1: 다음 코드는 암시적 내부 Intent를 사용합니다.

...
val imp_internal_intent_action = Intent("INTERNAL_ACTION_HERE")
startActivity(imp_internal_intent_action)
...

Android Intent는 임의 구성 요소가 수행하는 작업에 대한 명령을 제공하여 응용 프로그램과 응용 프로그램 구성 요소를 함께 바인딩하는 데 사용됩니다. 나중에 Intent를 전달하기 위해 PendingIntent가 생성됩니다. 암시적 Intent는 일반 이름과 필터를 사용하여 실행을 결정함으로써 임의의 외부 구성 요소에서 Intent 호출을 용이하게 합니다.

암시적 Intent가 PendingIntent로 생성되는 경우 이로 인해 Intent가 의도한 임시 컨텍스트의 외부에서 실행되는 의도하지 않은 구성 요소로 전송되어 시스템이 서비스 거부, 개인 정보 및 시스템 정보 유출, 권한 에스컬레이션과 같은 악의적 공격에 취약해질 수 있습니다.

예제 1: 다음 코드는 암시적 PendingIntent를 사용합니다.

...
val imp_intent = Intent()
val flag_mut = PendingIntent.FLAG_MUTABLE
val pi_flagmutable_impintintent = PendingIntent.getService(
    this,
    0,
    imp_intent,
    flag_mut
)
...

PendingIntent의 기본 Intent 수정을 허용하면 생성 후 시스템이 공격에 노출될 수 있습니다. 이는 대개 기본 Intent의 전체적인 기능에 따라 달라집니다. 대부분의 경우 PendingIntent 플래그를 FLAG_IMMUTABLE로 설정하여 잠재적인 문제를 방지하는 것이 모범 사례에 해당합니다.

예제 1: 다음은 FLAG_MUTABLE 플래그 값으로 생성된 PendingIntent를 포함합니다.

...
val intent_flag_mut = Intent(Intent.ACTION_GTALK_SERVICE_DISCONNECTED, Uri.EMPTY, this, DownloadService::class.java)
val flag_mut = PendingIntent.FLAG_MUTABLE

val pi_flagmutable = PendingIntent.getService(
    this,
    0,
    intent_flag_mut,
    flag_mut
)
...

리디렉션 의도 조작 문제는 다음 조건이 충족될 때 발생합니다.
1. 내보낸 구성 요소가 외부 제공 Intent의 추가 번들에 중첩된 임의의 Intent를 수락합니다.

2. 내보낸 구성 요소가 startActivity, startService 또는 sendBroadcast를 호출하는 방법으로 임의의 Intent를 사용하여 구성 요소를 시작합니다.

이러한 조건이 있는 경우 공격자는 달리 허용되지 않는 능력을 확보할 수 있습니다.
예제 1: 다음 코드는 외부 소스의 중첩된 Intent를 수락하고 Intent를 사용하여 활동을 시작합니다.

...
Intent nextIntent = (Intent) getIntent().getParcelableExtra("next-intent");
startActivity(nextIntent);
...

J2EE 표준에 따르면 응용 프로그램이 컨테이너의 리소스 관리 기능을 사용하여 리소스 연결을 확보해야 합니다.

예를 들어, J2EE 응용 프로그램은 다음과 같이 데이터베이스에 연결해야 합니다.

ctx = new InitialContext();
datasource = (DataSource)ctx.lookup(DB_DATASRC_REF);
conn = datasource.getConnection();

또한 다음과 같은 방식으로 연결하는 것은 피해야 합니다.

conn = DriverManager.getConnection(CONNECT_STRING);

모든 주요 웹 응용 프로그램 컨테이너는 리소스 관리 프레임워크의 일부로 공용 데이터베이스 연결 관리 기능을 제공합니다. 응용 프로그램에 이 기능을 복제하는 것은 어려운 작업이고 오류가 발생하기 쉽기 때문에 J2EE 표준에서 금지합니다.

세션을 더 오래 열어둘수록, 공격자가 사용자 계정을 손상시킬 수 있는 기회는 더 커집니다. 세션이 활성화 상태라면 공격자는 사용자의 암호를 무차별 대입하거나 사용자의 무선 암호화 키를 불법으로 복제하거나 열려 있는 브라우저에서 세션을 제멋대로 쓸 수도 있습니다. 또한 세션 초과 시간이 더 길어지면 메모리가 해제되지 못하도록 하여 결국 충분히 많은 세션이 만들어지는 경우 denial of service가 발생됩니다.

예제 1: 다음 예제의 코드는 최대 비활성 간격을 음수 값으로 설정하여 세션이 무기한으로 활성 상태를 유지하도록 합니다.

...
HttpSession sesssion = request.getSession(true);
sesssion.setMaxInactiveInterval(-1);
...

웹 응용 프로그램을 통해 응용 프로그램 컨테이너를 종료하려 하는 것은 좋은 방법이 아닙니다. 종료 메서드 호출은 제거되지 않은 leftover debug code의 일부분이거나 Non-J2EE 응용 프로그램에서 가져온 코드일 것입니다.

일반적인 개발 방법은 응용 프로그램으로 발표하거나 배포하지는 않고 디버깅 및 테스트 목적으로만 특별 디자인된 "비밀" 코드를 추가하는 것입니다. 이 비밀 디버그 코드가 실수로 응용 프로그램에 남아 있게 되면 응용 프로그램은 예기치 않은 상호 작용 모드에 노출됩니다. 이 비밀 진입점은 디자인이나 테스트 도중 고려되지 않고 응용 프로그램의 예상 동작 조건 범위를 벗어나기 때문에 보안 위험을 야기합니다.

실수로 남겨둔 디버그 코드의 가장 일반적인 예는 main() 메서드가 웹 응용 프로그램에 나타나는 것입니다. 이는 제품 개발에서는 허용되는 방식이지만 J2EE 운영 응용 프로그램에 속한 클래스는 main()을 정의할 수 없습니다.

J2EE 응용 프로그램은 여러 JVM을 이용하여 응용 프로그램 안정성과 성능을 개선합니다. 최종 사용자에게 여러 JVM을 하나의 응용 프로그램으로 보이게 하기 위해, J2EE 컨테이너는 여러 JVM에 HttpSession 개체를 복제하여 한 JVM을 사용할 수 없게 되면 다른 JVM이 개입하여 역할을 대신하기 때문에 응용 프로그램의 흐름이 중단되지 않습니다.

세션 복제가 제대로 동작하려면 응용 프로그램이 세션에 속성으로 저장한 값이 Serializable 인터페이스를 구현해야 합니다.

예제 1: 다음 클래스는 자신을 세션에 추가하지만 serializable 상태가 아니므로 세션을 더 이상 복제할 수 없습니다.

public class DataGlob {
   String globName;
   String globValue;

   public void addToSession(HttpSession session) {
     session.setAttribute("glob", this);
   }
}

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로 전환하지 못합니다. (이는 특히 링크가 웹 사이트의 공개 영역과 보안 영역 사이를 이동할 때 발생되기 쉽습니다.)