it-swarm-korea.com

SSL을 사용하지 않고 FireSheep에서 웹 앱을 보호 할 수 있습니까?

일부 웹 사용자에게 웹 사이트에 대한 액세스 권한을 부여하고 싶지만 최소한 초기 로그인 페이지를 지나서 모든 사용자에게 SSL을 제공 할 수 없거나 제공하지 않는다고 가정합니다.

이 경우 FireSheep을 무효화하지만 고통스러운 사용자 경험을 생성하지 않는 사용자 세션을 관리하는 방법이 있습니까?

19
Falkayn

원칙적으로 수동 공격으로부터 방어 할 수 있습니다. 그러나 실제로는 사소하지 않고 훌륭한 솔루션이 아닙니다.

원칙적으로 Javascript로 자체 암호화 코드를 작성하여 클라이언트 측 (Javascript)의 모든 것을 암호화 할 수 있습니다. 가장 먼저 만나는 것은 Javascript의 암호화가 브라우저의 기본 암호화보다 훨씬 느리기 때문에 성능이 좋지 않다는 것입니다. 자연스러운 반응은 가장 민감한 데이터 (예 : 사용자의 비밀번호 만) 만 암호화하도록 제안하는 것입니다. 그러나 이것은 제대로하기가 매우 어렵고 많은 미묘한 함정이 있습니다.

  1. 쿠키를 암호화하지 않으면 세션 하이재킹에 취약하고 아무것도 얻지 못했습니다. 그리고 자바 스크립트에서 쿠키 나 다른 HTTP 헤더를 암호화하는 것은 쉽지 않습니다. 따라서 사용자 인증 방법을 발명하고 세션 관리를 위해 쿠키 (자작) 이외의 다른 것을 사용해야 할 수 있습니다. 이는 많은 작업이며 잘못되기 쉽습니다.

  2. 비밀번호 만 암호화하면 CSRF 공격에 취약 할 수 있습니다. 도청자는 여전히 모든 페이지 콘텐츠를 볼 수 있으며, 특히 CSRF 토큰이 링크에 포함 된 경우 도청자는 모든 CSRF 토큰을보고 CSRF 공격을 수행 할 수 있습니다. 충분한 노력으로이를 방어 할 수 있지만 클라이언트와 서버 모두에서 여전히 더 많은 작업이 필요하고 제대로 작동하기가 까다 롭습니다.

  3. 사용자가 Facebook 계정을 사용하여 사이트에 로그인 할 수있는 경우 Facebook을 제어하지 않기 때문에 도청자가 Facebook 계정을 훔친 다음 사이트에 로그인하는 것을 막을 수 없습니다.

  4. 페이지 콘텐츠를 수정하는 중간자 공격 (활성 공격)에 여전히 취약합니다. ARP 하이재킹, 인종 공격 또는 기타 방법을 사용하여 Firesheep을 수정하여 중간자 (man-in-the-middle)로 삽입하고 모든 페이지 콘텐츠를 수정하는 것은 기술적으로별로 어렵지 않습니다. 그러면 공격자가 키로거 역할을하는 악성 자바 스크립트를 삽입하거나 인증 자격 증명을 훔치기 때문에 보안이 손실됩니다.

  5. 캐싱의 이점을 잃지 않도록주의해야합니다.

이제 나는 그것이 불가능하다고 말하는 것이 아닙니다. 거의 확실하지 않습니다. 대부분의 수동적 공격을 방지하는 웹 사이트와 솔루션을 구축하는 것은 거의 확실합니다. 그러나 그것은 복잡하고 사소하지 않을 것입니다. 즉,이를 구축하려면 상당한 보안 전문 지식이 필요하며 무언가를 망칠 가능성이 여전히 중요합니다. 결과가 비싸다는 의미이기도합니다. 그리고 보안은 본질적으로 제한되어 있습니다. 모든 체계는 부분적인 솔루션/완화 일 뿐이므로 가치가 제한됩니다. 좋은 트레이드 오프라고 생각하지 않습니다.

SSL을 사용하지 않고 도청으로부터 방어하려는 최첨단 시도에 대해 읽으려면 다음과 같은 훌륭한 리소스를 참조하십시오.

또한 SSL이 잘 작동하도록하기위한 몇 가지 리소스를 공유하고 싶습니다.

SSL은 무료가 아니지만 사람들은 때때로 SSL의 성능 영향이 실제보다 더 나쁠 것이라고 생각한다는 사실을 명심하십시오.

7
D.W.

여기 에 설명 된대로 동적 세션 관리를 통한 인증과 관련된 "모호함을 통한 보안"체계를 통해 현재 Firesheep을 피할 수 있습니다. "다이제스트 인증"( RFC 2617 )을 사용할 수 있지만 여전히 MITM 공격에 취약하고 사용자 경험이 저하되며 서버가 암호 (또는 이에 상응하는 암호)를 일반 파일에 저장해야합니다. .

그러나 SSL/TLS를 피한다고해서 암호화 없이는 (1) 모든 비공개 콘텐츠가 공개적으로 공유되고 (2) 단호한 공격자가 귀하의 계획을 알아내어 무력화 할 수 있다는 두 가지 근본적인 문제를 해결할 수 없습니다.

활성 공격의 몇 가지 귀여운 예, 성능 불이익에 대한 오해, EFF에서 SSL 배포에 대한 구체적인 조언을 참조하십시오. HTTPS를 올바르게 배포하는 방법 . Stack Overflow 메타 토론 Stack Overflow에서 수정되지 않은 이유 (아직)도 참고하세요.

일반적인 사이트에 대한 노출은 처음에 생각했던 것보다 더 나쁩니다. 예 : Firesheep 저자로서이 주름에 주목하십시오 훌륭한 포스트에 설명합니다

여기에서 공격을 받고있는 사이트를 단순히 방문하는 것을 피할 수는 없습니다. 오늘날 웹에는 Facebook '좋아요'버튼, Digg의 'Digg It'버튼, Twitter 위젯, 심지어 Flickr 또는 기타 사진 공유 사이트에서 호스팅되는 삽입 된 이미지와 같은 수많은 혼합 콘텐츠가 있습니다. 이 콘텐츠가 포함 된 웹 페이지에 액세스 할 때마다 브라우저는 위젯을 풀다운 요청과 함께 보유한 모든 인증 쿠키를 보냅니다.

적어도 그가 논의한 오류를 수정할 수 있습니다 (예 : 사용자가 로그 아웃 할 때 실제로 세션 쿠키를 무효화 !!).

또한 이러한 "사이드 재킹"공격으로부터 자신을 어느 정도 보호하는 방법에 대해 사용자에게 조언 할 수 있습니다. VPN을 사용하거나 WPA2 Wi-Fi 네트워크를 찾는 방법 (WPA2 문제 여기 참조).

@ D.W 덕분에. 내가 본 것 중 가장 잘 고안된 임시 접근 방식에 대한 링크는 Ben Adida의 SessionLock Lite입니다. 적어도 수동적 공격자의 지속적인 하이재킹을 방지합니다. Benlog"세션 쿠키에서 손을 떼지 마십시오 . 거기서 멈추지 말고 SSL 배포를 설계하세요 ....

10
nealmcb

의심의 여지없이 대답은 [~ # ~] 아니요 [~ # ~] 입니다. 세션 ID를 전달할 완전히 안전한 전송 계층이 있어야합니다. 이 세션 ID는 안전하지 않은 연결을 통해 변환 될 수 없습니다. 이것은 OWASP A9-Insufficient Transport Layer Protection 위반이됩니다.

8
rook

나는 Rook의 대답에 동의합니다. 그러나 firesheep 및 일반적으로 모든 세션 하이재킹의 사용을 완화 할 수있는 아이디어가 있습니다.

내 제안은 브라우저 지문을 모든 사용자에게 연결하는 것입니다. 지문이 다른 경우 사용자는이 지문을 자신의 계정에 다시 인증해야합니다.

기본적으로 브라우저 만보고 생성 할 수있는 panopticlick.eff.org 와 유사한 지문을 저장하는 것을 의미합니다.

  • 지문이 변경 될 때마다 사용자가이 지문을 인증했는지 확인하십시오.
  • 이 사용자 계정에서 지문이 인증되지 않은 경우 사용자를 다시 인증하십시오.

웹 사용자 프로파일 링에 대한 자세한 정보는 여기에서 찾을 수 있습니다.

2
Chris Dale

한마디로, 아닙니다. FireSheep 스타일의 공격을 방지하려면 수동적 인 관찰자로부터 헤더를 보호 할 수있는 방법이 필요합니다. (결국 모든 형태의 인증 기준을 포함하여 클라이언트가 보낸 모든 정보는 헤더에 있습니다.) 이것은 연결 수준 보안을 의미합니다. 그리고 HTTP의 경우 가장 일반적으로 HTTPS로 알려진 TLS 또는 SSL 보호 HTTP를 의미합니다.

더 어렵게 만들 수있는 몇 가지가 있지만 그 주위에는 방법이 있습니다.

1
David