LocalStorage vs Cookies : JWT 토큰 안전하게 하기위한 방안

session ID는 서버에 많은 부담을 주기때문에 인가를 하기위해 나온 방식이 Token이다.주로 JWT토큰을 사용하여 처리하는데 -Access token-Refresh token두가지를 가지고있다.

 

(서버측에서)

Access token은 짧은 생명주기를 가지고, 서버로부터 승일을 받아 인증이 필요한 모든 HTTP request에 포함되어 간다.

그에반해 Refresh token은 보통 긴 수명 주기를 가지고, DB에 저장되어 access token이 만료되었을때 새로운 

access token을 발급해준다.

 

(클라이언트)

받아온 token을 어디에 저장해야할까?

 

local storage, cookies 두가지 방식이있는데 장단점을 봐보자

 

local storage

 

장점 - 편리성

pure javascript로 편리한 장점이있다. 만약, back-end 없이 third party api로 의존을 한다고한다면,

매번 third party api에 쿠키를 셋팅 할 수 없을 것이다.

 

단점 - XSS공격에 취약하다.

 

local storage에 저장되어있는 access token을 탈취 할 수 있다.

웹사이트에 포함된 third-party javascript코드에 의해서 발생할 수있다. (리액트, 뷰 등등)

 

Cookies

 

장점- javasciprt로 접근이 불가능. XSS공격에 비교적 덜 취약

cookie의 secure옵션, httpOnly를 한다면 괜찮다고한다.

 

쿠키는 자도응로 요청에 포함

 

단점 - 서버에서 authorization header에 해달라고한다면 , 사용할수없고 용량이 작다.

 

XSS공격.

local storage는 자바스크립트를 사용해서 접근이가능한 반면에

쿠키는 secure, httpOnly를 사용하면 접근이 불가능하지만 그렇다고 완전히 공격에 안전한것은 아니다.

-> httpOnly하면 window. cookie뭐 이런식으로 쿠키 탈취가 불가능.

 

 

쿠키와 CSFR 공격

유저가 의도하지않은 요청을 하도록 만든느 공격

same-site, anti-CSFR Tokens를 사용하면 어느정도 예방이 가능하다.

 

 

가장좋은 방법은 refresh token을 httpOnly cookie에 저장하라: CSRF 공격으로부터 안전하고, XSS 노출에 대해서는 조금 더 낫다.

 

---

 

XSS

해커는 악의적인 공격을 하는것인데 =  크로스 사이트 스크립팅

 

해커가 서버에 입력을 하고, 희생자가 웹페이지를 봤을때 크로스 사이트 스크립팅으로 피해를 입게된다.

글을 쓰는것이아닌 자바스크립트 코드를 인젝션하게된다.

스크립트 랭기지가 실행되면서 => 피해를 입게되는 구조이다.

 

어떤 스크립트를 쓰느냐에 따라서 피해정도가 다른다.

httprequest를 만들어주고 Url을 서버에 url로 지정하고 쿠키를 넣어줘서

Get requestf를 만들수가있다. 

서버에 접속했을때 만들어진 쿠키가 -> 전부 쿠키로 가져올 수 가 있다.

 

쿠키안에 세션 아이디가있으면? 세션아이드를 가지고 서버에 접속해서 

모든 정보를 빼갈 수 있다.

cors이 될 수도 있다. 

 

방지하기위해서 - script가 플레인 텍스트로 보여지게 하는 그런 내용을 써야된다.

 

CSFR = 크로스 사이트 리케스트 뽀져리

링크를 클릭하면 = 서버에게 어떤 요청을 하는것이다.

a라는 페이지를 줘, b라는 페이지를줘 

어떤 처리를 요청. 로그인할껀데 아이디 비번 이거야~

 

요청 위조하는방법 : 

서버야 나 계좌번호 a라는 곳에 100만원 보내줘 이런식의 링크를 만들게된다.

이 링크를 뿌리게된다. 호기심에 클릭하면 털려버린다.