많은 웹 서비스가 OAuth 프로토콜을 이용하여 리소스 서버로부터 프로필 정보를 전달받아 사용자를 로그인시켜주는 형태로 제공되어 추가적인 회원가입의 불편함을 줄여주고 있다. 하지만, 작업을 종료한 사용자가 클라이언트 웹 서비스를 로그아웃하더라도 리소스 서버가 로그인 상태로 남아 사용자의 개인정보 및 리소스 서버 자원 유출에 대한 문제가 발생할 수 있다. 본 논문에서는 OAuth 프로토콜을 통해 로그인한 사용자가 클라이언트에서 로그아웃할 경우, 리소스 서버의 로그인 상태에 관한 알림을 통하여 사용자가 리소스 서버의 로그아웃 여부를 판단할 수 있도록 설계 및 구현하였다. 본 논문에서 제안하는 방법을 활용하여 OAuth 프로토콜을 통해 로그인한 사용자가 도서관, 백화점, 인쇄소와 같이 여러 사용자가 이용하는 공용 PC 환경에서 리소스 서버에 로그아웃 여부를 확인하지 않아 발생할 수 있는 정보유출 문제를 줄이고 리소스 서버의 자원을 보호할 수 있다.
많은 웹 서비스가 OAuth 프로토콜을 이용하여 리소스 서버로부터 프로필 정보를 전달받아 사용자를 로그인시켜주는 형태로 제공되어 추가적인 회원가입의 불편함을 줄여주고 있다. 하지만, 작업을 종료한 사용자가 클라이언트 웹 서비스를 로그아웃하더라도 리소스 서버가 로그인 상태로 남아 사용자의 개인정보 및 리소스 서버 자원 유출에 대한 문제가 발생할 수 있다. 본 논문에서는 OAuth 프로토콜을 통해 로그인한 사용자가 클라이언트에서 로그아웃할 경우, 리소스 서버의 로그인 상태에 관한 알림을 통하여 사용자가 리소스 서버의 로그아웃 여부를 판단할 수 있도록 설계 및 구현하였다. 본 논문에서 제안하는 방법을 활용하여 OAuth 프로토콜을 통해 로그인한 사용자가 도서관, 백화점, 인쇄소와 같이 여러 사용자가 이용하는 공용 PC 환경에서 리소스 서버에 로그아웃 여부를 확인하지 않아 발생할 수 있는 정보유출 문제를 줄이고 리소스 서버의 자원을 보호할 수 있다.
Many web services which use OAuth Protocol offer users to log in using their personal profile information given by resource servers. This method reduces the inconvenience of the users to register for new membership. However, at the time a user finishes using OAuth client web service, even if he logs...
Many web services which use OAuth Protocol offer users to log in using their personal profile information given by resource servers. This method reduces the inconvenience of the users to register for new membership. However, at the time a user finishes using OAuth client web service, even if he logs out of the client web service, the resource server remained in the login state may cause the problem of leaking personal information. In this paper, we propose a solution to mitigate the threat by providing an additional security behavior check: when a user requests to log out of the Web Client service, he or she can make decision whether or not to log out of the resource server via confirmation notification regarding the state of the resource server. By utilizing the proposed method, users who log in through the OAuth Protocol in the public PC environment like department stores, libraries, printing companies, etc. can prevent the leakage of personal information issues that may arise from forgetting to check the other OAuth related services. To verify our study, we implement a Client Web Service that uses OAuth 2.0 protocol and integrate it with our security behavior check. The result shows that with this additional function, users will have a better security when dealing with resource authorization in OAuth 2.0 implementation.
Many web services which use OAuth Protocol offer users to log in using their personal profile information given by resource servers. This method reduces the inconvenience of the users to register for new membership. However, at the time a user finishes using OAuth client web service, even if he logs out of the client web service, the resource server remained in the login state may cause the problem of leaking personal information. In this paper, we propose a solution to mitigate the threat by providing an additional security behavior check: when a user requests to log out of the Web Client service, he or she can make decision whether or not to log out of the resource server via confirmation notification regarding the state of the resource server. By utilizing the proposed method, users who log in through the OAuth Protocol in the public PC environment like department stores, libraries, printing companies, etc. can prevent the leakage of personal information issues that may arise from forgetting to check the other OAuth related services. To verify our study, we implement a Client Web Service that uses OAuth 2.0 protocol and integrate it with our security behavior check. The result shows that with this additional function, users will have a better security when dealing with resource authorization in OAuth 2.0 implementation.
* AI 자동 식별 결과로 적합하지 않은 문장이 있을 수 있으니, 이용에 유의하시기 바랍니다.
문제 정의
본 논문에서 리소스 서버의 사용자 자원 보호를 위해 사용자의 클라이언트 웹 서비스 로그아웃 요청시, OAuth 2.0 프로토콜을 이용하여 서비스에 로그인한 사용자를 대상으로 리소스 서버의 로그아웃여부 확인을 요구하는 방법을 제안 및 구현하였다. 제안하는 방법을 사용하게 된다면 로그아웃 이후 사용자가 자신의 리소스 서버에 로그아웃 유무를 쉽게 판단할 수 있어 자신이 추가로 이를 이용한 웹 서비스를 사용하려 한다면 유지하고 만약 사용하지 않고 종료하여야 하는 경우에는 로그아웃하여 공공장소와 같은 PC환경에서 자신의 로그인 상태를 쉽게 확인할 수 있다는 점에서 강점을 가지고 있다.
본 논문에서는 OAuth 프로토콜을 통해 로그인한 사용자가 클라이언트를 로그아웃할 경우, [Fig. 6]과 같이 클라이언트 서비스가 사용자에게 리소스 서버의 상태를 환기할 수 있는 알림을 통하여 위협을 예방할 것을 제안한다.
0 프로토콜을 이용한 로그인을 통해 클라이언트 웹 서비스를 이용할 때, 사용자 부주의로 인하여 로그인 상태의 리소스 서버를 남겨두고 자리를 떠난다면 다음 사용자에 의해 사용자 개인 정보 및 문서, 사진 등과 같은 사용자의 중요한 자원이 탈취될 수 있다. 본 논문에서는 리소스 서버의 로그인 상태로 인해 발생할 수 있는 위협을 소개하고 이러한 위협을 해결하기 위하여 클라이언트 사용자에게 메시지를 통한 알림으로 로그아웃 여부를 판단할 수 있게 제안하였으며 시스템을 구현하였다. 본 시스템은 로그인된 사용자에게 간단한 게시판을 제공할 수 있는 클라이언트 웹 서비스를 구축하였으며 Google에 클라이언트 등록 및 OAuth 2.
본 논문에서는 클라이언트 웹 서비스의 로그아웃 후, 로그인 상태의 리소스 서버로 인하여 클라이언트웹 서비스 재로그인 및 개인정보 탈취 문제 발생 위협을 해결하기 위하여 알림 기법을 제안한다. 이러한 내용은 OAuth 프로토콜의 취약점 및 안전성에 제안되어 있지 않은 새로운 취약점으로 추후 클라이언트 측에서 개발, 적용이 필요한 내용이다.
제안 방법
본 논문에서는 OAuth 2.0 프로토콜을 통한 로그인으로 클라이언트 웹 서비스를 이용한 사용자가 로그아웃을 요청할 때, 사용자에게 알림을 제공함으로써 리소스 서버의 상태를 판단할 수 있게 하였다. 클라이언트 웹 서비스의 사용자가 로그아웃 요청을 할경우의 과정을 [Fig.
본 논문에서는 리소스 서버의 로그인 상태로 인해 발생할 수 있는 위협을 소개하고 이러한 위협을 해결하기 위하여 클라이언트 사용자에게 메시지를 통한 알림으로 로그아웃 여부를 판단할 수 있게 제안하였으며 시스템을 구현하였다. 본 시스템은 로그인된 사용자에게 간단한 게시판을 제공할 수 있는 클라이언트 웹 서비스를 구축하였으며 Google에 클라이언트 등록 및 OAuth 2.0 라이브러리 적용을 통하여 동작이 가능하도록 하였다. 또한, 클라이언트 웹 서비스 이용이 끝난 사용자가 로그아웃을 누를 경우 팝업 형태의 메시지를 통하여 리소스 서버의 로그아웃을 제어할 수 있다.
사용자의 로그아웃 요청 시 리다이렉트 및 팝업 형태의 정보를 알림으로써 리소스 서버의 상태를 사용자가 직접 판단할 수 있도록 하였다. 본 장에서는 사용자의 판단 없이 리소스 서버를 자동 로그아웃시켰을 때 발생 가능한 문제에 대해 논의한 후, 자동 로그아웃이 아닌 사용자에게 리소스 서버의 로그인 상태 확인을 촉구시키며 선택적으로 리소스 서버를 로그아웃 시킬 수 있는 방법에 대하여 제안한다.
본 장에서는 웹 서비스를 이용한 서비스 이용 종료 후 발생할 수 있는 위협을 설명한다[15]. 사용상 발생 가능한 위협을 설명하기 위해 OAuth 프로토콜을 이용하여 클라이언트 웹 서비스에 로그인하는 사용자의 관점에 관해 설명한다. 그러고 나서 도서관, 백화점, 인쇄소와 같이 공용 PC 환경에서 발생할 수 있는 재로그인 문제와 리소스 서버 자원 노출문제에 관하여 설명한다.
이러한 내용은 OAuth 프로토콜의 취약점 및 안전성에 제안되어 있지 않은 새로운 취약점으로 추후 클라이언트 측에서 개발, 적용이 필요한 내용이다. 사용자의 로그아웃 요청 시 리다이렉트 및 팝업 형태의 정보를 알림으로써 리소스 서버의 상태를 사용자가 직접 판단할 수 있도록 하였다. 본 장에서는 사용자의 판단 없이 리소스 서버를 자동 로그아웃시켰을 때 발생 가능한 문제에 대해 논의한 후, 자동 로그아웃이 아닌 사용자에게 리소스 서버의 로그인 상태 확인을 촉구시키며 선택적으로 리소스 서버를 로그아웃 시킬 수 있는 방법에 대하여 제안한다.
제안하는 시스템의 경우, 기존의 OAuth의 취약점에서 분석하지 못한 새로운 취약점에 대한 대응책을 제시하였다. OAuth 프로토콜을 사용자 인증으로 활용하였을 경우, 클라이언트 서비스의 사용을 종료한 사용자가 로그아웃을 요청하면 클라이언트는 로그아웃 되지만 개인정보를 보관하는 리소스 서버는로그인 상태로 유지되는 문제가 있었다.
성능/효과
OAuth 프로토콜을 이용하여 클라이언트 서비스를 이용한 사용자는 클라이언트의 사용 종료 후 리소스 서버의 로그아웃 상태를 직접 확인해야 하지만 제안하는 프로토콜은 리소스 서버가 로그인 상태로 남아있을 수 있음을 환기시킨다. 또한, OAuth 프로토콜은 리소스 서버의 로그아웃을 위하여 직접 리소스서버를 방문해야 하지만 제안하는 프로토콜은 사용자가 리소스 서버의 추가적인 이용 여부 등을 판단하여 클라이언트에서 리소스 서버가 즉각 로그아웃이 되도록 설정할 수 있어 기존 OAuth보다 효율적이고 안전하게 개인정보를 보호할 수 있다.
다음 사용자가 클라이언트웹 서비스를 이용하기 위하여 같은 IdP로의 인증을 희망할 경우, 로그인된 리소스 서버 상태 때문에 다음 사용자는 리소스 서버의 로그인 절차 없이 클라이언트 웹 서비스에 로그인할 수 있다. 그리고 기존 사용자의 클라이언트 웹 서비스 히스토리 등의 이용 정보를 탈취할 수 있으며, 클라이언트 웹 서비스를 이용하는 것이 아닌 리소스 서버를 이용할 목적으로 리소스 서버 웹 페이지에 방문할 경우, [Fig. 3]과 같이 이미 로그인 되어있는 리소스 서버의 기존 사용자 정보와 중요 자원을 탈취당할 수 있다.
OAuth 프로토콜을 이용하여 클라이언트 서비스를 이용한 사용자는 클라이언트의 사용 종료 후 리소스 서버의 로그아웃 상태를 직접 확인해야 하지만 제안하는 프로토콜은 리소스 서버가 로그인 상태로 남아있을 수 있음을 환기시킨다. 또한, OAuth 프로토콜은 리소스 서버의 로그아웃을 위하여 직접 리소스서버를 방문해야 하지만 제안하는 프로토콜은 사용자가 리소스 서버의 추가적인 이용 여부 등을 판단하여 클라이언트에서 리소스 서버가 즉각 로그아웃이 되도록 설정할 수 있어 기존 OAuth보다 효율적이고 안전하게 개인정보를 보호할 수 있다.
제안하는 방법을 사용하게 된다면 로그아웃 이후 사용자가 자신의 리소스 서버에 로그아웃 유무를 쉽게 판단할 수 있어 자신이 추가로 이를 이용한 웹 서비스를 사용하려 한다면 유지하고 만약 사용하지 않고 종료하여야 하는 경우에는 로그아웃하여 공공장소와 같은 PC환경에서 자신의 로그인 상태를 쉽게 확인할 수 있다는 점에서 강점을 가지고 있다. 또한, 본 논문에서 제안하는 방법을 이용하여, 회원가입 없이 OAuth 프로토콜을 이용하여 로그인한 사용자의 리소스 서버 자원을 보호할 수 있다.
본 논문은 OAuth 2.0 프로토콜이 구현된 클라이언트 웹 서비스에 로그인한 사용자의 브라우저에서 로그인 과정 후 보이지 않는 리소스 서버가 지속적으로 로그인 되어있음을 확인하였다. 사용자가 리소스 서버에 로그인한 주요 목적은 클라이언트를 이용하는 것으로 사용자가 리소스 서버 상태를 인지하기 어렵다.
0 프로토콜을 이용하여 서비스에 로그인한 사용자를 대상으로 리소스 서버의 로그아웃여부 확인을 요구하는 방법을 제안 및 구현하였다. 제안하는 방법을 사용하게 된다면 로그아웃 이후 사용자가 자신의 리소스 서버에 로그아웃 유무를 쉽게 판단할 수 있어 자신이 추가로 이를 이용한 웹 서비스를 사용하려 한다면 유지하고 만약 사용하지 않고 종료하여야 하는 경우에는 로그아웃하여 공공장소와 같은 PC환경에서 자신의 로그인 상태를 쉽게 확인할 수 있다는 점에서 강점을 가지고 있다. 또한, 본 논문에서 제안하는 방법을 이용하여, 회원가입 없이 OAuth 프로토콜을 이용하여 로그인한 사용자의 리소스 서버 자원을 보호할 수 있다.
후속연구
본 논문에서 제시한 위협을 해결하기 위하여 사용자의 클라이언트 웹 서비스 로그아웃 요청으로 리소스 서버를 함께 로그아웃시키는 방법을 고안할 수 있다. 클라이언트 서비스에서 지원하는 OAuth 프로토콜을 통하여 사용자가 리소스 서버를 로그인한 주요 목적은 클라이언트 웹 서비스에 로그인하기 위한 것이며, 사용자는 리소스 서버가 로그인 상태로 남는 것을 원하지 않을 수 있다.
본 논문에서는 클라이언트 웹 서비스의 로그아웃 후, 로그인 상태의 리소스 서버로 인하여 클라이언트웹 서비스 재로그인 및 개인정보 탈취 문제 발생 위협을 해결하기 위하여 알림 기법을 제안한다. 이러한 내용은 OAuth 프로토콜의 취약점 및 안전성에 제안되어 있지 않은 새로운 취약점으로 추후 클라이언트 측에서 개발, 적용이 필요한 내용이다. 사용자의 로그아웃 요청 시 리다이렉트 및 팝업 형태의 정보를 알림으로써 리소스 서버의 상태를 사용자가 직접 판단할 수 있도록 하였다.
질의응답
핵심어
질문
논문에서 추출한 답변
OAuth 2.0 프로토콜은 무엇인가?
OAuth 2.0 프로토콜은 서비스 간 계정 정보공유 없이 사용자의 리소스 서버 자원에 접근할 수 있는 권한인가를 지원하는 하는 표준이다[3]. 이러한 OAuth 2.
OAuth 2.0프로토콜 기반의 SSO 기능을 이용하는 클라이언트가 가지는 이점은 무엇인가?
① 추가적인 회원가입 과정 없이 리소스 서비스의회원이 클라이언트의 회원이 될 수 있음
② 클라이언트는 복잡한 개인정보를 관리 할 필요가 없음
③ 계정정보 분실, 사용자 문의 등 회원관리를 위한 인증 비용 (SMS, ARS 등)은 리소스 서버가 부담함
많은 클라이언트들은 OAuth 2.0 프로토콜을 이용하여 어떤 서비스를 제공하는가?
하지만, 많은 클라이언트는 OAuth 2.0 프로토콜을 이용하여 페이스북, 구글, 네이버와 같은 많은 양의 사용자 정보를 보유한 IdP (IdentityProvider)로부터 프로필 정보를 전달받아 사용자를 로그인 시켜주는 형태로 서비스하고 있다[2,4,5]. 사용자는 클라이언트에서 로그인을 수행할 IdP를 선택하고 리다이렉트를 통하여 IdP의 로그인 페이지에서 사용자의 계정 정보를 이용한 로그인을 수행한다.
참고문헌 (16)
I. Faynberg, H. Lu, and H. Ristock, "On Dynamic Access Control in Web 2.0 and Beyond: Trends and Technologies," BELL LABS Technical Journal, vol. 16, no. 2, pp. 199-218, Sep. 2011.
D. Fett, R. Kusters, and G. Schmitz, "SPRESSO: A Secure, Privacy-Respecting Single Sign-On System for the Web," In Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security, pp. 1358-1369, Oct. 2015.
D. Hardt, Ed., "The OAuth 2.0 Authorization Framework," Internet Engineering Task Force (IETF) RFC 6749, Oct. 2012.
R. Wang, S. Chen, and X. Wang, "Signing Me onto Your Accounts through Facebook and Google: a Traffic-Guided Security Study of Commercially Deployed Single-SignOn Web Services," In Proceedings of the IEEE Symposium on Security and Privacy, pp. 365-379, May. 2012.
C. Bansal, K. Bhargavan, and S. Maffeis, "Discovering Concrete Attacks on Website Authorization by Formal Analysis," In Proceedings of the IEEE 25th Computer Security Foundations Symposium, pp. 247-262, Jun. 2012.
OAuth Community Reports, "User Authentication with OAuth 2.0," http://oauth.net/articles/authentication (accessed June 9, 2016).
Eran Hammer, "OAuth 2.0 and the Road to Hell," https://hueniverse.com /2012/07/26/oauth-2-0-and-the-road-to -hell (accessed June 9, 2016).
R. Wang, Y. Zhou, Ed., and Y. Gurevich, "Explicating SDKs: Uncovering Assumptions Underlying Secure Authentication and Authorization," In Proceedings of the 22nd USENIX Security Symposium, pp. 399-414, Aug. 2013.
S. Sun and K. Beznosov, "The Devil is in the (Implementation) Details: An Empirical Analysis of OAuth SSO Systems," In Proceedings of ACM Conference on Computer and Communications Security, pp. 378-390, Oct. 2012.
T. Lodderstedt, Ed., "OAuth 2.0 Threat Model and Security Considerations," Internet Engineering Task Force (IETF) RFC 6819, Jan. 2013.
E. Ferry, and J. O Raw, "Security evaluation of the OAuth 2.0 framework," Information & Computer Security, vol. 23, no. 1, pp. 73-101, 2015.
D. Fett, R. Kusters, and G. Schmitz, "A Comprehensive Formal Security Analysis of OAuth 2.0," Technical Report, pp. 1-90, May 2016.
M Jones, Ed., "OAuth 2.0 Mix-Up Mitigation," Internet Engineering Task Force (IETF) draft-jones-oauthmix-up-mitigation-01, Jan. 2016.
NaverLogin Guide. "Sign in with NAVER," http://developer.naver.com/ wiki/pages/NaverLogin (accessed June 9, 2016).
J. Kim, J. Park, L. Nguyen_Vu and S. Jung, "An Incomplete Logout problem after using OAuth access token for system Login," In Proceedings of APIC-IST 2016, Jun, 2016.
T. Lodderstedt, Ed., "OAuth 2.0 Token Revocation," Internet Engineering Task Force (IETF) RFC 7009, Aug, 2013.
※ AI-Helper는 부적절한 답변을 할 수 있습니다.