1. Session
1.1 Session에 대해
1.2 Session의 사용
2. token
2.1 token에 대해
2.2 token의 사용
3. Cookie
3.1 Cookie에 대해
3.2 Cookie의 사용
3.3 Cookie의 옵션
들어가면서)
먼저 HTTP의 특징을 먼저 짚고 넘어가겠다.
1. server와 client를 통해 해석된다.
2. TCP/IP를 통한 응용 프로토콜이다.
3. 비연결성과 무상태성(stateless)를 가진다.
여기서 3번째에 무상태성이란 우리가 서버에 정보를 보낼때마다 내가 누구인지, 어떤상태인지 어떤 작업을 하고싶은지 전부 알려줘야한다는 점이다. 즉 서버/DB는 들어오는 요청만을 해결할 뿐이지 우리가 누구인지는 저장을 안한다는 것이다. 그렇다고 통신간에 모든 정보를 보내려면 서버에서는 처리해야할 데이터가 많아지고 client도 데이터를 정리하고 보내는것에 엄청난 작업이 소요될것이다. 이를 해결하기 위해 나온것이 Session과 token그리고 Cookie이다.
1. Session
1.1 Session에 대해
- Session은 흔히 DB측에 하나의 공간을 마련해놓고 들어온 요청에대해 SessionID를 생성, 세션저장소에 저장을 한뒤 Client에 다시 SeccionID를 보내주는방식이다.
- Client는 서버와 통신을 할때 이 SessionID를 같이 보내 자신이 누구인지 서버에 알려주는것이다. 서버는 이 SessionID를 세션저장소의 ID와 대조를 해보고 존재하는 ID면 그에맞는 응답을 Client로 보내주는 방식인 것이다.
- 중요한 데이터는 DB측에 보관되어 있고 우리는 Session을 송수신 하므로 보안성이 좋다.
1.2 Session의 사용
<출처 - https://blog.lgcns.com/2687>
- 장점
- 최초접속을 제외하면 Session만 왔다갔다 하므로 보안이 가능
- 서버에 저장되므로 Client에 의존하지 않음
- 데이터를 Hash Table에 저장, 한번에 많은 정보를 하나의 세션객체에 가능
- 단점
- 서버에 데이터를 저장하므로 세션이 많아질수록 서버의 부하가 커진다.
- 여러대의 Server가 있는 경우 Session을 받은 DB에서만 인증이 가능하다.(다른 Server들은 무상태성에 의해 Session을 판별하지 못한다.)
TIP) 한대의 Server에서만 인증이 가능하면 문제이지 않나요?
- 이러한 문제를 해결하기 위해 sticky session, session clustering과 같은 방안이 나오기도 했습니다. 하지만 이 방안들도 감안해야 할 처리 비용이 발생한다.
참고 - https://velog.io/@hyeminn/%EB%8B%A4%EC%A4%91-%EC%84%9C%EB%B2%84-%ED%99%98%EA%B2%BD%EC%97%90%EC%84%9C-%EC%84%B8%EC%85%98%EC%9D%84-%EA%B4%80%EB%A6%AC%ED%95%98%EB%8A%94-%EB%B0%A9%EB%B2%95
2. Token
2.1 Token에 대해
- 인증을 위해 암호화된 하나의 문자열
- DB에서 저장된 Token의 유무를 확인해서 통신을 하는것이 아닌 Server에서 제공된 Token의 유효성만 판별하여 데이터를 보내준다.
- Token은 웹 브라우저에 저장되기 때문에 민감한 정보를 담지 않는것이 좋다.
하지만 이러한 경우를 대비해서 Token을 암호화 하는 과정이 필요한데 이때 사용되는 흔한 방법이 "JWT"이다.
TIP) JWT란?
1. JSON형식의 암호화된 Token
2. 구성요소 =>
Header : 토큰 타입과 알고리즘 형식을 지정
payload : 서버에 보낼 정보가 들어간다
signature : Base64 방식으로 인코딩한 헤더, 페이로드 그리고 SECRET KEY를 더해 해싱된다.
2.2 Token의 사용
<출처 - https://blog.lgcns.com/2687>
- 장점
- 유저의 상태관리를 별도로 하지않아 Server측은 작업량이 줄언든다.
- Token 기반으로 하는 다른 인증 시스템에 접근이 가능합니다.(Ex. Facebook, Google ...)
- Key를 노출시키지 않는 이상 암호화된 Token을 사용하면 안정성있게 사용할 수 있습니다.
- 단점
- JWT의 경우 유효기간이 만료될때 까지 사용할 수 있어서 장기간 보관시 보안에 취약합니다.
- payload를 따로 암호화 하지 않으며 발급된 Token의 헤더,데이터와 서명을 이용하여 검증합니다. 이에따라 payload의 데이터를 변조해 유효한 Token을 생성할 수 있습니다.
3. Cookie
3.1 Cookie의 사용사례
- Server와 Client가 대화하기 위한 수단
- Client가 요청을 하면 Header에 set-cookie가 담겨진다.
- cookie의 데이터들은 Client에서 관리한다.
- 위의 설명된 Session과 Token이 cookie를 통해 Server와 통신한다.
- HTTP에 무상태성에의해 매번 사용자의 상태를 전달하는것이 아닌 cookie에 저장된 정보를 통해 Server와 DB에 Data를 받아온다.
3.2 cookie의 특징
- 쿠키는 1개의 Url에 한정되어 있다.(Google cookie가 naver에 전송될 수 없다.)
- cookie는 코드에 의해 자동 생성되며 유저가 직접 사용할 수 없다.
- 하나의 도메인당 20개까지 cookie를 가질 수 있다.
3.3 cookie의 옵션
- Domain : 서버와 요청의 도메인이 일치하는 경우 cookie 전송
- Path : 서버와 요청의 세부경로가 일치하는 경우 cookie 전송
- MaxAge or Expires : 쿠키 유효시간 설정
- HttpOnly : 스크립트의 쿠키접근 여부설정
- Secure : HTTPS 프로토콜에서만 cookie 전송여부 결정
- SameSite : CORS요청의 경우 옵션 및 메소드에 따라 cookie 전송여부 결정
TIP) CSRF란?
Cross-site-request-forgery로 해커가 사용자에게 위조된 요청을 보내도록 임의로 만든 사이트를 보내면 사용자는 그 잘못된 사이트를 사용해서 은행이나 중요한 사이트에 위조된 요청을 보내게됩니다.
그 뒤 해커가 위조된 요청을 통해 받은 Token을 활용해서 사용자가 요청을 보냈던 은행이나 중요 사이트를 활용 할 수 있게 되는 것이다.
- CSRF대응법
- CSRF 토큰사용 : 웹은 스크립트나 자동화된 도구에 의해 보내져 요청에 대한 검증절차가 없이 처리될 수 있다. 따라서 세션별로 CSRF토큰을 생성하여 세션에 저장하고 사용자가 요청할때마다 토큰을 전달하고 CSRF토큰도 체크하는 더블체크방식이 이루어져야 한다.
- 재인증 요구 : 중요기능일 경우 재인증을 통해 요청의 유효성을 검토한다.
- CAPTCHA : 사용자가 컴퓨터인지 사람인지 구분할수 있게해주는 기술
느낀점
- 보안에 좀더 신경써야하는 백엔드업무의 기반을 다진거 같다.
- 직접 Hash알고리즘을 공부해보고 싶다.
- 직접 서버에서 어떻게 동작하는지 코드를 직접 짜서 cookie를 통해 Token과 Session을 다뤄볼 예정이다.
참고
0개의 댓글
