JWT 관리와 탈취대응 시나리오 ( 2 )

토큰기반의 인증 전략에 대해 고민해본 글 입니다.

 

 

이전 글에서 RTR이 토큰 탈취 대응 방안으로 어느정도 효과가 있는지 알아보았습니다.

여러가지 문제가 있었지만 간략 하게 정리하면 아래와 같습니다.

 

• RTR은 일부 케이스에선 효과가 있지만 그리 효과적이지는 못한 것 같다.
• XSS 공격에는 여전히 취약하다. 대부분 방어가 되어있긴 하지만 일부 취약한 부분도 있다. 
• 어느정도 양보하면 세션과 다를게 없어진다.

그리하여 새로운 전략에 대해 이야기 해보려 합니다.

 

Http Only

리프레시 토큰을 쿠키에 담아 보내는 방식 입니다. http only 속성을 부여하여 자바스크립트로 접근할 수 없도록 설정하는 방식입니다.

우선 자바스크립트로 접근 할 수 없기 때문에 여기서 대부분의 보안 취약점은 해결이 된 모습입니다.

 

덕분에 XSS 공격에도 대응이 가능해졌습니다.

하지만, 

웹 보안 이슈 단골손님 csrf가 기다리고 있습니다.

 

해커가 만든 피싱 사이트 url을 클릭 하고 해커가 미리 삽입해둔 태그에서 발생한 요청에 의해 정상 유저인 것 처럼 둔갑되어 버립니다.

 

 

엑세스 토큰에 고유정보 기록

엑세스 토큰에 고유정보를 기록하는 방식입니다.토큰을 발급 할 때 요청을 보낸 사람의 브라우저, IP, 디바이스 종류 등 비교적 덜 민감한 요소들을 기록합니다.

 

이후 재발급 요청을 받으면 고유정보를 다시 확인하고 이 정보가 매칭이 되지 않는다면 재발급 요청에 응하지 않는 방식 입니다.물론 IP 같은 경우에는 다소 민감한 요소로 분류될 수도 있지만, 이름, 주민번호, 휴대폰 번호 정도의 민감성은 없다고 판단됩니다.

 

이 방식은 토큰을 직접 해독하여 기록된 정보를 알아내지 않는 이상 다른 세부정보를 모두 알아내기가 쉽지 않습니다.

 

 

 

결론

세션도 그렇고 토큰도 그렇고 완벽한건 없는 것 같습니다.

개인적으로 비용이 더 들더라도 각 전략의 장점을 적절히 섞어 안전한 방법을 모색하고,

Google Authenticator 같은 멀티팩터 인증을 적극적으로 활용하면 좋을 것 같다는 생각입니다.