RoamingFolder 및 RoamingSettings 속성은 로밍 응용 프로그램 데이터 저장소에서 컨테이너를 가져옵니다. 이 컨테이너는 2개 이상의 장치에서 데이터를 공유하는 데 사용할 수 있습니다. 개발자는 로밍 앱 데이터 저장소에 저장된 개체를 쓰고 읽음으로써 손상될 위험을 높입니다. 여기에는 로밍 앱 데이터 저장소를 통해 해당 개체를 공유하는 데이터, 응용 프로그램 및 시스템의 기밀성, 무결성 및 가용성이 포함됩니다.

개발자는 이 기능을 사용하기 전에 먼저 필요한 기술적 제어를 구현해야 합니다.

시그널 처리 race condition은 시그널 처리기로 설치된 함수가 재진입할 수 없을 때마다 나타날 수 있는데, 이러한 현상은 시그널 처리 race condition 시 일부 내부 상태가 유지되거나 이러한 기능을 하는 다른 함수를 호출함을 의미합니다. 이러한 race condition은 여러 시그널을 처리하도록 동일한 함수를 설치할 때에도 더 많이 나타납니다.

시그널 처리 race condition은 다음과 같은 경우에 더 많이 발생합니다.

1. 두 개 이상의 시그널에 대해 프로그램이 하나의 시그널 처리기를 설치합니다.

2. 처리기를 위해 두 개의 다른 시그널이 짧게 연속으로 설치되면 시그널 처리기에 race condition이 나타납니다.

예제: 다음 코드는 두 개의 다른 시그널에 대해 간단하며 비 재진입성(non-reentrant)의 동일한 시그널 처리기를 설치합니다. 공격자가 정확한 순간에 신호를 보내면, 신호 처리기에 double free 취약점이 발생하게 됩니다. 동일한 값에 대해 free()를 두 번 호출하면 buffer overflow가 발생할 수 있습니다. 프로그램이 같은 인수로 free()를 두 번 호출하면 프로그램의 메모리 관리 데이터 구조가 손상됩니다. 이 손상으로 인해 프로그램이 손상되거나 경우에 따라 이후에 있을 두 번의 malloc() 호출이 같은 포인터를 반환하기도 합니다. malloc()이 같은 값을 두 번 반환하고 나중에 프로그램이 이 중복 할당된 메모리에 작성되는 데이터에 대한 제어권을 공격자에게 넘겨주면 프로그램은 buffer overflow 공격에 취약해집니다.

void sh(int dummy) {
  ...
  free(global2);
  free(global1);
  ...
}

int main(int argc,char* argv[]) {
  ...
  signal(SIGHUP,sh);
  signal(SIGTERM,sh);
  ...
}

많은 Servlet 개발자들은 Servlet이 단일 항목이라는 사실을 모릅니다. Servlet의 인스턴스는 하나뿐이며, 이 단일 인스턴스를 여러 번 사용하여 다른 스레드에 의해서 동시에 처리되는 여러 요청을 처리합니다.

이런 무지로 인해 일반적으로 발생하는 결과는 개발자가 사용자로 하여금 실수로 다른 사용자의 데이터를 볼 수 있도록 Servlet 멤버 필드를 사용하는 것입니다. 다시 말해, 사용자 데이터를 Servlet 멤버 필드에 저장하여 데이터 접근 경쟁 조건(race condition)을 야기합니다.

예제 1: 다음 Servlet은 요청 매개 변수의 값을 멤버 필드에 저장한 다음, 나중에 매개 변수 값을 응답 출력 스트림으로 보냅니다.

public class GuestBook extends HttpServlet {

   String name;

   protected void doPost (HttpServletRequest req, HttpServletResponse res) {
     name = req.getParameter("name");
     ...
     out.println(name + ", thanks for visiting!");
   }
}

이 코드는 단일 사용자 환경에서는 올바로 동작하지만, 두 명의 사용자가 거의 동시에 Servlet에 접근하면 다음과 같이 두 요청 처리기 스레드가 얽힐 수 있습니다.

스레드 1: name에 "Dick" 할당
스레드 2: name에 "Jane" 할당
스레드 1: print "Jane, thanks for visiting!"
스레드 2: print "Jane, thanks for visiting!"

따라서 첫 번째 사용자에게 두 번째 사용자의 이름이 표시됩니다.

데이터베이스 연결과 같은 트랜잭션 리소스 개체는 동시에 트랜잭션 하나에만 연결될 수 있습니다. 따라서 스레드 간에 연결을 공유하지 말고 정적 필드에 저장하지 않아야 합니다. 자세한 내용은 J2EE Specification의 섹션 4.2.3을 참조하십시오.

예제 1:

public class ConnectionManager {

private static Connection conn = initDbConn();
...
}

다음의 경우 session fixation 취약점이 발생합니다.

1. 웹 응용 프로그램이 먼저 기존 세션을 무효화하지 않고 사용자를 인증하여 이미 사용자에게 연결되어 있는 세션을 계속 사용하도록 합니다.
2. 공격자가 사용자에게 알려진 세션 ID를 강제로 적용할 수 있기 때문에 사용자가 인증되면 공격자가 인증된 세션에 대한 접근 권한을 갖게 됩니다.

Session fixation 취약점의 일반적인 익스플로이트에서 공격자는 웹 응용 프로그램에 대한 새 세션을 만들어 관련 세션 ID를 기록합니다. 그런 다음 공격자는 기록한 세션 ID를 사용하여 피해자가 서버에 대해 인증을 받도록 하고 공격자는 활성 세션을 통해 피해자의 계정에 대한 접근 권한을 얻습니다.

Spring Security와 같은 일부 프레임워크는 새 세션을 만들 때 기존 세션을 자동으로 무효화합니다. 이 동작을 비활성화하면 응용 프로그램이 이 공격에 취약해질 수 있습니다.

예제 1: 다음 예는 session fixation 보호가 비활성화된 Spring Security로 보호된 응용 프로그램의 조각을 보여줍니다.

	<http auto-config="true">
        ...
        <session-management session-fixation-protection="none"/>
	</http>

응용 프로그램이 취약하다 하더라도 여기에 기술한 공격이 성공하려면 여러 요인이 공격자에게 유리하게 작용해야 합니다. 즉, 공용 터미널에 대한 접근을 들키지 않는 것, 손상된 세션을 활성 상태로 유지하는 능력 및 공용 터미널에서 취약한 응용 프로그램에 로그인하려는 피해자가 바로 그런 요소입니다. 대부분의 경우 충분한 시간을 투자한다고 했을 때 첫 번째 두 관문은 통과할 수 있습니다. 공용 터미널을 사용하여 취약한 응용 프로그램에 로그인하려는 피해자를 찾는 일도 해당 사이트가 아주 인기 있기만 하면 불가능한 일이 아닙니다. 잘 알려지지 않은 사이트일수록 공용 터미널을 사용하여 로그인하려는 피해자가 있을 확률이 낮고 따라서 앞서 기술한 공격이 성공할 가능성도 낮습니다.

공격자가 session fixation 취약점을 익스플로이트할 때 직면하는 가장 큰 과제는 공격자에게 알려진 세션 ID를 사용하여 피해자가 취약한 응용 프로그램에 대해 인증을 받도록 유도하는 것입니다. Example 1에서는 공격자가 잘 알려지지 않은 웹 사이트 관련 공격에 적합하게 조정할 수 없는 직접적인 방법을 사용하여 이를 수행합니다. 하지만 그렇다고 안심해선 안 됩니다. 공격자는 이 공격의 한계를 극복할 수 있는 여러 가지 수단을 갖고 있습니다. 공격자가 사용하는 가장 흔한 방법은 대상 사이트에서 cross-site scripting 또는 HTTP response splitting 취약점을 이용하는 것입니다[1]. 피해자를 속여 JavaScript 또는 기타 코드를 피해자의 브라우저에 다시 돌려보내는 취약한 응용 프로그램에 악성 요청을 전송하도록 하여 공격자는 피해자가 공격자가 제어하는 세션 ID를 다시 사용하도록 하는 쿠키를 만들 수 있습니다.

쿠키가 주어진 URL과 연결된 최상위 도메인에 연결되어 있다는 것을 주목할 필요가 있습니다. 여러 응용 프로그램이 bank.example.com 및 recipes.example.com과 같이 같은 최상위 도메인에 있는 경우, 한 응용 프로그램의 취약점 때문에 공격자가 도메인 example.com [2]에 있는 응용 프로그램과의 모든 상호 작용에 사용할 고정 세션 ID로 쿠키를 설정할 수 있습니다.

다른 공격으로는 공격자가 올바른 사이트의 요청을 리디렉션하여 사용자가 악성 사이트를 방문하도록 만드는 DNS 감염 및 관련 네트워크 기반 공격 등이 있습니다. 네트워크 기반 공격은 일반적으로 피해자의 네트워크상에 실제로 존재하거나 네트워크상의 피해 시스템을 제어하는 것과 관련이 있습니다. 이는 원격 익스플로이트가 어렵지만 그 중요성을 간과해서는 안 됩니다. Apache Tomcat의 기본 구현과 같이 세션 관리 메커니즘의 보안이 약할수록 일반적으로 쿠키에서 예상되는 세션 ID를 URL에도 지정할 수 있습니다. 이를 통해 공격자가 악성 URL을 전자 메일로 전송하기만 하면 피해자가 고정 세션 ID를 사용하도록 할 수 있습니다.