4월 3주차 주간회고

저번주에는 JWT의 취약한 부분들을 찾아보고, 어떻게 취약점을 보완할지 고민해보았다.

이번주에는 고민한 내용들을 실제로 적용해 보았는데, JWT뿐만 아니라 쿠키에 대한 이해도 좀 더 높일 수 있었다.

토큰 전달 방법 선택

리프레쉬 토큰을 적용하면서, 먼저 리프레쉬 토큰을 어떻게 클라이언트에게 전달해줄지 고민을 해보았다.

토큰을 응답 바디로 주는 방법과 쿠키에 담아서 전달하는 방법이 있고 장단점은 다음과 같다.

 

쿠키 방식 장점

- http only 옵션을 이용해 스크립트 공격을 막을 수 있음

 

쿠키 방식 단점

- 일부 브라우저는 쿠키를 사용하지 않도록 설정 되어있을 수 있기 때문에 CORS문제가 발생할 수 있다.

- 인증된 사용자 권한을 이용해 위조된 요청을 보내는 CSRF공격에 취약하다.

 

응답 바디 방식 장점

- CORS문제에서 비교적 자유롭다.

 

응답 바디 방식 단점

응답 바디로 주게되면 XSS공격으로 토큰을 탈취당할 수 있다.

 

각각 방식의 장단점을 고려해보았고 만료시간이 짧은 액세스 토큰을 응답 바디를 이용해서 전달하고, 만료시간이 길어 탈취당하면 위험한 리프레쉬 토큰을 http only 쿠키에 넣어 전달하는게 안전하다는 생각이 들었다. 하지만 쿠키의 CSRF 취약성을 해결해주기 위한 방법이 필요했다.

 

CSRF 취약성 해결하기

쿠키를 안전하게 사용하기 위해 SameSite쿠키 옵션을 이용했다.

SameSite쿠키 옵션이란 쿠키를 전송할 때 SameSite 설정값에 따라 다른 도메인에서의 요청에서 쿠키가 전송되는 것을 방지하는 옵션이다.

 

세가지 옵션이 존재한다.

None => SameSite 설정을 적용하지 않는다. 크로스 사이트 요청에서 쿠키를 자유롭게 전송할 수 있다.

Strict => 다른 도메인의 요청에서 쿠키를 전송하지 않는다.

Lax => 다른 도메인에서의 POST요청에서는 쿠키를 전송하지 않지만 GET 요청에서는 쿠키전송을 허용한다.

 

이중 가장 안전한 것은 Strict이지만, 리프레쉬 토큰을 서버에서 확인해야 하므로 유연한 Lax옵션을 이용해 SameSite쿠키를 구현해주었다.

 

이러한 방식을 이용해 JWT의 취약점을 보완한 인증 / 인가 시스템을 구현했다.

 

좋았던 점

이번주 쿠키를 직접 써보면서 쿠키에 대한 오해를 많이 해소한 것 같아서 좋았다.

쿠키를 처음 배웠을 때는 클라이언트 측에 저장되기 때문에 굉장히 취약한 도구로 알고 있었는데, 어떤 옵션을 선택하는가에 따라 적절한 보안수준을 달성할 수 있었다.

 

앞으로도 궁금한 것들이 생기면 직접 써보면서 효과적인지 판단해보자.

 

다음주는 평소 가고싶었던 기업의 과제테스트가 있어 과제테스트에 집중하게 될것 같다. 다음주도 화이팅!