사람들과 대화를 해보거나 물어보면 Tocken전송을 통한 인가(Jwt Tocken)에 대해서 보안적인 측면은 생각하지 않고 개발하시는 분들이 많은것 같다.
그렇다면 Tocken전송을 통한 인가는 항상 옳은가? why로 시작해보겠다.
oauth2.0 간편 로그인 토큰
네이버 간편 로그인을 보면 일반적인 oauth 2.0 방식의 흘러가는 흐름을 파악할수 있다.
그 순서를 표현하면 다음과 같다.
- 미리 신청해 발급받은 key를 통한 인가코드 받기.
- 발급 받은 인가코드를 통한 Access Token과 Refresh Tocken받기.
- Access Token을 통한 User 정보 받기.
현 시대에서 고객 데이터 유출은 기업이미지에 심각한 초래를 유발할수 있다. 그렇다면 이를 방지해야 한다는 의미이다.위와 같은 순서에서 발생할수 있는 취약 포인트에 대해서 생각해보자.
인가코드를 받는 와중에 발생하는 인증 key값의 유출
하나의 예시를 들어야 하므로, 카카오의 간편 로그인 방식을 예시로 설명하겠다.
일단 중간에 전송되는 패킷을 가로채서 패킷 내용을 확인하는 것부터가 1차적인 문제이다.
왜냐하면, HTTPS의 경우 SSL 프로토콜을 사용하므로, 패킷 자체의 내용부터가 암호화되어 있기 때문이다.
암호화를 풀어야 하는 1차적인 문제에 직면한다. 하지면 어떻게 암호화를 풀고 인증 Key값을 Hacker쪽에서 얻었다고 가정하자.
카카오의 경우, 인가코드를 요청하기 위해서는 다음과 같은 정보가 필요하다.
그 중에서 redirect_uri항목과 state항목을 살펴보자.
redirect_uri referer check를 통한 1차 보안
카카오의 경우, Redirect URI를 관리 사이트에서 등록을 해줘야 한다.
그래서 파라미터로 해당 사이트에 등록된 Redirect URI로 Redirect URI 파라미터가 전송되어야만 응답을 해준다. 아니라면 401 Not Authorized error 메시지를 보게 될것이다.
즉, 이말은 해커 입장에서 해당 인가코드를 탈취하더라도 관리사이트에서 Redirect URI를 등록해야 한다는 의미이다.
이 부분부터 이미 넌센스라고 생각한다.
state parameter를 통한 2차 보안
위를 살펴보면, state를 파라미터로 전송해준다.
응답값으로는,
code, state값을 전송해준다. 처음 전송해준 state를 다시 전송해준다는 의미이다.
즉, 처음 전송한 state가 중간에 위변조가 되었는지 확인을 할수 있다는 의미이고 위변조 여부를 확인하여 탈취여부를 확인할수 있다는 의미이다.
그렇기에 state를 2차보안으로 사용한다.
인가코드를 받은 후 토큰 발급 과정에서의 토큰 탈취(Access Tocken, Refresh Tocken)
해커는 위와 같은 과정에 의해 막혀서, 이제 2차과정은 토큰 탈취의 과정을 노릴 것이다. 토큰 역시 탈취가 가능한지 보자.
역시나 해커는 HTTPS에 의한 SSL 프로토콜을 1차적으로 뚫어야 한다.
그리고 Client_id값을 얻었다고 가정하자.
일단 요청값으로는 다음의 파라미터들을 요청한다.
redirect_uri referer check를 통한 1차 보안
위와 같다. 관리 사이트를 해킹해야 한다.
client-secret check를 통한 2차 보안
추가적인 파라미터로 Client Scret를 전송하고 서버쪽에서는 값에 대한 인증을 한다. 그렇기에 해당 파라미터에 대한 정보는 '인증' 검증의 한 종류로 여겨진다.
그렇기에 주기적으로 해당 정보를 재발급을 통해 변경해줘야 한다.
인가코드(Authentication code) check를 통한 3차 보안
1차과정에서 받았던 인가코드를 같이 보내줘야 마찬가지로 인증을 시도한다. 그렇기에 인가코드의 정보까지 요구하며 검증의 한 종류로 사용한다.
Access Token, Refresh Tocken, expires_in값을 얻는다. 카카오의 경우 Access Token의 유지 시간은 4시간이다.
유저 정보를 얻는 과정에서의 토큰 탈취(Access Tocken, Refresh Tocken)
Access Tocken 탈취
발급 받은 Access Token을 통해, 유저 정보를 요청한다. 요청 파라미터는 다음과 같다.
이 부분에서 나는 가장 크게 보안적인 이슈가 있다고 생각한다.
SSL 프로토콜을 뚫고, Access Tocken을 탈취 당하면 해커는 이 Access Token을 통해 유저 정보를 요청할수 있다.
Access Token 유효 시간의 최소화를 통한 1차 보안
Access Tocken에 대한 탈취 가능성을 염두해두고, 토큰의 발급 시간을 최소화한다.
그리고 처음 같이 발급한 Refresh Tocken을 통해, Access Tocken의 재발급을 하도록 강제한다.
그 내용을 표현하면 다음과 같다.
위의 그림을 보면 쉽게 이해할수 있다.
- Acess Tocken, Refresh Tocken발급
- Access Tocken이 만료라면, Refresh Tocken 전송
- Refresh Tocken을 통한 Access Tocken 재발급
그럼으로, Acess Tocken의 유효기간을 최소화하여, 탈취 당하더라도 사용할수 있는 시간을 최소화 하는 것이다.
refresh Tocken 탈취
refresh Tocken을 통한 재발급시 응답 항목을 보면 refresh_tocken이 있는걸 확인할수 있습니다.
이는 refresh Tocken Rotation기법을 활용한 결과이다.
해커는 refresh tocken을 탈취시 그 기간동안 지속적으로 access tocken발급을 요청할수 있습니다. 그렇기에 한번 이상의 refresh tocken발급시 탈취된것으로 가정하고, 발급된 모든 Refresh tocken들을 폐기처리하고 새로운 Refresh tocken을 발급해주는 것이다.
결론
- 토큰 전송은 항상 옳은 것은 아니다. 언제나 탈취의 위험성은 존재한다. 하지만, 보안과 성능의 적절한 타협이 이루어낸 결과물이다.
- 그렇기에, 추가적인 보안을 하려고 한다면 유효시간, 발급 횟수등을 통해 서버에서의 점검을 실행한다.
- 아니라면, 접속 IP를 통해 인증을 시도한다. 접속 IP가 일치하지 않으면 로그아웃 하는 경우이다.
- 네이버의 경우, 새로운 기기에서 로그인을 시도하면 새로운 환경에서 로그인이 되었다는 알림창과 로그인을 유지할지의 여부를 묻는걸 많이 보았을 것이다.
- 그렇기에 토큰 사용으로 얻는 이득과 실을 잘 판단해서 Tocken을 이용한 방식을 도입할지 하지 않을지 잘 결정해야 한다.
'보안' 카테고리의 다른 글
| CSAP VS CVE (0) | 2023.08.24 |
|---|---|
| Iaas vs Paas vs Saas (0) | 2022.08.05 |
| 0. 암호화 복호화 (0) | 2022.06.09 |
