SSO 구현시 발생할 수있는 보안 문제는 무엇입니까?

Question

현재 도메인 간 SSO 구현을 연구하고 있으며 제 3 자 SSO 공급자를 사용할 수 없을 수도 있습니다.

일련의 리디렉션과 암호화 된 쿼리 문자열 매개 변수가 포함 된 맞춤형 구현 온라인을 발견했습니다. http://www.foo.com

MrUser에

1. MrUser 로그 bar.com에 인증되지 http://www.bar.com/page.aspx

2. MrUser 링크를 클릭하지만 bar.com http://www.foo.com/sso.aspx

리디렉션 인증 코드를 가지고

3. sso.aspx 페이지는 쿠키 컬렉션에서 유효한 ASP.NET 인증 쿠키를 확인합니다. 존재하는 경우 sso.aspx는 http://www.bar.com/page.aspx&ssoauth=[encryptedkey]으로 리디렉션됩니다 (여기서 [encryptedkey]은 foo.com과 bar.com이 동의 한 MrUser의 암호화 된 ID입니다). 유효한 ASP.NET 인증 쿠키가없는 경우 ssoauth 매개 변수없이 리디렉션됩니다.

4. Bar.com은 무한 리디렉션 루프를 방지하기 위해 검사를 수행 한 다음 ssoauth 값의 암호를 해독합니다. ssoauth 매개 변수가 없으면 MrUser는 로그인 페이지로 리디렉션됩니다. 그렇지 않으면 Bar.com은 해독 된 ID를 사용하여 MrUser를 인증 한 후 page.aspx로 보냅니다.

이 메서드의 잠재적 인 보안 문제 (또는 다른 유형의 문제)는 무엇입니까?

(인용 : http://blogs.neudesic.com/blogs/michael_morozov/archive/2006/03/17/72.aspx)

편집 : 암호화 된 ID가 매번 동일하고, 공격자가 액세스하는 데 사용할 수 있다는 것을 인용 답변에 대응 - bar.com가를 확인하면 어떻게 foo.com의 ssoauth 매개 변수 만 받아 들일 수 있도록 referrer?

Answer 1

첫 번째 문제는 모든 암호화/해독 스키마가 명백하게 표시 될 때 알아낼 수 있다는 점입니다. 암호화 키가 공개되어 있지만 암호 해독 키가 비공개 인 PKI 암호화/암호 해독 플랫폼 라인을 따라 뭔가를 구현하는 것이 좋습니다. 암호화는 "깨지는 시간"을 늘리기 위해 적절히 복잡 할 필요가 있으며, 키의 암호화/해독을 수행하는 데 리소스가 필요할 것입니다.

도메인이 공통적이지 않기 때문에 헤더에 암호화 된 부분 (게시 또는 가져 오기)을 제공하고 일반 텍스트로 전달해야 할 필요가 생깁니다. querystring 정보는 요청 수명 동안 안전하게 보관되지만 (편집 : SSL이라고 가정) 브라우저 기록 (일반적인 컴퓨터에서 액세스 할 수있게 만드는)으로부터 안전하지 않습니다.

최악의 보안 문제는 "균열 하나/균열 모두"의 개념입니다. 서버 중 하나가 손상되어 해당 암호화/해독 알고리즘, 소금 등이 노출되면 공격자가 원하는대로 유효한 암호화 SSO 키를 생성하여 모든 시스템을 손상시킬 수 있습니다.

이러한 문제는 극히 비극적입니다. 은행이나 의료기관에서는이 계획을 이행하지 않지만 SO 나 Twitter와 같은 위험도가 낮은 사이트의 경우 완벽하게 수용 할 수 있습니다. 자원, 위험 및 이득을 관리하는 일 모두가 내려 질 것입니다.

Answer 2

누구나 encryptedKey을 사용하면 MrUser로 액세스 할 수 있습니다. 암호화가 아니라 서명 또는 메시지 인증 서비스가 필요합니다. 인증 된 메시지는 재생을 막기 위해 사용자 식별자가있는 nonce를 포함해야합니다.

이와 같은 프로토콜은 고안하기가 어렵습니다. 수년 동안 널리 사용되고 검토 된 TLS조차도 보안 결함이 있습니다. 증명되지 않은 인증 메커니즘을 사용하지 마십시오.

Answer 3

ssoauth 암호화 키가 사용자의 암호화 된 ID 일 경우 잠재적 인 문제가 발생할 수 있습니다. 이러한 설정은 매번 동일한 키를 제공하게되므로 원래 사용자 또는 제 3자가 다시 사용할 수 있습니다.

이러한 상황을 피하는 한 가지 방법은 foo.com 및 bar.com 서버의 시간 시계를 상대적으로 동기화 된 상태로 유지하고 날짜/시간 (모듈로 5 분)이 포함 된 키를 발급하는 것입니다.

사람들은 종종이 암호화의 요소 중 하나로서 웹 클라이언트의 IP 주소를 사용하려고하지만 여러 프록시 및 게이트웨이가 풀 내의 다른 공용 IP를 사용하여 다른 도메인/서버에 액세스하기 때문에 나쁜 생각입니다.

별개의 암호를 각각의 시간을 허용하는 또 다른 방법은

http://www.foo.com/sso.aspx 

이 매개 변수와 같은

http://www.foo.com/sso.aspx?ParamForKey=some_random_number 

을 포함

에 bar.com의 리디렉션을하고 암호화의 한 부분으로 ParamForKey을 사용하는 것입니다 프로세스

Answer 4

몇 가지 문제가 있습니다. 1) 암호화 된 토큰의 유효 기간은 얼마입니까? 초에 대해서만 유효해야합니다. 모든 서버가 ntp에 있으면 쉽습니다. 만료가 있으면 암호화 된 토큰이 포함 된 링크가 남아있는 경우에도 사용자를 보호합니다. bar.com 서버가 많은 경우 nonce를 확인하기가 어렵습니다. 몇 초 만료하면 재생을 완화해야한다고 말할 수 있습니다.

2) SSO 상호 도메인의 문제점은 싱글 사인 오프입니다. 사용자가 foo.com에서 로그 아웃하면 어떻게 될까요? bar.com의 세션은 무효화되어야합니다. 당신은 해킹으로 XSRF bar.com 로그 아웃을 할 수 있습니다 :). 사용자가 아직 로그인했는지 확인하려면 bar.com beacon foo.com을 15 분마다 보유해야합니다.

3) 사용자가 bar.com에서 로그 오프하지 않고 다중 사용자 컴퓨터이고 다른 사용자가 foo.com에? 사용자 ID가 일치하지 않으면 이전 사용자의 데이터가 표시되지 않도록해야합니다.

4) 다른 사람이 언급했듯이 암호화보다는 사용자 ID에 서명 또는 HMAC가 필요할 수 있습니다. 암호화하는 경우에는 암호문의 무결성을 보호해야합니다. barcode에서 사용자 B의 데이터에 액세스 할 수 있는지 알아보기 위해 암호문에 사용자 A가 튀기는 비트를 원하지 않습니다.

https를 통해 리디렉션됩니다.

마지막으로 모든 사람이 말했듯이 리퍼러는 스푸핑 될 수 있습니다. 그들을 신뢰하지 마십시오.