2011-02-01 5 views
4

올바르게 이해하면 내 데스크톱 응용 프로그램 (지금부터는 '클라이언트'라고 함)에서 API 호출을하려면 OAuth2 표준과 같이 응용 프로그램 ID와 응용 프로그램 ID를 결합하는 식별자 인 access_token을 얻어야합니다. 액세스하려는 데이터의 사용자 ID ('리소스 소유자'). 인증 가이드 (developers.facebook.com/docs/authentication/) 내가 시간에 요청을 보낼 필요가 이해에 클라이언트 흐름에 따라redirect_uri를 사용하는 페이스 북의 클라이언트 측 인증 흐름은 borken입니까?

** 추신 : //www.facebook.com/dialog/oauth CLIENT_ID = YOUR_APP_ID & redirect_uri로 = HTTP : // example.com & response_type = 토큰 결과적으로 페이지는 h ** p : //example.com/#access_token=XXX로 리디렉션됩니다. 클라이언트가 순수한 데스크톱 응용 프로그램 인 경우 redirect_uri는 h ** p : //www.facebook.com/connect/login_success.html이 될 수 있습니다. 클라이언트가 웹 컨트롤을 소유하고 있기 때문에 access_token은 리디렉션 된 주소에서 쉽게 추출 할 수 있습니다.

클라이언트 측 흐름이 3의 OAuth 단계로 구성 리소스 소유자가 페이스 북 자격 증명을 요청, 페이스 북, 대화에 로그인하지 않은 경우,

  1. 사용자 인증, 표시됩니다. 리소스 소유자가 로그인하면 세션은 Facebook의 서버에서 쿠키를 사용하여 인증됩니다. 보안 - CHECK V!
  2. 응용 프로그램 권한, 자원 소유자가 아직 응용 프로그램에 대한 권한을 부여하지 않은 경우 자원 소유자가 이전에 필요한 모든 권한을 강탈 한 경우 권한 대화 상자에서 응용 프로그램에 권한을 부여하라는 대화 상자가 표시됩니다 표시됩니다. 보안 - CHECK V!
  3. 앱 인증 - 이제는 끈적 거리는 곳입니다. 가이드는 "응용 프로그램 인증은 redirect_uri가 개발자 앱에 구성된 사이트 URL과 동일한 도메인에 있는지 확인하여 처리됩니다"라고 말합니다. 보안 - 제 생각에는 FAIL!

왜 보안 문제가 마지막 단계라고 생각합니까? 우선 앱 ID와 redirect_uri는 누구나 얻을 수있는 공개 정보입니다. 둘째, redirect_uri는 h ** p : //www.facebook.com/connect/login_success.html이 될 수 있습니다.

다음 시나리오를 살펴 보겠습니다. 데스크탑 응용 프로그램 인 EVE는 사용자가 페이스 북에 로그인하고 EVE에 기본 권한을 부여하는 웹 컨트롤을 사용자에게 보여줍니다. 리소스 소유자는 아무 것도 의심 할 이유가 없습니다. 그런 다음 EVE는 웹 컨트롤을 숨기고 h로로드하려고 시도합니다. h ** ps : //www.facebook.com/dialog/oauth? client_id = OTHER_APP_ID & redirect_uri = http : //www.facebook.com/ connect/login_success.html & response_type = 토큰. 응용 프로그램은 가장 인기있는 페이 스북 응용 프로그램 응용 프로그램 ID로이 URL을로드하고로드 할 수 있습니다. 로그인 대화 상자와 권한 대화 상자가 표시되지 않으므로 이전에 사용자가 OTHER_APP을 승인 한 경우 앱에 성공 메시지가 표시됩니다. 그러면 자원 소유자가 OTHER_APP에 부여한 자원 소유자의 모든 자원에 액세스하기 위해 EVE에게 access_token이 제공되고 EVE에는 부여되지 않습니다.

보안상의 문제입니까? 나는 따라 오는 것을 놓쳤습니까?

(UPDATE) 응용 프로그램이 이미 그와 함께 아무것도 할 수있는 사용자 이름과 페이스 북 세션, 심지어 사용자 이름과 암호를 가지고 있기 때문에 데스크톱 응용 프로그램의 경우에는 분명히

는 보안 문제가 무관 사용자 계정

(업데이트) 웹 브라우저에서 실행되는 JavaScript 응용 프로그램의 경우 redirect_uri가 실제로 작동합니다! (hnrt의 답변 및 의견 참조).

현재 질문 : 유일한 미스터리는 iPhone 및 Android 앱에서 클라이언트 인증이 작동하는 방법입니다. 전체 보안은 데스크톱 응용 프로그램을 사용할 때와 비슷합니까? 탈옥 한 아이폰이나 뿌리 내린 안드로이드에 약간의 차이가 있습니까?

건배!

+0

적어도 iPhone에서는 다른 app_id에 대한 각 토큰 요청에서 사용자 로그인이 필요합니다. 개발자가 SDK를 사용하지 않고 표준 API를 통해 access_token을 요청하지 못하게하는 이유는 무엇입니까? – fudge

답변

1

내가 올바르게 이해한다면, 사용자는 이미 EVE가 Facebook과 대화 할 때 사용할 수있는 동일한 웹 컨트롤을 사용하여 다른 앱에 대해 이미 인증을 받아야합니다. 그렇다면 이미 훨씬 더 큰 보안 문제가 있습니다 :) EVE는 전체 세션과 모든 인증 토큰을 납치 할 수 있습니다.

[업데이트] Javascript 응용 프로그램과 관련하여 same origin policy은 EVE가 /dialog/oauth?client_id=OTHER_APP 요청에 대한 응답에 액세스하지 못하게합니다. 데이터에 액세스하는 유일한 방법은 redirect_uri에서 대기하고 리디렉션 된 요청을 구문 분석하는 것입니다. 여기에 "사이트 URL"보호 기능이 있습니다.

iPhone 및 Android 응용 프로그램의 작동 방식이 확실하지 않지만, 웹 컨트롤이 다른 사용자의 인증 데이터 (= 쿠키)에 대한 액세스를 허용하면 정말 놀랍습니다. 응용 프로그램.

+0

데스크톱 앱에 대해 정확합니다. 사용자 이름과 비밀번호는 앱에서도 도용 될 수 있습니다. 내 질문을 JS 사례로 업데이트했습니다. – fudge

+0

Iframe 내에서 똑같은 작업을 수행하는 JS 코드가 있으면 JS가이 Iframe에 액세스 할 수 있으며 새 URL에서 access_token을 읽을 수 있습니다 (리디렉션 후)? (나는 웹 프로그래머가 아니므로 모든 것이 잘못되었을 수도 있습니다.) – fudge

+0

아니요, iframe에 다른 사이트의 콘텐츠가있는 경우 iframe 콘텐츠에 액세스 할 수 없습니다. 같은 기원 정책. – hrnt