OAuth가 안전하지 않거나 이해하지 못 했습니까?

Question

내 REST 웹 서비스 API에 대한 보안을 고려 중이며 다른 서비스를 살펴보고 서비스를 수행하는 방법을 결정하기로 결정했습니다. 예를 들어 트위터의 OAuth를 연구하기로 결정했습니다. 초보자 가이드를 읽은 후에 나는 조금 혼란스러워하고 충격을 받았습니다.

사용자를 인증하고 사용자가 어떤 종류의 액세스 권한을 요구하는지 (예 : 특정 리소스에 대한 읽기 전용 액세스 권한)를 표시하는 것은 서비스 제공 업체의 책임입니다. 그러나 서비스 제공 업체가 사용자에게 어떤 유형의 액세스 소비자가 요구하고 있는지 알려주지 않고 (심지어 현재는 소비자의 신원을 보여주고 있음) 사용자에게 알리지 않습니다. 문제의 두 번째 부분은 고객이 IFrame에서 자신의 맞춤형 공급자 서비스 인증 양식을 보여줄 수 있으며 액세스 세부 정보를 숨기거나 비밀번호를 무단으로 사용하거나 리소스에 무제한 액세스를 요청할 수 있다는 것입니다. 사용자를 속이는 방법이 많이 있습니다.

예를 들어 LinkedIn을 예로 들어 봅시다. 그들은 자신의 형태로 Gmail 사용자 이름과 암호를 요청하며, 어떻게 사용할지 모릅니다. 그들은 단지 그것을 훔쳐서 DB에 저장할 수 있으며 Gmail에 OAuth를 사용할 수 있습니다. (그들은 요청한 액세스 유형에 따라 gmail의 페이지를 표시하지 않습니다.) 그들은이 정보로 원하는대로 할 수 있습니다.

내가 말하고자하는 것은 OAuth 통신 프로토콜이 안전하지 않다는 것이 아니라 부적절하게 사용자를 속여서 자격 증명을 얻는 방법이 많이 있다는 것입니다.

BTW OAuth 프로토콜 자체에 보안 흐름이있었습니다. http://oauth.net/advisories/2009-1/) 거기에 더 많은 정보가 있지만, 아무도 그 정보를 찾을 수 없습니다.

Answer 1

나는 '너는 그것을 이해하지 못했다'고 갈 것입니다. (방위에서는 극히 소수의 사람들이 있습니다.)

OAuth 1.0의 세션 고정 공격이 OAuth 1.0a에서 해결 되었으나 RFC 5849이되었습니다. OAuth 1.0의 주요 구현 자 - 주요 구현자가 모두 OAuth 1.0a/RFC 5849를 구현했거나 OAuth 2.0 초안 중 하나를 구현했습니다.

사용자 이름/비밀번호 반 패턴의 경우 OAuth 1.0a는 액세스 토큰에 대한 사용자 이름과 비밀번호를 교환하는 메커니즘을 제공하지 않습니다. OAuth 2.0은 설치된 애플리케이션을 지원하기위한 용도로만 사용됩니다. 설치된 응용 프로그램은 실제로 원한다면 단순히 키로 그 (또는 유사) 할 수 있습니다. 보안에 관해서는, 응용 프로그램이 이미 클라이언트 컴퓨터에서 네이티브로 실행되지 않고 실행되지 않은 경우 모든 베팅이 해제됩니다. 그러나 이것은 실제로 당신이 말하는 것과는 아주 다른 시나리오입니다. OAuth 1.0a 및 OAuth 2.0의 웹 애플리케이션은 사용자 이름과 비밀번호를 절대 접하지 않습니다.

OAuth 1.0a의 흐름은 다음과 같습니다. 응용 프로그램이 공급자에게 요청 토큰을 요청하여 액세스하려는 모든 것을 말합니다.프로 바이더는 일시적인 미 인증 토큰을 발행하고, 클라이언트는 그 토큰을 인증하기 위해서 프로 바이더에 유저를 송신 할 수 있습니다. 사용자는 제공자의 사이트에 사용자 이름과 비밀번호 으로 로그인 한 다음 액세스 권한을 부여하거나 거부합니다. 그런 다음 공급자는 승인 된 액세스 토큰으로 사이트를 업그레이드 할 수 있도록하는 확인 자 문자열을 사용하여 다시 리디렉션합니다. 이러한 모든 상호 작용이 서명됩니다. 서명이 일치하지 않는 경우 공급자는 요청을 거부합니다. 사용자는 언제든지 토큰을 취소하여 클라이언트의 계정 액세스 기능을 제거 할 수 있습니다.

프로토콜을 사용하는 숫자는 security considerations입니다. 실제로 목록을 읽는다면 인터넷의 거의 모든 사이트에 영향을주는 보안 문제 목록과 동일합니다. 이러한 보안 고려 사항은 모두 잘 알려져 있으며 잘 이해되어 있습니다. 내 지식으로는 현재 이러한 모든 보안 고려 사항을 올바르게 처리하는 공급자에 대한 악용 가능한 공격은 없습니다.

요점은 OAuth 1.0a 또는 OAuth 2.0을 사용하면 어떤 대안보다 제 3자를 인증하는 것이 훨씬 안전하다는 것입니다. 이러한 문제에 익숙하지 않은 경우 솔루션은 간단합니다. 타사의 계정 액세스 권한을 부여하지 마십시오. 분명히 그렇게하고 싶지 않을 이유가 많이 있습니다.

Answer 2

안전하지 않은 것에 대해 혼란스러워하는 것처럼 들립니다. OAuth 프로토콜 자체가 제대로 구현되면 보안이 보장됩니다. 부적절하게 구현하기 쉽고 사용자가하는 일을 실제로 이해하지 못하기 때문에 혼란스러워합니다.

예를 들어, LinkedIn이하는 일은 모두 잘못되었습니다. 이 방법으로 내 Gmail 계정 정보를 제공하지 않습니다. 내 Gmail 계정 정보를 제공하기 위해 브라우저가 Google과 SSL을 사용하고있어 페이지의 루트 프레임이 Google에서 제공된다는 사실을 고집합니다.

그러면 Google에 누가 어떤 액세스 권한을 요청했는지 누가 Google에 알릴지를 묻는 메시지가 나타납니다. 내가 이것을 믿을 수 없다면, 나는 OAuth를 사용하면 안된다.