아래에서 AJKJ님이 지적하신 문제(race condition)가 아닐까 생각되네요.

고쳐보도록 하겠습니다.

네, 항상 경쟁상태(race condition)가 문제죠. 두 가지 종류가 발생할 수 있겠는데요...

첫째는 AJKJ님이 말씀하신 것처럼 네트워크 환경 때문에 요청 순서가 뒤바뀌는 경우입니다. 일단, 쿠키 갱신 후에도 30초간 예전의 쿠키를 계속 사용할 수 있도록 변경해 보았습니다. 제가 만들어본 다른 프로그램에서는 이 정도만 해줘도 웬만한 경쟁상태는 피할 수 있더군요. 아무리 통신이 불안정하더라도 30초 이상 걸리면 연결을 끊어버리는 것이 보통이니까요. (더 길게 허용할 수도 있지만, 너무 봐주면 오히려 보안이 나빠집니다.)

둘째는 서버단에서 세션을 불러와 사용하고 저장하는 과정에서 발생하는 경쟁상태입니다. PHP에서 세션을 파일로 사용할 경우에는 자동으로 lock이 걸려서 순차적으로 접근하기 때문에 문제가 없지만, DB나 Memcached 등으로 사용하면 lock이 없기 때문에 두 페이지가 동시에 세션을 갱신해버리는 수가 있지요. 다음 버전에서는 여기에 뭔가 mutex를 걸어버리는 방법을 연구해 봐야겠습니다.

업로더는 PHPSESSID를 사용하도록 되어 있는데, PHPSESSID는 전혀 건드리지 않으므로 업로더와는 상관없을 거라고 생각합니다. procFileUpload act 사용시에는 애드온 작동을 일시 중지하도록 조치하기도 했고요.

DB, Memcached 등을 사용해도 세션이 동시에 여러 군데에서 수정될 가능성을 최소화하기 위해, 갱신 직전과 직후에 각각 session_write_close() && session_start() 해주고, 그 사이에 세션이 변경될 경우 갱신을 포기하는 (즉, 지금은 위험하니 다음으로 미루는) 코드를 추가해 보았습니다. 일종의 mutex를 동기화해 주는 거죠.

사실 XE는 그 묵직함-_- 때문에 처음 세션을 시작할 때(Context::init)와 마지막에 세션을 닫을 때(Context::close) 사이의 시간차가 상당히 나는 편입니다. 시간차가 많이 날수록 경쟁 상황이 발생할 가능성도 기하급수적으로 증가하죠. 방금 말씀드린 방법으로 시간차를 확 줄여버리면 문제가 발생할 여지도 확 줄어들 것 같습니다.

단 한 페이지라도 SSL을 사용할 경우 xe_secure_ssl이라는 별도의 쿠키를 secure 속성으로 구워주고 있습니다.

혹시 "세션 키"가 PHPSESSID를 의미하는 거라면 그건 어렵습니다. PHPSESSID는 업로더 등 여러가지 문제가 걸려 있어서 건드리기 힘들 뿐더러, 세션 쿠키의 속성을 바꾸려면 세션을 시작하기 전에 미리 session_set_cookie_params() 함수를 써줘야 하는데 그 시점에서는 애드온이 끼어들 수가 없습니다. 별도의 쿠키로 구현한 것도 그 때문이고요.

네, 훔친 세션에 유통기간이 있다는 의미죠. 워낙 오래 전부터 당연히 해야 하는 것으로 받아들여져 오긴 했는데, 보안 기술과 해킹 기술 모두 엄청나게 발달해버린 2015년 현재 현실적으로 얼마나 도움이 될지는 저도 의심이 됩니다. 옆집 중딩이 훔친 세션으로 이리저리 기웃거리는 것을 막을 수는 있겠지만, 전문적인 해커라면 불과 몇 초 사이에 자기 목적을 이루고 사라져 버리겠죠.

일단 경쟁상태가 발생할 여지를 최소화해 놓고 좀더 테스트해 보고, 계속 문제가 발생한다면 세션 식별자 재생성 기능 사용 여부를 사용자가 선택할 수 있도록 하는 방법도 생각중입니다. 물론 로그인시에는 당연히 해줘야 하고요. 로그아웃시에는 따로 뭘 재생성할 필요도 없이 XE 코어 자체에서 세션을 완전 파괴해 버리더군요 ㅋㅋ

EDIT: 일단 POST 요청, AJAX 요청, 플래시를 사용한 요청에서는 세션 식별자를 재생성하지 않고 "예약"만 하도록 조치했습니다. 예약된 재생성은 나중에 평범한 (페이지 전체를 새로 로딩하는) GET 요청을 할 때에 이루어집니다.