FormsAuthentication.SetAuthCookie 대 FormsAuthentication.Encrypt

Question

질문 # 1 : setAuthCookie가 FormsAuthentication.Encrypt (ticketVariable)보다 덜 안전합니까?

누군가가 setAuthCookie로 만든 쿠키를 수정하려고 시도하면 사용자 이름을 수정하여 이후의 호출에서 인증을 위반하게 될 것이라고 생각합니까?

질문 2 : 아이폰과 태블릿을 사용하여 사이트에 액세스하는 사람들은 FormsAuthentication이 실패 할 것이라고 생각합니까? cookieless 옵션을 사용하고 싶지 않다는 점을 감안할 때, 스마트 폰 웹 브라우저와 ummm none-smartphone 웹 브라우저에서 사이트를 안전하게 만드는 다른 접근법이 있습니까?

환호

Answer 1

SetAuthCookie 기본적 제공된 자명 & 지속성 옵션은 FormsAuthenticationTicket 새를 생성하여 직렬화, FormsAuthentication.Encrypt()의 그것과는에는 Response.Cookies 컬렉션에 설정. SetAuthCookie와 GetAuthCookie는 모두 FormsAuthentication.Encrypt를 간접적으로 호출합니다.

후속 요청에서 FormsAuthentiationModule은 AuthenticateRequest 이벤트를 처리합니다. 쿠키 (만료되었을 수 있음)가 표시되면 machineKey (이 쿠키는 변조되었을 수 있음)의 값을 해독하고 FormsAuthenticationTicket으로 다시 역 직렬화합니다 (손상되었을 수 있음). 그 중 나쁜 것이 발생하지 않으면 티켓에는 사용자 이름, 발급 날짜, 만료 정보 등이 포함됩니다. 티켓이 만료되지 않으면 IIdentity 및 IPrincipal이 만들어져 HttpContext.Current.User 및 Thread에 할당됩니다. CurrentThread.Principal. .NET 4.5 이상에서는 (ClaimsIdentity, ClaimsPrincipal) 클레임 기반입니다. 그 전에는 (GenericPrincipal, FormsIdentity)라고 생각했습니다.

사용자쪽에있는 모든 변조는 익명으로 처리됩니다. 해독에 실패합니다. 이 유효성 검사를 손상시키는 유일한 일은 web.config/machine.config의 machineKey가 어떻게 든 공격자의 손에 닿았거나 프레임 워크 코드에 버그가있는 경우입니다 (Oracle의 Padding 검색에서).

이외에도주의해야 할 다른 사항은 세션 도용입니다. 예를 들어 누군가가 공개 wifi에서 쿠키를 훔쳐 내면 쿠키를 서버에 표시 할 수 있으며 서버는 마치 자신의 것처럼 동작합니다. 이것은 일반적으로 네트워크 트래픽 스니핑을 포함합니다. 이러한 이유로 전체 사이트에 대해 SSL을 사용하고 web.config/system.web/authorization/forms에서 쿠키를 HTTP 전용 및 보안 (https 연결을 통해서만 제공)으로 설정하는 것이 가장 좋습니다. HTTP는 클라이언트 쪽 자바 스크립트에서 사용할 수 없음을 의미합니다. HTTP 전용 및 보안은 효과적으로 HTTPS만을 의미합니다. 이는 전체 사이트에서 SSL을 사용하는 경우에만 작동합니다.

FormsAuthentication은 모바일 웹 브라우저에서 정상적으로 작동합니다. 클라이언트가 쿠키를 허용하기 만하면됩니다. 내가 아는 한, 모든 모바일 장치가 이것을 허용 할 것입니다.