session과 cookie를 비교할때, session이 더 나은 점?
: 쿠키는 그저 http의 stateless한 것을 보완해주는 도구.
즉, 그렇다는 말은, '브라우저에서, 누군가 제3자가 접근하여 쿠키를 탈취할 가능성이 있을수가 있는것이다.'
그러니까, 우리의 이 예의 상황이 발생한다면,
누군가가 이 쿠키에 접근하여 로그인을 할수도 있는 상황이 벌어질수도 있을것이다!!!
이때, 이 옵션을 이용해, 서버에서, 쿠키 유효기간을 지정을 해준다면..?
이 옵션이 동작하면서 일정시간 후 쿠키가 자동적으로 소멸이 되게 끔 만들수 있다!
쿠키는, 경우에 따라 < script>태그로 접근이 가능한데,
그렇기때문에 XSS공격에 취약해질수 있다고 한다(ex) < script>alert(document.cookie)< /script>) //!일케 작성시에...!
때문에, 이 옵션을 사용한다면, 일케 스크립트태그로 접근하는것을 막아준다고 한다!
- 떄문에, 다시말하지만 쿠키에는 민감한 개인정보나 중요정보는 안적는게 좋다!!
- 블로그나 문서 찾아보니 대부분 그냥 'HttpOnly;'
일케 사용하던데, 스프린트에서는, 키에 값을 작성하는 방식이어서, 일단 true라고 해줌.
=> 자세한 이유는 test.js등에 있지않을까... 찾아봐야 할듯.
이 sameSite옵션은, 이러한 CSRF공격을 막는데 매우 효과적이라고 한다. 👍*CSRF공격: a가 b사이트에서 사용자로서 인증되는동안, 강제로 a에게, 원하지않는 악의적인 요청을 하는것.
ex) 만약 김코딩이 은행사이트에 로그인되어있는 상태에서, 'CSRF 공격을 받은경우,'
1. 김코딩이 은행사이트에 로그인한다.
2. 그러면 은행은 김코딩에게 유효한 토큰을 할당해줄것이다.
3. 이때, 스팸메일을 통해 해커가, 어떤 링크를 클릭하게 만들어서,
킴코딩의 유저정보를 갖고, 해커의 계좌로 이체하게 만드는 악의적인 요청이 발생할수 있다!
~이 옵션이 공격을 막는 방법~
-옵션들-
-Lax : 'GET메소드 요청만' 쿠키 전송 가능. -Strict : 그 어떤 전송요청에 대해서도, '쿠키 전송 불가.' -None : 아무 요청도 주지 않았을 경우, 서버는 cors에 의해, '모든 메소드 요청에 대해, 쿠키 전송이 가능.'
=> 위의 특징이 보여주듯이 위험한 옵션이기 때문에,
이 옵션은, HTTPS프로토콜+secure쿠키옵션이 필요!!
=>TIP: 만약 나중에 클라이언트에서 서버로 쿠키전송이 되지않으면서, 네트워크탭에서,
set-cookie 프로퍼티에 '경고아이콘'이 보인다면, 이 옵션에서 none옵션을 사용시에 해결이가능할것이다
: 접속상태를 서버가 가짐(stateful). 접속상태와 권한부여를 위해, 세션아이디를 쿠키로 전송.
Today I learned..
쿠키, 세션 스프린트를 빠르게 끝냈다.
쿠키와 세션을 비교해가면서 어떤 점이 다른지 보고
이를 응용해서 하는법을 익히면 금방 하는것 같다.사실상 현실에서는 토큰인증을 더 유효하게 사용하기때문에
내일 스프린트 전에 미리 좀 공부를 하고 페어에 임할 필요가 있을것같다.그리고 좀 성실히 블로깅을 하자. !!!!