Session Fixation

기존의 세션 ID를 무효화하지 않고 사용자를 인증하면 공격자에게 인증된 세션을 도용할 수 있는 기회를 제공합니다.

다음의 경우 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를 사용하도록 할 수 있습니다.