지난 몇 주간 CSRF_TOKEN, SESSION, COOKIE에 대하여 경험을 할 수 있었다.
나의 목적은 Client에서 보낸 request의 정당성에 대하여 server에서의 판별이었다.
이에 따라, CSRF_TOKEN으로 처음에는 접근을 하였으며,
이 과정에서 시행착오를 겪으며
- CSRF_TOKEN
- SESSION_ID
- COOKIE
에 대하여 생각해볼 수 있는 귀중한 경험이었다.
우선, 어떠한 기술을 적용함에 있어서 접근하는 태도에 대하여 느낀점이 있다면
기술이 만들어진 목적(의도)을 파악하는 것이 중요하다는 것이다.
목적 및 의도를 정확히 파악해야 동작 방식에 대한 이해와 활용이 가능하다고 생각한다.
CSRF_TOKEN
CSRF(Cross Site Request Forgery) 공격을 막기위해, 주요정보를 입력받기전
만료기한을 짧게하여 일시적으로 발급하는 토큰이다.
입력 제한 시간을 주기위한 TOKEN 이라 생각할 수 있다.
만료기한이 1 ~ 5분 이내의 token을 일시적으로 발급하여
공격자가 사용자의 인증(Authentication) 정보를 이용하여
오염된 요청을 보내는 것을 임시적으로 막을 수 있는 역할을 해준다.
Token을 통해 공격을 완전히 막을 수는 없다.
이로써, 민감한 정보를 가득 담은 Payload를 담은 각종 요청에 대하여
SERVER가 정당한 사용자의 요청인지 판별해낸다.
하지만 나의 목적은, 주어진 시간에 관계없이
모든 요청에 대하여 정당한 지를 판별하는 것이므로,
CSRF_TOKEN의 목적성과 일치하지 않는다.
SESSION_ID
Session은 Server가 Client의 정보를 기억하기 위한 Server측 장치이다.
Server에 Client의 정보를 저장해야 한다면, 사용하는 것이다.
주로 Client의 인증(Authentication) 정보를 저장하는 데 이용된다.
Session은 다양한 형태로 Server측에 저장된다.
- 단순 Server 측 Memory를 이용하여 휘발적으로 관리하기도,
- 파일의 형태로 저장되기도,
- SQL 및 NoSQL 기반의 DB를 이용하기도 한다.
비유적으로 표현하면
Client가 Server에 요청을 보내면,
Server는 Client가 보낸 일종의 열쇠: session_id
(사용자에게 배정된 Session이라는 사물함의 열쇠)를 같이 보냈는지 확인한다.
- 주로 request Header에 담겨온다.
(상황에 따라 반드시, 안전한 방식을 취해야 할 것이다.)
Case1.session_id 라는 열쇠가 있다면,
열쇠에 맞는 session 사물함을 찾아서,
그 안의 정보들을 확인한후, 요청을 수행한다.
Case2. session_id 라는 열쇠가 없다면,
인증과정(로그인 등)을 통해
새로운 사용자라고 판단하여 새로운 session 을 사용자에게 배정(생성)하고,
이에 맞는 열쇠: session_id 를 client에 전달한다.
- response Header: Set-cookie 및 response Payload 등을 통하여 전달.
이후부터, Client는 이를 이용하여 Server와의 소통을 할 수 있다.
Session은 인증과정을 거친 사용자의 정보를 Server측에 저장하기위해 주로 활용되고,
+) 굳이 로그인을 하지않아도,
현재 Session을 유지하고있는 사용자에 대한 정보를 저장하여
요청 처리에 활용할 수도 있다.
Session은 주로 "인증과정"을 거친 사용자에 대하여 Session을 만들고,
Session_id 를 부여하기 때문에,
인증과정이 없는 임의의 요청이 정당한지 판별하고자 하는 나의 목적과 부합하지 않다.**
COOKIE
Cookie는 Browser에 현재 Domain에 대한 정보를 저장하는 장치이다.
간단한 정보부터 Session_id 및 JWT, CSRF_TOKEN처럼 민감한 정보까지
다양한 정보를 저장할 수 있다.
우선, Cookie는 위의
Session과 대칭적으로, Server에서 보낸 정보를 저장해야한다면, 사용하는 것이다.
Cookie는 request에 자동으로 포함되어 보내지기 때문에,
( 보안상의 이유로 Cookie의 몇가지 설정(Secure, httpOnly 등)을 통해 이 또한 제어할 수 있다.)
Server에서 보내온 정보를 저장하여
Server와 통신하기위해 사용하는 데에 주목적이 있다.
하지만, Server에서 보낸 정보를 저장하지 않고,
Client측에서만 필요한 정보를 저장하기위해 사용하기도 한다.
(이는, LocalStorage, SessionStorage가 더 적합해 보인다.)
Cookie는 Client가 Server에 보내거나 보내기위해 쟁여놓은 정보 조각이므로,
나의 목적인 요청의 정당성을 논하기에는 관점을 달리한다.
보안을 충분히 고려한다면 "정당성을 확인받기위한 장치의 저장장소"로 사용할 수 있을 것이다.
결론
CSRF_TOKEN과 SESSION_ID는
앞써 서술한 바에 의해 내가 구현하고자하는 기능과는 그 목적성이 거리가 멀다.
COOKIE는
저장장치의 일종이므로, 이는 관점을 달리한다.
CORS 및 Origin 등을 이용하여 요청의 출처를 통해
요청의 정당성을 판별하는 것이 나의 목적에 더 부합해보인다.
CORS와 ORIGIN에 대하여 다이브해볼 생각이다.
p.s. 귀중한 피드백주시면 감사히 공부하겠습니다.
