[etc] 브라우저 저장소 종류와 보안 이슈
😱 브라우저 저장소 종류와 보안 이슈
1. LocalStorage 저장 방식
브라우저 저장소에 저장하는 방식이다. Javascript 내 글로벌 변수로 읽기 / 쓰기 접근이 가능 하다.
😈 : localStorage 안에 세션 id, refreshToken 또는 accessToken을 저장해두면 XSS 취약점을 통해 그 안에 담긴 값을 불러오거나, 불러온 값을 이용해 API 콜을 위조할 수 있다.
2. 쿠키 저장 방식
브라우저에 쿠키로 저장되는데, 클라이언트가 HTTP 요청을 보낼 때마다 자동으로 쿠키가 서버에 전송된다. Javascript 내 글로벌 변수로 읽기/쓰기 접근이 가능하다.
😈 : 쿠키 저장 방식 역시 안에 세션 id, refreshToken, accessToken을 저장해두면 XSS취약점이 있을 때 담긴 값들을 불러오거나, API 콜을 보내면 쿠키에 담긴 값들이 함께 전송되어 로그인한 척 공격을 수행할 수 있다.
😈 : 쿠키에 세션 id나 accessToken을 저장해 인증에 이용하는 구조에 CSRF 취약점이 있다면 인증 정보가 쿠키에 담겨 서버로 보내진다. 공격자는 유저 권한으로 정보를 가져오거나 액션을 수행할 수 있다.
😇 : 쿠키에 refreshToken만 저장하고 새로운 accessToken을 받아와 인증에 이용하는 구조에서는 CSRF 취약점 공격을 방어할 수 있다. refreshToken으로 accessToken을 받아도 accessToken을 스크립트에 삽입할 수 없다면 accessToken을 사용해 유저정보를 가져올 수 없기 때문이다.
3. HttpOnly 쿠키 저장 방식
브라우저에 쿠키로 저장되는 건 같지만, Javascript 내에서 접근이 불가능 하다.
😇 : httpOnly 쿠키 방식으로 저장된 정보는 XSS취약점 공격으로 담긴 값을 불러올 수 없다.
😇 : httpOnly 쿠키 역시 refreshToken만 저장하고 accessToken을 받아와 인증에 이용하는 구조로 CSRF 공격 방어가 가능하다.
😈 : 쿠키 저장 방식과 같은 이유로 세션 id, accessToken은 저장하면 안 된다.
😈 : httpOnly 쿠키에 담긴 값에 접근할 수는 없지만 XSS 취약점을 노려 API 콜을 요청하면 httpOnly 쿠키에 담긴 값들도 함께 보내져 유저인 척 정보를 빼오거나 액션을 수행할 수 있다.
어떤 저장 방식을 택해도 XSS 취약점이 있다면 보안 이슈가 존재한다. (XSS로 API 콜을 보내는 방식으로 다 뚫린다.) 그러므로 유저 정보 저장 방식을 바꾸는 것만으로는 방어할 수 없고, 클라이언트와 서버에서 추가적으로 XSS 방어처리가 필수다.
예: <input> 에서 입력된 값이 html / Javascript 로 인식되지 않도록 서버에서 escape 처리를 해준다. 또 url을 통해 Javascript를 수행할 수 없도록 라우팅을 꼼꼼하게 관리한다. 다행인 것은 React는 공격자가 String에 html / Javascript 를 담아 JSX에 삽입할 경우 자동으로 escape 처리한다. (XSS 방어 처리는 또 다른 주제기에 여기서는 이 정도에서 마무리한다.)