쿠키와 세션의 차이
정보 유지가 필요한 상황에서 HTTP 특징인 Stateless한 방식을 대처하기 위해 쿠키와 세션을 사용한다.
큰 차이점은 상태정보의 저장 위치이다.
쿠키와 세션 모두 클라이언트가 가지고 있지만 세션은 서버'도' 저장한다
쿠키
클라이언트의 상태 정보를 클라이언트의 PC에 저장하였다가 필요시 정보를 참조하거나 재사용 가능하다.
특징
- Key-Value 쌍의 작은 데이터 파일
- 이름, 값, 만료일(저장 기간 설정), 경로 정보, HttpOnly 등로 구성되어 있다.
- 클라이언트에 총 300개의 쿠키를 저장할 수 있다.
- 하나의 도메인 당 20개의 쿠키를 가질 수 있다.
- 하나의 쿠키는 4KB(=4096byte)까지 저장 가능하다.
동작방식
1. 클라이언트가 서버에 로그인 요청
2. 서버는 클라이언트의 로그인 요청의 유효성을 확인하고 응답헤더에 set-cookie: user=kwc를 추가하여 응답
3. 클라이언트는 이후 서버에 요청할 때 전달받은 cookie: user=kwc 쿠키를 자동으로 요청헤더가 추가하여 요청한다.(브라우저에서 자동으로 추가해줌)
※ 쿠키의 기한이 정해져 있지 않고 명시적으로 지우지 않는다면 반 영구적으로 쿠키가 남아있게 된다.
사용 예시
- 방문했던 사이트에 다시 방문하였을 때 아이디와 비밀번호 자동 입력
- 팝업창을 통해 "오늘 이 창을 다시 보지 않기" 체크
세션
브라우저가 종료되기 전까지 클라이언트의 요청을 유지하게 해주는 기술
특징
- 웹 서버에 상태를 유지하기 위한 정보를 저장한다
- 웹 서버에 저장되는 쿠키(= 세션 쿠키)
- 브라우저를 닫거나, 서버에서 세션을 삭제했을때만 삭제가 되므로, 쿠키보다 비교적 보안이 좋다
- 각 클라이언트에 고유 Session ID를 부여한다.
동작방식
1. 클라이언트가 서버에 로그인 요청
2. 서버는 클라이언트의 로그인 요청의 유효성을 확인하고 unique한 id를 sessionid라는 이름으로 저장
3. 서버가 응답할 때 응답헤더에 set-cookie: sessionid:skkefq2를 추가하여 으답
4. 클라이언트는 이후 서버에 요청할 때 전달받은 sessionid: skkefq2 쿠키를 자동으로 요청 헤더에 추가하여 요청
5. 서버에서는 요청 헤더의 sessionid 값을 저장된 세션 저장소에 찾아보고 유효한지 확인 후 요청을 처리하고 응답
※ 세션의 내용은 서버에 저장되기 때문에 계속하여 늘어날 경우 서버에 부하가 발생
사용 예시
화면이 이동해도 로그인이 풀리지 않고 로그아웃하기 전까지 유지
쿠키와 세션의 차이점
저장위치
쿠키는 클라이언트(로컬), 세션은 로컬과 서버에 저장
보안
쿠키는 탈취와 변조가 가능하지만(암호화나 Httponly 속성이 안되어 있을 경우), 세션은 ID값만 가지고 있고 서버에도 저장되어 있기 때문에 상대적으로 안전
Lifecycle
쿠키는 브라우저를 종료해도 파일로 남아있지만, 세션은 브라우저 종료시 세션을 삭제
속도
쿠키는 파일에서 읽기 때문에 상대적으로 빠르고, 세션은 요청마다 서버에서 처리를 해야하기 때문에 비교적 느림
접근성
쿠키는 Js를 이용하여 액세스할 수 있다(httponly 속성이 활성화 되어 있을경우 JS 액세스 불가능)
세션은 액세스 할 수 없다.
용량
쿠키는 하나당 최대 4KB
세션은 서버측 용량에 따라 다름
SOP와 CORS
SOP(Same Origin Policy)
다른 출처의 리소스를 사용하는 것에 제한하는 보안 방식
※ 출처(Origin)는 Protocol, Host, Port를 통해 같은 출처 인지 다른 출처인지 판단할 수 있다
브라우저에서는 String을 비교하기 때문에 localhost != 127.0.0.1 이다
CORS(Cross-Origin Resource Sharing)
다른 출처의 자원에 접근할수 있는 권한을 부여하도록 브라우저에 알려주는 체제
방식
1. 프라플라이트 요청 (Preflight Request)
2. 단순 요청 (Simple Reqeust)
3. 인증정보 포함 요청 (Credentialed Request)
Preflight Request
- OPTIONS 메서드를 통해 다른 도메인의 리소스에 요청이 가능한 지 확인 작업
- 요청이 가능하다면 실제 요청(Actual Request)을 보낸다
Access-Control-Max-Age
- 하나의 요청마다 매번 Preflight 요청을 날릴 수 없으니 응답값을 캐싱, 그럼 캐싱시간동안 바로 요청을 보낼 수 있음
Preflight Response는 응답 코드가 200대여야 하고 응답 바디는 비어있는 것이 좋다.
💡 Preflight가 왜 있는가?
CORS spec이 생기기 이전에 만들어진 서버들은 브라우저의 SOP(same origin policy) request만 가능하다는 가정하에 만들어졌는데, cross-site request가 CORS로 인해서 가능해졌기 떄문에 이런 서버들은 cross-site request에 대한 security mechanism이 없다보니 보안적으로 문제가 생길수 있으니 이런 서버들을 보호하기 위해 CORS spec에 preflight request를 포함한겁니다. Preflight request로 서버가 CORS를 인식하고 핸들할수있는지 먼저 확인을 함으로써 CORS를 인식하지 못하는 서버들을 보호할수있는 매커니즘 입니다
ex) CORS를 모르는 서버들에 요청을 보냈는데 해당 요청이 삭제같은 작업이면 브라우저에선 에러가 터졌지만 이미 서버에선 작업이 완료된 상태..
Simple Request
- Preflight 요청 없이 바로 요청을 날린다
- 서버가 이에대한 응답 헤더에 Access-Control-Allow-Origin과 같은 값을 보내주면 그때 브라우저가 CORS 정책 위반 여부를 검사하는 방식
- 다음 조건을 모두 만족해야 한다
- 요청의 메소드는 GET, HEAD, POST 중 하나여야 한다.
- Accept, Accept-Language, Content-Language, Content-Type, DPR, Downlink, Save-Data, Viewport-Width, Width를 제외한 헤더를 사용하면 안된다.
- 만약 Content-Type를 사용하는 경우에는 application/x-www-form-urlencoded, multipart/form-data, text/plain만 허용된다.
- 2번, 3번 조건이 까다롭다. Authorization도 사용 못하고, text/xml이나 application/json도 사용하지 못한다.
Credentialed Request
인증 관련 헤더를 포함할 때 사용하는 요청이다.
credentials 옵션
same-origin(기본값): 같은 출처 간 요청에만 인증 정보를 담는다
include: 모든 요청에 인증 정보를 담는다
omit: 모든 요청에 인증 정보를 담지 않는다.
클라이언트 측
credentials: include
credentials를 incldue로 하게 되면...
서버측은 아래조건을 만족해야 한다.
- 응답헤더에 Access-Control-Allow-Credentials: true
- Access-Control-Allow-Origin: *은 안된다. 정확한 Origin을 줘야 한다
REST API
REST 아키텍처 스타일에 부합하는 API이다.
※ 아키텍처 스타일이란 제약조건의 집합을 의미
제약조건
1. Client-Server 구조
클라이언트는 요청을 발생 시키고, 서버는 요청에 대해 반응
관심사의 분리를 통해 클라이언트는 UI의 이식성에 집중, 서버는 확장성에 집중 가능
2. Stateless (무상태성)
요청은 상태를 가지지 않는다는 제약조건
각각의 요청은 독립적이고 필요한 모든 정보를 제공해야 한다.
서버는 클라이언트가 이전에 무슨 요청을 보냈는지 모름
3. 캐시
서버는 자원이 캐시 가능한지 명시해야 한다
4. 계층형 시스템
계층형 시스템을 적용해야 한다는 제약 조건
각각의 책임에 맞게 서버에서 이를 구현하여 단순성과 확장성이 좋음
5. 주문형 코드 (Optional)
클라이언트가 '필요에 의해' 기능을 확장할 수 있도록 해야한다는 제약조건
대표적인 예시로 플러그인이 있음
시스템 전체적으로 적용되었을때 오히려 성능에 안좋을 수도 있어서 Optional임
6. Uniform Interface ★
개발을 할 때 클라이언트와 맞닿아 있는 부분을 쉽고 일반적으로 설계하라는 제약조건
6-1. 자원의 식별
클라이언트와 서버 사이의 상호작용에서 고유하게 자원을 식별할 수 있어야 한다
6-2. 표현을 통한 자원의 조작
표현이란? 메타데이터 + 데이터이면서, 자원의 특정 상태를 의미
이러한 표현을 통해서 자원을 조작해야 한다!
6-3. 자기 서술적인 메시지
자신의 표현은 메시지를 처리하기에 충분한 정보를 제공해야 한다.
JSON 데이터를 자기 서술적으로 표현하는 방법
1. IANA에서 커스텀 medai type 등록하기
2. 메시지 헤더에 명세가 포함된 링크 등록하기
6-4. HATEOAS(hypermedia as the engine of application state)
클라이언트는 서버와 상호작용하면서 하이퍼링크를 통해 동적으로 모든 리소스에 접근할 수 있어야 한다는 제약조건
HTML의 경우 a 태그를 통해 다른 리소스에 접근이 가능하다
=> 클라이언트가 어플리케이션의 상태를 동적으로 변경할 수 있으므로 HATEOAS
자원을 생성했을 때 Location 헤더에 생성된 자원의 위치를 넣어준다면 HATEOAS를 만족함
헤더가 아닌 데이터로 링크를 넘겨주는 방식
REST의 핵심
클라이언트와 서버간의 결합도를 낮춰 독립적인 진화를 할 수 있게 하는것
※ 독립적인 진화는 서버와 클라이언트 간의 상호작용에서 변경의 영향을 최소화하고 유연성을 제공하기 위한 노력을 의미한다.
토큰이란
토큰은 서버에서 해당 클라이언트에게 인증되었다는 의미로 유니크하고 암호회된 데이터이다.
- 세션과 달리 서버가 아닌 클라이언트에 저장된다. 그래서 확장성이 좋다.
- 토큰 자체에 데이터가 들어있어 서버에서는 토큰을 받아서 클라이언트에서 위조되었는지 판별하고 내부 데이터를 꺼내서 사용할 수도 있다.
- 토큰은 앱과 서버가 통신 및 인증할때 가장 많이 사용된다. 왜냐하면 웹에는 쿠키와 세션이 있지만 앱에서는 없기 때문이다.
- 대표적인 방식으로 JWT 방식이 있다.
- 인증에 필요한 정보들을 암호화 시킨 JSON 토큰
Token 방식의 단점
- 쿠키/세션과 다르게 토큰 자체의 데이터 길이가 길어, 인증 요청이 많아질수록 네트워크 부하가 심해질수 있다.
- Payload 자체는 암호화되지 않기 때문에 유저의 중요한 정보는 담을 수 없다.
- 토큰을 탈취당하면 대처하기 어렵다. (따라서 사용 기간 제한을 설정하는 식으로 극복한다)
대표적인 방식으로 JWT 방식이 있다.
XSS (Cross-Site Scripting)
가장 널리 알려진 웹 보안 취약점 중 하나
악의적인 사용자가 공격하려는 사이트에 악성 스크립트를 삽입할 수 있는 보안 취약점
C&C로 리다이렉트 하거나 사용자의 쿠키를 탈취하여 세션 하이재킹 공격을 할 수 있다.
대표적인 공격방식
- Stored XSS
- Reflected XSS
- DOM Based XSS
Stored XSS
공격자가 제공한 데이터가 서버에 저장된 후 지속적으로 서비스를 제공하는 정상 페이지에서 다른 사용자에게 스크립트가 노출되는 기법
Reflected XSS
웹 어플리케이션의 지정된 파라미터를 사용할 때 발생하는 취약점을 이용한 공격법
- 검색어 같은 쿼리스트링을 URL에 담아 전송했을 때, 서버가 필터링을 거치지 않고 쿼리에 포함된 스크립트를 응답 페이지에 담아 전송함으로써 밠갱
공격용 스크립트가 대상 웹사이트에 있지 않고 다른 매체(타 사이트, 이메일)에 포함될 수 있다
Stored XSS와는 다르게 DB에 스크립트가 저장되지 않고 응답 페이지로 바로 클라이언트에 전달된다는 차이점이 있다
XSS 예방법
1. XSS 취약점이 있는 innerHTML 사용을 자제한다.
- textContent, innerText를 사용하면 스크립트가 주입되지 않는다
2. 쿠키에 HttpOnly 옵션을 활성화 한다.
- 악의적인 클라이언트가 쿠키에 저장된 정보(세션Id, 토큰)에 접근하는 것을 차단한다.
- 활성화 하지 않으면 스크립트를 통해 쿠키에 접근할 수 있어 Session 하이재킹 취약점 발생
- LocalStoage에 세션ID같은 민감한 정보를 저장하지 않는다.
3. XSS 특수문자를 치환한다.
- Spring에서는 직접 구현하지 않아도 오픈소스 라이브러리를 사용하면 된다.
- Lucy XSS Servlet Filter
- but, @Request Body로 전달되는 JSON 요청에 대해서는 처리해주지 않는다.
SQL Injection
데이터베이스와 연동된 웹 어플리케이션에서 공격자가 입력이 가능한 폼에 조작된 질의문을 삽입하여 웹 서비스의 데이터베이스 정보를 열람 또는 조작할 수 있는 취약점
예방법
Parameter Binding 방식을 지원하는 PrepareStatement 객체를 사용한다.
- 내부적으로 escape를 처리한다.
URI URL URN
URI (Uniform Resource Identifier)
- 특정 리소스를 식별하는 통합 자원 식별자
- 추상적 / 물리적 리소스를 식별하기 위한 식별자(Identifier)
URL (Uniform Resource Locator)
- 리소스의 위치
- 컴퓨터 네트워크 상에서 리소스가 어디 있는지 알려주기 위한 규약
URN (Uniform Resource Name)
- 리소스에 이름을 부여
- 한 리소스에 대해 위치와 상관없이 유일하게 해당 리소스를 식별하는 이름 역할을 한다
- URN은 아직 실험중이고, 널리 채택되어 사용되고 있지 않다.
모든 URL은 URI 이지만
- 고유한 위치를 나타내기 때문에 URI로 볼 수 있다.
URI는 locator 대신 이름일 수 있기 때문에 모든 URI가 URL인 것은 아니다.
현실 예시
- Charles는 내 이름이며 식별자(Identifier)다. 이는 URI와 비슷하지만 내 위치나 연락처에 대한 정보가 없으므로 URL은 될 수 없다.
- 경기도 성남시 분당구 정자동 불정로 6는 주소다. 주소는 특정 위치를 가르킨다. URL 및 URI와 비슷하며 간접적으로 내가 있는 장소로 식별한다.
URI 구조
scheme:[//[user[:password]@]host[:port]][/path][?query][#fragment]
- scheme: 사용할 프로토콜을 뜻하며 웹에서는 http 또는 https를 사용
- user와 password : (서버에 있는) 데이터에 접근하기 위한 사용자의 이름과 비밀번호
- host와 port : 접근할 대상(서버)의 호스트명과 포트번호
- path : 접근할 대상(서버)의 경로에 대한 상세 정보
- query : 접근할 대상에 전달하는 추가적인 정보 (파라미터)
- fragment : 메인 리소스 내에 존재하는 서브 리소스에 접근할 때 이를 식별하기 위한 정보
웹 캐시
주어진 리소스의 복사본을 저장하고 있다가 요청 시 제공하여 네트워크 지연과 트래픽을 줄여주는 기술이다.
사용자 입장에서는 빠른 서비스 경험을 할 수 있다.
추가 장점으로 오리진 서버의 과부하 방지도 있다.
단점으로는 데이터의 성격과 상황에 따라 캐시전략을 잘 세워야 오래된 콘텐츠를 노출하는 등의 문제를 방지할 수 있다.
캐시 무효화 전략
캐시 무효화(Cache Busting)는 웹 브라우저의 캐시를 완전 제거해버리는 것을 말한다.
만약 캐시를 사용해선 안되는 페이지가 존재한다면, 다음과 같이 Cache-Control 헤더에 파라미터들을 Setup 하여야 한다.
- Cache-Control: no-cache
- 데이터는 캐시해도 되지만 항상 원 서버에 검증하고 사용해야 한다. (max-age=0 과 동일한 뜻)
- 즉, 서버로부터 304 응답(Not Midified)을 받아야 캐시에서 가져온다는 말이다. 비록 네트워크 트래픽이 발생하지만 헤더 메세지만 응답 받기 때문에 네트워크 다운로드량은 적다.
- no cache 라는 이름때문에 캐시를 사용안한다고 생각할 수 있는데, 이 단어의 의미는 본래 캐시 유효 기간이 남아있으면 무조건 캐시 저장소를 조회하지만 그리하지말고 무조건 서버에 검증 받으라는 말이다.
- Cache-Control: no-store
- 데이터에 민감한 정보가 있기에 저장하면 안된다는 의미
- 메모리에서 사용하고 최대한 빨리 삭제한다.
- Cache-Control: must-revalidate
- 캐시 만료후 최초 조회시 원 서버에 검증해야 할때 설정
- 원 서버에 접근 실패시 반드시 504(Gateway Timeout) 오류가 발생해야 하도록 한다.
- 만일 캐시 유효 시간 내에 있다면 캐시를 사용한다.
Pragma: no-cache- HTTP 1.0 하위 호환용
no-cache vs must-revalidate 비교
캐시 무효화 헤더를 설정할때 보통 no-cache 와 must-revalidate 를 같이 설정하는 편이다.
must-revalidate 가 사용되는 이유는 no-cache 에 의해 원 서버(Origin Server) 에 검증 요청을 보내는 도중 원 서버 와 프록시 캐시 서버(Proxy Cache Server) 의 연결이 끊어져 검증이 불가능할 경우, 504 Gateway Timeout 오류를 발생시키기 위해서이다. 왜냐하면 몇몇 프록시 캐시 서버에서는 원 서버에 접근이 불가능해질 경우에 검증을 거치지 않고 이전의 캐시 데이터를 반환하기 때문이다.
예를들어 통장 잔고와 같은 중요 데이터의 경우, Origin Server 와의 연결이 불가능하다고 해서 변경 전의 데이터를 반환하면 큰일나므로, must-revalidate 를 활용해 일부로 5XX 오류를 발생시키는 전략을 세운다고 보면 된다
다만, must-revalidate는 캐시 유효성 기간이 남아있으면 우선적으로 캐시 저장소를 조회하게 되어있다. 따라서 원 서버 네트워크 문제 해결과 항상 원 서버에 캐시 검증을 함께 사용하고 싶은 경우 no-cache와 함께 설정해주면 된다.
브라우저 캐시
브라우저 안에 있는 로컬 캐시를 사용하는 방법
클라이언트에서 사용하고 저장되어 private 캐시라고도 부른다.
HTTP의 Response Header에 cache-control로 제어한다.
- 캐시의 유효 시간(생명 주기)을 명시하는 응답 헤더
- 헤더 값 파라미터 종류
- max-age : 캐시 유효 시간, 초 단위
- no-cache : 데이터는 캐시해도 되지만, 항상 Origin Server 에 검증후 사용
- no-store : 데이터에 민감한 정보가 포함되어 있어 저장 불가 혹은 최대한 빨리 삭제
- public : public 캐시(프록시 캐시 서버)에 저장 가능
- private : public 캐시에 저장 불가
- s-maxage : 프록시 캐시 서버에 적용되는 max-age
- Age : Origin Server 의 응답이 프록시 캐시 서버에 머문 시간(sec)
- must-revalidate : 캐시 만료후 최초 조회시 Origin Server 에 검증
프록시 캐시
사용자와 웹 서버 사이에 위치하여 오리진 서버까지 요청하지 않고 프록시 서버에 저장된 캐시된 데이터를 이용하는 방식
프록시 서버에 캐시가 있어 public 캐시라 한다.
HTTP Response Heaer의 Cache-Control값에 'public' 값으로 설정을 해야 한다.
CDN
최종 사용자에게 가까운 엣지 서버에 캐시된 콘텐츠를 저장 및 제공하여 사용자에게 콘텐츠를 빠르게 제공한다.
포워드 프록시
클라이언트가 인터넷에 직접 접근하는게 아니라 포워드 프록시가 요청을 받고 인터넷에 연결하여 서버 응답을 클라이언트에게 전달
캐시를 자주 사용하는 데이터라면 서버에 요청을 보내지 않고 캐시에서 가져와 응답하기 때문에 성능 향상이 가능하다
흔히 말하는 프록시 서버가 포워드 프록시 서버이다.
장점
- 클라이언트 보안
- 방화벽같은 개념으로 인트라넷에서 특정 사이트에 접속하는 것을 막는다.
- 캐싱
- 암호화
- 포워드 프록시 서버를 통과할 때 암호화 되어 클라이언트의 IP를 감춰주는 효과도 있다.
리버스 프록시
클라이언트가 인터넷에 데이터를 요청하면 리버스 프록시 서버가 해당 요청을 받아 내부 서버에서 데이터를 받은 후 클라이언트에게 응다한다.
웹 서비스에 접근할 때 웹 서버에 요청하는 것이 아닌, 프록시 서버로 요청하게 되고, 프록시 서버가 배후의 서버로부터 데이터를 가져오는 방식
💡 우리가 일반적으로 구성하는 WEB(Apache, Ngnix) <-> WAS(Tomcat) 분리 형태를 리버스 프록시 형태라고 보면 된다. 여기서 WEB(Apache, Nginx) 가 Reverse Proxy 가 된다. 하지만 만약 WEB, WAS가 한 서버에 존재한다면 Reverse Proxy 라고 볼 수 없다.
장점
- 로드 밸런싱
- 특정 서버가 과부화 되지 않도록 로드 밸런싱
- 서버 보안
- 본래 서버의 IP 주소를 노출시키지 않을 수 있어 보안에 좋다.
- 캐싱
- 포워드 프록시의 캐싱과 비슷한 기능을 한다.
- 암호화
- SSL 암호화
포워드 프록시 VS 리버스 프록시
참고
https://hahahoho5915.tistory.com/32
https://www.youtube.com/watch?v=-2TgkKYmJt4
https://velog.io/@wiostz98kr/CORS%EC%9D%98-%EB%AA%A8%EB%93%A0-%EA%B2%83
https://www.youtube.com/watch?v=Tm2mja5_dZs&t=783
https://www.youtube.com/watch?v=bSGqBoZd8WM
https://www.youtube.com/watch?v=qzas_-u4Nxk
https://dev-jwblog.tistory.com/161
'외부활동 > CS 면접 끝장내기 - 컴퓨터 네트워크 2기' 카테고리의 다른 글
| 컴퓨터 네트워크 4주차 스터디 정리 (0) | 2023.08.13 |
|---|---|
| 컴퓨터 네트워크 3주차 스터디 정리 (0) | 2023.08.07 |
| 컴퓨터 네트워크 2주차 스터디 정리 (0) | 2023.07.30 |
| 컴퓨터 네트워크 1주차 스터디 정리 (0) | 2023.07.23 |
댓글