폼 인증을 사용하는 ASP.NET MVC 앱이 있습니다. 사용자가 인증되면 응답으로 인증 정보가 포함 된 양식 쿠키를 받게됩니다. 이제 양식 쿠키에 관한 : 그것은 기계 키에 의해 암호화되며 서명에 의한 변조로부터 보호됩니다. 또한 HTTPS를 사용합니다 ... 그러나 어떻게 든 쿠키를 가져 와서 다른 클라이언트의 요청을 만들려고한다면 (요청은 다른 IP 주소에서 이루어짐)?폼 인증은 세션 하이재킹으로부터 보호합니까?
이 시나리오는 효과가 있습니다. 이런 종류의 공격으로부터 방어 할 수있는 방법이 있습니까?
그런 종류의 공격으로부터 방어 할 수있는 방법이 있습니까?
하지 않아야합니다. 몇 년 전에 우리는 그러한 기능을 구현하여 곧 중단했습니다. 바로 그 브라우저/컴퓨터에서 요청을하지만, HTTP/HTTPS를 전환 한 사용자가 때때로 서로 다른 IP에서 볼 수
용어를 명확히하기 위해 세션 하이재킹은 권한이없는 사용자가 서버의 세션 상태에 액세스하는 경우의 취약점에 대해 일반적으로 언급됩니다.
인증 쿠키는 세션 쿠키와 다릅니다. ASP.NET은 인증 쿠키를 보호하는 데 더 많은 사전 예방 조치를 취합니다. 설명하는 내용은 CSRF (교차 사이트 요청 위조)이라는 용어로 더 잘 설명됩니다. @Wiktor의 답변에 따르면 IP로 액세스를 제한하는 것은 실용적이지 않습니다. 또한 CSRF의 작동 방식을 읽으면 악용은 원래 IP 주소의 사용자 브라우저에서 실행될 수 있습니다.
좋은 소식은 ASP.NET MVC가 구현하기가 쉬운 CSRF 방지를 지원한다는 것입니다. here을 읽으십시오.
나는 OP가 CSRF를 의미한다고 생각하지 않는다. 왜냐하면 그들은 다른 클라이언트와 IP에서 쿠키가 사용되었다는 것을 명시하고 있기 때문이다. 세션 하이재킹은 서버 세션 (.NET 세션 객체)에 액세스하거나 폼 인증을 통해 적절한 위치에서 인증 집합을 도용하는 것을 의미합니다. 둘 다 일반적으로 공격자의 시스템에서 유효한 토큰 클라이언트 측을 사용하여 수행됩니다. – SilverlightFox
사이트의 모든 곳에서 HTTPS를 사용하고 web.config의 system.web/authentication/forms 요소에서 requireSSL = "true"로 설정하면 브라우저가 HTTPS 연결을 통해 해당 쿠키 만 다시 전달하도록 지시합니다 . 이렇게하면 트래픽 스니핑 기반 세션 하이재킹 공격의 대부분을 막을 수 있으며 사이트가 HTTPS 인 경우에만이를 사용해야합니다.
폼 인증은 본래부터 상태 비 저장입니다. 서버는 CookiePath, Expiration, Expired, IsPersistent, IssueDate, Name, UserData, Version과 같은 정보를 암호화하여 클라이언트 측에 저장합니다. machineKey가 해킹 당하지 않았다고 가정하면 클라이언트는 이것을 암호화 된 데이터의 얼룩으로 간주합니다. 해당 BLOB를 다시 서버에 제공하면 서버는이를 해독하고 다시 FormsAuthenticationTicket으로 변환하고, config에 대한 티켓의 유효성을 검사하고 티켓이 만료되지 않았는지 확인한 다음 요청을 다음과 같이 처리할지 여부를 결정합니다. 인증 된. 어떤 티켓이 돋보이는지를 '기억'하지 않습니다. 또한 IP 주소는 어디에도 포함되어 있지 않습니다.
HTTPS 전용 인 경우 machineKey를 보호하고 requireSSL 형식의 인증 쿠키를 설정하면 공격자가 클라이언트의 브라우저 및/또는 컴퓨터를 대상으로 할 수 있습니다. 이론적으로 그들은 브라우저의 공간에서 메모리 나 디스크의 쿠키를 훔칠 수 있습니다. 바이러스/트로이 목마가 악의적 인 브라우저 확장 기능을 수행 할 수도 있습니다.간단히 말해, 사용자가 유효 기간이 만료되지 않은 Forms Auth 쿠키를 사용할 수있게되면 만료 될 때까지 원하는 모든 컴퓨터에서 제공 할 수 있습니다. 영구적 인 인증 쿠키를 허용하지 않고 제한 시간을 최소로 유지하면 위험을 줄일 수 있습니다.
machineKey가있는 경우 원할 때마다 처음부터 FormsAuth 쿠키를 만들 수 있습니다.
아 .. 하트 블을 잊지 마세요. 안전하지 않은 버전의 OpenSSL을 사용하는로드 밸런서 또는 리버스 프록시가있는 경우 공격자가 개인 키를 손상시키고 HTTPS 연결을 통해 트래픽을 가로 챌 수 있습니다. ASP.NET은 OpenSSL을 사용하지 않으므로 순수 MS 스택에서는 안전합니다. MS의 SSL 구현의 취약점에 대해 듣는다면 최대한 빨리 패치를 적용하고 비밀번호를 변경하고 인증서를 다시 발급 받으십시오.
브라우저/머신 기반 하이재킹이 걱정된다면 Sholo.Web.Security (https://github.com/scottt732/SholoWebSecurity)라고 불렀던 프로젝트를 살펴볼 수 있습니다. 목표는 각 요청에 대한 약간의 오버 헤드를 희생하면서 서버에서 상태를 유지함으로써 폼 인증을 강화하는 것이 었습니다. 서버 측 (사용자를 걷어차/로그 아웃) 티켓을 취소하고 사용자가 IP 주소 사이에서 티켓을 이동하지 못하도록하는 등의 작업을 수행 할 수 있습니다. Wiktor가 설명하는 이동중인 모바일 사용자 시나리오에서 성가 시게 될 수 있습니다 (선택 사항 임). 포크를하거나 포크 요청을 제출하십시오.
0leg는 로그인 프로세스를 시작하는 UI/양식 메커니즘에 적용되는 Anti-CSRF 기능이지만 CSRF와 관련된 Forms 인증 프로세스 자체에는 아무 것도 없습니다. 즉, 쿠키가 클라이언트에 발행되면 쿠키가 서버간에 반송되는 것을 막는 유일한 방법은 쿠키가 발급 된 도메인/하위 도메인으로 제한된다는 것입니다. stackoverflow.com 쿠키는 serverfault.com에 제공되지 않습니다. 브라우저가 당신을 위해 그 물건을 처리합니다.
가능한 복제본 [세션 복제를 보안 위험으로 생각합니까?] (http://stackoverflow.com/questions/22806797/do-you-consider-session-replication-as-a-security-risk) – SilverlightFox
당신은 "이 시나리오는 효과가있다"고 말했다. https/ssl이 사용될 때 어떻게 누군가의 양식 ID를 얻습니까? – Pingpong
[PingPong] 쿠키가 보안 속성이 설정된 경우에도 XSS를 사용하여이 작업을 수행 할 수 있다고 생각합니다. 트로이 목마 같은 다른 것들이있을 수 있습니다. – seeker