오늘날 인터넷과 컴퓨팅 기술의 발달로 인해 고객에게 서비스를 제공하기 위한 여러 형태의 애플리케이션이 존재하며, 이들 중에서 Restful API를 이용하여 외부에 서비스를 제공하는 형태의 애플리케이션이 다수 개발/운영되고 있다. 이 애플리케이션들이 사용자의 인증 수단으로 사용하는 OAuth 프로토콜 중 주로 사용되는 OAuth 2.0 Framework는 많은 조사, 분석 및 연구에 의해 여러 취약점이 발견되었으며 이에 따라 IETF에서는 2013년 이들 취약점을 정리하고 그것을 보완하는 보안 고려사항을 발표하였다. 그럼에도 불구하고 짧은 개발 일정에 대한 부담으로 인한 표준 미 준수, 보안 고려사항 대응책 누락 등 아직도 많은 Restful ...
오늘날 인터넷과 컴퓨팅 기술의 발달로 인해 고객에게 서비스를 제공하기 위한 여러 형태의 애플리케이션이 존재하며, 이들 중에서 Restful API를 이용하여 외부에 서비스를 제공하는 형태의 애플리케이션이 다수 개발/운영되고 있다. 이 애플리케이션들이 사용자의 인증 수단으로 사용하는 OAuth 프로토콜 중 주로 사용되는 OAuth 2.0 Framework는 많은 조사, 분석 및 연구에 의해 여러 취약점이 발견되었으며 이에 따라 IETF에서는 2013년 이들 취약점을 정리하고 그것을 보완하는 보안 고려사항을 발표하였다. 그럼에도 불구하고 짧은 개발 일정에 대한 부담으로 인한 표준 미 준수, 보안 고려사항 대응책 누락 등 아직도 많은 Restful API 애플리케이션들이 보안 고려사항을 준수하지 못한 상태로 개발/운영되고 있으며, 한 부분의 허점으로 인하여 Access Token이 공격자에게 탈취될 경우 보호된 자원이 유출될 수 있다. 이에 따라 본 논문에서는 OTP를 사용함으로서 Access Token뿐만 아니라 그에 관련된 Parameter들이 같이 노출되어도 Client Secret 원문만 탈취되지 않으면 재사용을 할 수 없게 하는 기법 두 가지를 제안한다. Client Secret 원문이 Network상에 노출되지 않아도 Client의 인증을 진행할 수 있는 방안 한 가지와 Access Token 및 다른 Parameter가 Client의 Log 또는 Network상에 노출되어도 그것을 이용한 재생 공격이 어렵게 되는 방안 두 가지를 제안하고 검증한다. 본 논문에서는 기존 OAuth 2.0 Framework를 그대로 구현한 애플리케이션에서 Access Token을 탈취하여 재생 공격이 가능함을 확인하고, 제안을 적용함으로서 재생 공격이 실패함을 확인하는 방법으로 본 논문의 제안을 검증한다. 본 논문에서 제안한 방안의 장단점을 고려하여 적기적소에 적용한다면 Access Token 및 관련 Parameter들이 Network 또는 Log등에서 공격자에게 노출되는 허점이 존재한다고 하더라도 그것을 이용하여 보호된 자원을 탈취하기는 어려울 것이다.
오늘날 인터넷과 컴퓨팅 기술의 발달로 인해 고객에게 서비스를 제공하기 위한 여러 형태의 애플리케이션이 존재하며, 이들 중에서 Restful API를 이용하여 외부에 서비스를 제공하는 형태의 애플리케이션이 다수 개발/운영되고 있다. 이 애플리케이션들이 사용자의 인증 수단으로 사용하는 OAuth 프로토콜 중 주로 사용되는 OAuth 2.0 Framework는 많은 조사, 분석 및 연구에 의해 여러 취약점이 발견되었으며 이에 따라 IETF에서는 2013년 이들 취약점을 정리하고 그것을 보완하는 보안 고려사항을 발표하였다. 그럼에도 불구하고 짧은 개발 일정에 대한 부담으로 인한 표준 미 준수, 보안 고려사항 대응책 누락 등 아직도 많은 Restful API 애플리케이션들이 보안 고려사항을 준수하지 못한 상태로 개발/운영되고 있으며, 한 부분의 허점으로 인하여 Access Token이 공격자에게 탈취될 경우 보호된 자원이 유출될 수 있다. 이에 따라 본 논문에서는 OTP를 사용함으로서 Access Token뿐만 아니라 그에 관련된 Parameter들이 같이 노출되어도 Client Secret 원문만 탈취되지 않으면 재사용을 할 수 없게 하는 기법 두 가지를 제안한다. Client Secret 원문이 Network상에 노출되지 않아도 Client의 인증을 진행할 수 있는 방안 한 가지와 Access Token 및 다른 Parameter가 Client의 Log 또는 Network상에 노출되어도 그것을 이용한 재생 공격이 어렵게 되는 방안 두 가지를 제안하고 검증한다. 본 논문에서는 기존 OAuth 2.0 Framework를 그대로 구현한 애플리케이션에서 Access Token을 탈취하여 재생 공격이 가능함을 확인하고, 제안을 적용함으로서 재생 공격이 실패함을 확인하는 방법으로 본 논문의 제안을 검증한다. 본 논문에서 제안한 방안의 장단점을 고려하여 적기적소에 적용한다면 Access Token 및 관련 Parameter들이 Network 또는 Log등에서 공격자에게 노출되는 허점이 존재한다고 하더라도 그것을 이용하여 보호된 자원을 탈취하기는 어려울 것이다.
Today, due to the development of the Internet and computing technology, there are various types of applications for providing services to customers. Among them, a number of applications that provide services to the outside using Restful API are being developed / operated. The OAuth 2.0 framework, wh...
Today, due to the development of the Internet and computing technology, there are various types of applications for providing services to customers. Among them, a number of applications that provide services to the outside using Restful API are being developed / operated. The OAuth 2.0 framework, which is one of the OAuth protocols that these applications use as authentication methods for users, Numerous investigations, analyzes and studies have found several vulnerabilities. So, the IETF released security considerations that summarized and complemented these vulnerabilities in 2013. Nonetheless, many of the Restful API applications are still being developed and operated in a non-compliant manner due to the lack of standards compliance and the lack of security consideration countermeasures due to the burden of short development schedules, and a loophole in one part may result in a leak of protected resources if an access token is stolen by an attacker. Therefore, in this thesis, if not be exposed the Client Secret, I propose two methods using OTP that can not be reuse Access token despite of the Access Token and its related parameters are exposed together. In this thesis, I propose and verify a way that client authentication can be performed even if the original Client Secret text is not exposed on the network, and two methods that to make hard to replay attack by using Access Token and other parameters that are exposed on the client`s log or network packets. In this thesis, I verify the proposal of this thesis by verifying that a replay attack by taking an access token from the application that implements the existing OAuth 2.0 framework, and verifying that the replay attack fails by applying the proposal of this thesis to the application. If considering the advantages and disadvantages of the proposed method and applying it to the apporopriate time and place, it is difficult to exploit protected resources even if there are loopholes in which access tokens and related parameters are exposed to attackers in the network or log.
Today, due to the development of the Internet and computing technology, there are various types of applications for providing services to customers. Among them, a number of applications that provide services to the outside using Restful API are being developed / operated. The OAuth 2.0 framework, which is one of the OAuth protocols that these applications use as authentication methods for users, Numerous investigations, analyzes and studies have found several vulnerabilities. So, the IETF released security considerations that summarized and complemented these vulnerabilities in 2013. Nonetheless, many of the Restful API applications are still being developed and operated in a non-compliant manner due to the lack of standards compliance and the lack of security consideration countermeasures due to the burden of short development schedules, and a loophole in one part may result in a leak of protected resources if an access token is stolen by an attacker. Therefore, in this thesis, if not be exposed the Client Secret, I propose two methods using OTP that can not be reuse Access token despite of the Access Token and its related parameters are exposed together. In this thesis, I propose and verify a way that client authentication can be performed even if the original Client Secret text is not exposed on the network, and two methods that to make hard to replay attack by using Access Token and other parameters that are exposed on the client`s log or network packets. In this thesis, I verify the proposal of this thesis by verifying that a replay attack by taking an access token from the application that implements the existing OAuth 2.0 framework, and verifying that the replay attack fails by applying the proposal of this thesis to the application. If considering the advantages and disadvantages of the proposed method and applying it to the apporopriate time and place, it is difficult to exploit protected resources even if there are loopholes in which access tokens and related parameters are exposed to attackers in the network or log.
※ AI-Helper는 부적절한 답변을 할 수 있습니다.