왜 세션 쓰기가 스레드 종료에 취약합니까?

Question

하는 코드 :

Session["foo"] = "bar"; 
Response.Redirect("foo.aspx"); 

인한 문제 : foo.aspx 세션에서 "foo는"읽을 때

, 거기 아니다. 세션이 있지만 "foo"에 대한 가치는 없습니다.

나는 이것을 우리의 생산 환경에서 간헐적으로 관찰했다. 그러나 나는 여기에 묻기를 의미하지는 않습니다. a question about Response.Redirect().

설명

:

Bertrand Le Roy는 설명합니다 (굵은 글자는 내 꺼야) :

자, 리디렉션가하는 것은 서버에 요청 있도록 클라이언트에 특별한 헤더를 보내는 것입니다 대기중인 것보다 다른 페이지에 대해 서버 쪽에서이 헤더를 보낸 후 Redirect가 응답을 종료합니다. 이것은 매우 폭력적인 일입니다. Response.End는 실제로 인 페이지의 실행을 ThreadAbortException을 사용하여 중지합니다. 어떤 이 실제로 여기에서 발생하는 것은 세션 토큰이 전투에서을 잃어 버리게된다는 것입니다.

나의 테이크 어웨이는 Response.Redirect()가 엔딩 스레드로 무거워 질 수 있습니다. 그리고 그것은 그 무거운 힘에 너무 가까워지면 내 세션 기록을 위협 할 수 있습니다.

질문 :

무엇 ASP.NET에 대한 세션 관리는 이것에 너무 취약 하죠? Response.Redirect() 코드 줄은 세션 쓰기 줄이 "완료"될 때까지 실행을 시작하지 않습니다. 세션 쓰기에 대한 위협이 될 수있는 방법은 무엇입니까?

다음 코드 줄이 실행되기 전에 세션 쓰기가 "완료"되지 않습니다. 세션 쓰기가 (결코 발생하지 않았던 것처럼) 손실되는 다른 시나리오가 있습니까?

Answer 1

몇 가지 대안 (Response.Redirect (..., false), Server.Transfer() 및 지금은 기억할 수없는 다른 "솔루션")을 테스트 한 후에이 문제에 대한 단 하나의 신뢰할만한 답변을 찾았습니다 .

세션 상태를 InProc에서 SqlServer로 이동하면 Response.Redirect (...)를 완전히 신뢰할 수있게 남겨두고 시스템에서이 동작을 효과적으로 제거했습니다. 추가 테스트에서 그렇지 않다고 표시되면 여기에서보고 하겠지만 세션 환경을 SqlServer로 이동하십시오 (또는 "Out of InProc"으로 충분합니까? 확실하지 않습니다).

Answer 2

필자는 세션 작성의 내부에 익숙하지 않지만 브라우저 세션 쿠키를 서버 식별로 변환하는 데 의존하기 때문에 다소 복잡하다고 생각합니다. 또한 ThreadAbortExceptions do have special considerations이 런타임에서 재생 될 수 있습니다. 확실하지 않습니다.

어쨌든 Response.Redirect()에는 스레드를 종료할지 여부를 지정할 수있는 부울 매개 변수를 사용하는 오버로드가 있습니다.

당신이 "거짓"으로 설정 endResponse로 호출하면

Response.Redirect(string url, bool endResponse); 

, 그것은 정상적으로 오히려 내부적으로 Thread.Abort()를 호출하는 대신, 완료됩니다. 그러나 이는 페이지 라이프 사이클에서 남아있는 코드가 실행되기 전에 실행된다는 것을 의미합니다.

좋은 절충안은 Response.Redirect(url, false) 다음에 Application.CompleteRequest()을 호출하는 것입니다. 이렇게하면 리디렉션이 발생하지만 최소한의 추가 수명주기 처리로 현재 실행 컨텍스트를 정상적으로 종료 할 수 있습니다.

Answer 3

응용 프로그램 풀 재활용은 세션을 종료시킬 수 있습니다. 고정 된 시간에 (권장 및 야간 또는 사용량이 적은 시간에) 재생하거나 응용 프로그램 풀 재생 시간 초과 기간을 늘리려면 응용 프로그램 풀을 구성 할 수 있습니다.