https : http 에서 보안성이 추가.
누군가요청을 들여다본다면 그대로 요청을 들여다볼수잇엇다
그러다보면 개인정보가 쉽게노출된다.
그러나 세션 프로토콜은 한번 암호화를 시키기 때문에 정확한 키가 없다면 어떤 내용인지 알 수 없다.
☝🏼 google 의 인증서.
📂 인증서 (certification)
데이터 제공자 신원보장, 도메인 종속
요청을 받는다면 서버는 인증서와 함께 응답을 전송, 응답받은 클라이언트는 인증서에 작성된 도메인과 응답에 작성되있는 도메인 확인 -> 그게 같으면 확실하게 같다는것을 인지.
하지만
제3자 공격, 해커가 정보를 탈취한다면 응답확인도메인과,인증서 작성도메인이 정말로 데이터를 제공해주는서버가 같지않다는걸 보장할수없음.
전혀다른 제공자임을 알수있게된다.
CA-공인인증서 발급기관
비대칭 키 암호화, 복호화 가능
한쌍의 키에서 하나는 비밀로 숨겨두고 나머지하나는 클라이언트에게 공개
공개 키 방식
통신의 초창기에서만 비밀키로 사용하기위해
hand shake
서로를 확인하고 서버는 클라이언트에게 공개키 한쌍중 하나를 전달
비밀 키 생성
클라이언트는 전달받은 키를 이용해서 서버와 키를만들어낼 임의의 정보를 암호화해서 전송. 서버는 클라이언트처럼, 임의의 정보를 암호화 해서 전송한다.
상호 키 검증
각자 생성한 키를 바탕으로 클라이언트가 테스트용 데이터를 만들어낸 비밀키로 암호화해서 전달. 서버는 비밀키로 복호화, 암호화해서 클라이언트에게 전달.
클라이언트가 같은내용의 데이터를 복호화 하는데 성공한다면 비밀키성공.
== https 성립오케이
cert.pem 과 key.pem 파일이 생성되었다.
여기서 cert.pem 은 인증기관의 서명을 포함하고 있어 공개해도 상관없지만 key.pem 은 개인 키 이므로 git 에 커밋하지 않고 암호처럼 다루어야 한다.
📂 해시
외부에서 만들어진 알고리즘에 의해 만들어진 pw.
비번이 털려도 해시값이 다르기때문에 악용될 여지에 대한 걱정을 덜 수 있다.
hashing
1. 모든값에 대해 해시값을 계산하는데 오래걸리지 않아야 한다.
2. 최대한 해시 값을 피해야 하며, 모든 값은 고유한 해시 값을 가진다.
3. 아주작은 단위의 변경이라도 완전히 다른 해시 값을 가져야 한다.
대표적인 hashed password(SHA1)
salt 는 암호화해야하는 값에 더떤 별도의 값을 추가하여 결과를 변형하는 것.
안전장치. 암호화하려는 값에 솔트를 주고 해싱을 진행하게됨.
주의사항
1. 유저와 패서워드 별로 유일한 값을 가져야한다.
2. 사용자 계정 생성할때와 비번 변경할때마다 새로운 임의의 솔트를 사용해서 해싱해야함.
3. 솔트는 절대 재사용불가.
4. db유저테이블에 같이 저장되어야 한다.
📂 쿠키
http 는 무상태성(stateless) 이지만 정보가 유지될 수 있는 이유는 바로 쿠키 덕분이다.
(장바구니 유지)
*무상태성?
각각의 요청<-->응답 은 독립적이다.
로그인 / 유저정보조회 -> 서로 모름
서버가 일방적으로 클라이언트에 전달하는 작은 데이터.
set-cookie : key=value;
key2 = value2
이런식으로 전달된다.
사용자 선호, 테마, 장시간 보존해야하는 정보저장에 적합.
서버는 쿠키의 값,옵션을 키에 저장
클라이언트가 매 요청시마다 서버에게 전달
매요청에 자동으로 쿠키가 전송.
쿠키내용을 바탕으로 서버는 클라이언트에 저장된 쿠키를 통해 로그인유지,테마유지 등의 현상이일어날수있음
📁 쿠키옵션
도메인
서버와 요청의 도메인이 일치하는 경우에만 쿠키전송
패스
서버와 요청의 세부경로가 일치하는 경우 쿠키전송
MaxAge 또는 Expires
쿠키의 유효기간 설정
HttpOnly
스크립트의 쿠키 접근을 막고 브라우저만 접근 가능 여부결정
secure
https 프로토콜에서만 쿠키전송 여부결정
samesite
cors 요청의 경우 옵션및 메서드에 따라 쿠키전송여부결정
*maxage 또는 expires
예시 ) 피시방
로그아웃안하고 집에왔을때,
누군가가 이후에 쿠키를 탈취해서 내껄로 로그인할수도있음
이때, maxage 또는 expires 옵션을 이용해서 서버에서 쿠키의 유효기간을 지정해준다면 일정기간이 지난 후 자동소멸하게 가능.
httpOnly
script 태그로 접근가능 -> xss 공격에 취약하다.
쿠키에 노출되서는안되는 정보는 쓰지않는것이 좋다.
samesite : cors
은행사이트 로그인되있는 상태에서 csrf 공격을 받은 경우
김코딩이 은행사이트에 로그인->은행은 김코딩에게 유효한 토큰할당 -> 스팸메일을 통해 해커가 어떤 링크를 클릭하게 만들어서 돈을 이체하는 악의적인 공격이 csrf 공격임.
이 공격을 막는데 효과적인 옵션이다.
어떤 옵션을 쓰느냐에 따라 쿠키의 전송여부를 결정할수있다.
Lax
GET 요청에 대해서만 쿠키전송가능
Strict
그 어떤요청 메소드에 대해서도 쿠키전송불가
None
cors 에 대해서 모든 메서드요청에 대해 쿠키전송가능 (위험)
그렇기 때문에 samesite - none 옵션사용할땐
https 프로토콜과 secure 옵션을 사용해야한다.,
(samesite = 'none' 옵션은 secure 쿠키옵션이 필요합니다.)
만약 서버에서 쿠키가 전송되지않으면서 네트워크탭에서 set-Cookie 프로퍼티에 쿠키를 담아 옆에 경고아이템이 보이면 samesite 옵션을 none 으로 처리하면 해결할수있다.
📂Session
세션이 활성화되었다. -> 서버와 클라이언트간 연결이 활성화 된 상태.
쿠키에는 서버가 클라이언트에 유일하고 암호화된 ID 를 부여
중요 데이터는 서버에서 관리.
세션도 쿠키의 유저의 정보를 담아줘
암호화를 하는 과정이 필요함.
set-cookie 메소드를 통해 클라이언트에 전달.
클라이언트가 세션아이디가 부여된 상태이기 때문에 세션아이디로 서버에 요청을함. (신분증역할) 서버에서는 db에 세션아이디가 맞는지 확인하고 장바구니에 담아주고, 클라이언트에게 장바구니 담기완료를 알려줌.
클라이언트의 중요한 정보는 서버에서 관리하게 됨.
장점
쿠키 : 서버에 부담을 덜어줌.
세션 : 신뢰할 수 있는 유저인지 서버에서 추가로 확인 가능.
단점
쿠키 : 쿠키 그 자체는 인증이 아님, xss 공격에 취약.
세션 : 하나의 서버에서만 접속 상태를 가지므로 분산에 불리,
서버의 메모리에 세션정보저장.
서버의 이용자가 매우많으면 메모리공간의 일정부분을 항상 차지.
서버성능안좋아질수있음
기존쿠키를 완전히 대체한것이 아니라 여전히 쿠키를 사용하고있다.
공공장소가면 항상로그아웃 해줘야 하는 이유가 바로이것임.
