📚 글 쓰기 전에

현재는 프로젝트에서 web관련 부분들을 다루고 있는데, 이번에도 security다. (글이 날라가서 두번째 작성중이다. 글이 날라가서 두번째 작성중이다.)

본문

📌 문제점

securityConfig.class를 뜯어보던 중 아래와 같은 코드 한줄이 있었다.

httpSecurity.csrf.disable()

확인해보니 csrf 공격 방어에 대한 비활성화라고 한다. 이걸 왜 비활성화 하지?싶어서 확인해보니 jwt token을 사용하면 이 설정을 비활성화한다고 한다. 주로 세션이나 쿠키 기반의 보안을 사용했을 때 공격을 막아내기 위한 설정이라고 한다.

근데 여기서 드는 의문점이 있었다.
우리 프로젝트에서는 액세스 토큰을 쿠키에 넣고 리프레시 토큰을 레디스에 넣어주고 있었다. 근데 쿠키를 통한 공격을 막는 설정을 비활성화한다고 하는데서 이상함을 느꼈다.

📌 저장 위치

위화감 때문에 확인해보니 csrf를 활성화 했을 때 주로 csrf token이란 것을 사용한다. 근데 지금처럼 액세스 토큰을 쿠키에 넣었다면 csrf 토큰을 사용해야하는 것인가?고민했을 때 중복적이고 번거로운 작업이라고 생각했다. csrf 토큰은 jwt token을 사용한 인증을 할 때 잘 사용하지 않는 방식이라고도 했다.(보안을 위한 보안을 위한 보안..이런 느낌)

그렇다면 지금 액세스 토큰이 csrf 공격에 노출됐다는 상황이 아닌가. 다시한번 저장위치를 고려해야 했다.

📌 공격 방법

저장 위치를 정하기 전에 어떤 방식의 공격이 있는지 먼저 확인하자.

CSRF(Cross-Site Request Forgery)

웹 사이트 취약점 공격의 하나로 사용자가 자신의 의지와는 무관하게 공격자가 의도한 행위(수정, 삭제, 등록 등)를 특정 웹 사이트에 요청하게 하는 공격을 말한다. 쉽게 예시를 들어서 설명하면 아래와 같다.

서버의 기능 중에는 서로에게 송금하는 기능이 있다고 하자. 만약에 공격자가 서버의 송금 uri를 알아내어 자신에게 송금하는 uri를 만들어내고 이를 무작위로 뿌린다. 해당 사이트에 인증이 되어있는 유저들은 링크에 들어가면 공격자에게 "강제"송금 행동을 하게 되는 것이다.

근데 이러한 공격이 가능하려면 인증이 브라우저에 저장되어있어야하고, 서버에서도 인증을 브라우저에서 가져와야한다. 공격자는 서버의 이런 취약점을 알아내어 행동 하는 것이다.

XSS(Cross Site Scripting)

csrf에서 브라우저에 저장되어있는 인증을 통해 강제 행동을 하게 했다면, xss는 공격자가 작성한 악성 스크립트를 통해 직접 인증을 탈취하는 행동이다. 둘의 차이점은 인증을 탈취하는 공격이냐 아니면 인증을 가지고 있는 상태를 이용한 공격이냐이다. (전자는 xss,후자는 csrf)

📌 Access Token

액세스 토큰은 로컬 private 변수에 저장하기로 했다. 로컬 storage에 저장하면 csrf 공격을 피할 수 있지만 xss 공격에 취약하다는 점이 문제였는데, 이를 private변수에 저장한다면 어느정도 문제를 해결할 수 있다고 한다. 그리고 access의 만료 시간을 짧게 한다면 xss문제점에서 더욱 도움이 될 것이다.

📌 Refresh Token

리프레시는 쿠키에 저장할 것이다.

액세스 토큰을 원래 쿠키에 넣었었고, 이것이 csrf공격의 문제가 될 수 있다고 했으면서 왜 리프레시는 쿠키에 넣는가하면. 리프레시 토큰 자체는 인증이 되지 않는다. 리프레시를 통해 다시 액세스 토큰을 발급 받을 수 있는것이지, 그자체에 인증이 되지 않는다는 것이다.

쿠키를 탈취할 수 있기 때문에, httpOnly설정과 Secure 설정을 해주도록 한다. httpOnly는 자바스크립트로 클라이언트의 쿠키를 조회하는 것을 막는 옵션이며 secure은 클라이언트의 웹 브라우저 환경과 https통신에서만 쿠키를 서버로 전송하는 옵션이다.

📙 글을 마치면서

프로젝트를 진행하면서 정답이 없는 경우가 더 많아지는 것 같다. 어떤 것을 중점으로 볼 것인지가 기본적인 태도로 잡혀야 하며 무게를 재기 위해 검색하는 시간이 엄청 길어졌다.

사실 대중의 선택이 주로 정답이기는 하다만 직접 결정을 내려보고 나중에 몸소 체감하는 것도 굉장히 도움이 되는 것 같다. 좋은 선택지만 보면 그게 진짜 좋은 건지 느껴지지 않는 것 같기도 하고.

이번 jwt token 저장 위치만 몇번을 바꾸고 있는지 모르겠는데, 매번 새롭다. 그래도 점점 spring security와 친밀해져가고 있다는 생각이 든다.아마도?