카테고리 없음

[컴퓨터네트워크] 쿠키, 세션, REST, 프록시, 로드밸런싱

ヽ(°ᴥ°)ﾉ 2024. 3. 21. 23:36

1. 쿠키 & 세션 & 토큰

  • HTTP의 stateless, connectionless 특징때문에, 정보를 유지하고 있을 수 없다
  • ex) 로그인하고나서도 매 페이지에서 로그인해야됨

1-1. 쿠키

- 브라우저에 저장되는 키-밸류로 이루어진 작은 데이터 파일

  • 저장위치 : 클라이언트(브라우저)
  • 저장형식 : key-value
  • 사용예시 : 
    • 오늘 더이상 보지않음 체크

1-2. 세션

- 일정 시간동안 같은 사용자(브라우저)로부터 들어오는 일련의 요구를 하나의 상태로 보고, 그 상태를 서버에서 관리해서 유지시키는 기술

  • 저장위치 : 서버
  • 서버에서는 클라이언트를 구분하기 위해 세션ID 부여

1-3. 쿠키 vs 세션

  • 세션이 쿠키보다 보안 좋은 이유?
    • 세션은 정보를 서버측에 저장해놓기 때문에 보안 측면에서 쿠키보다 우수하다. 즉, 중요한 정보가 클라이언트의 브라우저에 직접 저장되지 않기 때문에 쿠키가 탈취되어도 정보가 노출될 위험이 적다. 쿠키는 클라이언트 측에서 직접 변경할 수 있지만, 세션은 서버에서만 변경 가능
  • 세션과 쿠키의 라이프사이클
    • 쿠키의 생명주기 : set-Cookie: expires (날짜 만료일 설정) / max-age (특정 시간 지나면)
    • 세션의 생명주기 : 유효시간을 설정해 일정시간 응답이 없으면 끊거나, 브라우저가 종료되면 끊김

1-4. 토큰

- JWT 인증에 필요한 정보들을 Json 객체에 담은 후 비밀키로 서명한 토큰입니다. 서버/클라이언트 사이에서 인증/인가를 수행하기 위해 사용합니다. 

- 헤더(header), 페이로드(payload), 시그니처(signature) 부분으로 이루어져있고, 각 부분은 점(.)으로 구분

- 헤더 : 토큰의 타입과 해시 암호화 알고리즘 정보

- 페이로드 : 토큰에 담을 정보 (사용자를 구분할 수 있는)

- 시그니처 : Secret key로 정보들을 암호화한것

 

2. 출처 정책

- 모두 출처(origin)과 관련된 내용

- 출처 구분 요소 : URL의 스킴(프로토콜), 호스트(도메인), 포트 3가지로 정의

2-1. 동일 출처 정책(Same Origin Policy, SOP)

  • sop는 동일한 출처 사이에서만 리소스를 공유할 수 있도록하는 보안 정책
  • ex) http://sub.tistory.com , https://sub.tistory.com : 다른 프로토콜을 공유하므로 다름

2-2. CORS

  • CORS는 특정 출처를 서버가 명시해놓으면, 출처가 다르더라도 서버와 리소스를 주고 받을 수 있도록하는 보안 정책을 말합니다.
  • 브라우저에서는 보안적인 이유로 cross-origin HTTP 요청들을 제한하기 때문에, 요청 전에 서 서버의 동의가 필요합니다. 서버가 동의한다면 브라우저에서는 요청을 허락하고, 동의하지 않는다면 브라우저에서 거절하는 메커니즘을 CORS(Cross-Origin Resource Sharing)라고 합니다.

3. REST

  • Rest
    • 먼저 Rest란 HTTP URI를 통해 자원을 명시하고 GET, POST, PUT, DELETE 메소드를 통해 해당 자원에 대한 CRUD연산을 적용해, API 가독성을 높인 구조화된 소프트웨어 아키텍처
    • 특징
      • 클라이언트-서버 구조
        • 자원이 있는 쪽이 Server, 자원 요청하는 쪽이 Client
      • 무상태성
        • 서버는 각각의 요청을 완전히 별개의 것으로 인식하고 처리, 즉 이전요청이 다음 요청 처리에 연관되지않음
      • 캐시처리 등등
  • Rest API
    • Rest API란 REST의 특징을 기반으로 서비스 API를 구현한 것을 말합니다. REST API의 가장 큰 특징은 각 요청이 어떤 동작이나 정보를 위한 것인지를 그 요청의 모습 자체로 추론이 가능한 것 입니다.
  • Restful API
    • 대개, REST 원리를 따르는 시스템을 RESTful하다고 말한다.
    • 목적
      • 이해하기 쉽고 사용하기 쉬운 REST API를 만드는 것 → API의 목적을 명확히 하기 위함
      • RESTful한 API를 구현하는 근본적인 목적이 성능 향상에 있는 것이 아니라 일관적인 컨벤션을 통한 API의 이해도 및 호환성을 높이는 것이 주 동기이니, 성능이 중요한 상황에서는 굳이 RESTful한 API를 구현할 필요는 없다.

4. 웹 공격

4-1. SQL injection

  • 공격자가 악의적인 SQL 쿼리문을 서버에 전송하고 실행하게 해서, 데이터베이스가 비정상적인 동작을 하도록 조작하는 공격
  • 대응 방안
    • 입력값 검증
    • 미리 선언된 SQL만 사용하도록 (stored procedure)
    •  

4-2. XSS 공격 (Cross Site Scripting)

  • 웹 애플리케이션에서 많이 나타나는 취약점 중 하나로, 공격자가 클라이언트 코드에 악성 스크립트를 삽입하는 공격
  • 주로, 사용자로부터 입력 받은 값을 
    • 공격자가 웹사이트에 악성 스크립트를 심은 클릭 유도글 작성
    • 사용자가 클릭
    • 클릭한 사용자의 정보 빼냄
  • 대응 방안
    • 입력값 검증 (ex. 입력값 검증하는 필터 제작)

 

4-3. CSRF 공격 (Cross Site Request Forgery)

  • 특정 웹사이트에 인증된 사용자가 자신의 의지와 상관없이 공격자가 의도한 행위를 웹사이트에 요청하게 하는 공격
  • 위조된 요청을 서버에 보냄 -> 서버는 인증된 사용자의 유효한 요청이라 판단하고 요청 처리 (ex. 비밀번호 변경)
  • 대응 방안
    • csrf 유효성 검증 : 임의의 csrf 토큰을 생성해서, 그 값도 같이 전송하도록 인증 
    • referrer 유효성 검증 : 요청헤더의 referrer 필드 값 확인해서, 동일도메인으로부터 온 요청인지 확인

5. 프록시

5-1. 프록시 서버

  • 클라이언트와 서버간의 중계서버로, 통신을 대리 수행하하는 서버
    • 캐시, 보안, 트래픽 분산 등 여러 장점 -> 보안성, 성능, 안정성 향상시키기 위해

5-2. 포워드 프록시

  • 클라이언트 - 포워드프록시 - 인터넷 - 서버
  • 특징
    • 캐싱 : 클라이언트의 요청과, 그에 대한 응답을 
      • 전송 시간 절약, 불필요한 외부 전송 X, 서버 부하 감소
    • 익명성 : 클라이언트가 보낸 요청을 감춤
      • 서버가 응답받은 요청을 누가 보냈는지 알지 못하게함 -> 서버가 받은 요청 IP = Proxy IP

5-3. 리버스 프록시

  • 클라이언트 - 인터넷 - 리버스프록시 - 서버
  • 특징
    • 캐싱
    • 보안 : 서버 정보를 클라이언트로부터 숨김
      • 클라이언트는 리버스 프록시를 실제 서버라고 생각해서 요청
    • 로드밸런싱 : 서버의 부하를 분산시키는 것
  • ex) 우리가 구성하는 일반적인 WEB(Apache, nginx) - WAS(Tomcat) 분리 형태를 Reverse 프록시라고 보면 된다.
    여기서 WEB(Apache, nginx)가 reverse proxy가 된다.

5-4. 로드 밸런싱

  • 서버에 가해지는 부하(=Load)를 분산(=Balancing)해주는 장치 또는 기술
  • 사용 이유
    • 대량의 트래픽이 들어올때 대응하기 위한 2가지 방법
    • Scale up : 서버 하드웨어 자체의 성능을 높임
    • Scale out : 여러개의 서버를 두는 것 -> ✅ 여러대의 서버로 트래픽을 균등하게 분산시켜주는 로드밸런싱 필요
  • 서버 선택 기준
    • 라운드 로빈 : 서버에 들어온 요청을 순서대로 돌아가며 배정하는 방식
    • Least Connection : 연결 갯수가 가장 적은 서버 선택 (가장 많이 사용되는 방식)
  • 로드 밸런싱 종류
    • L4 로드 밸런싱
      • 전송 계층에서 부하 분산 -> IP, Port 번호 이용해서 부하 분산
    • L7 로드 밸런싱
      • 애플리케이션 계층에서 부하 분산
      • 사용자 요청 기준 (url, 헤더, 쿠키 등)으로 특정 서버에 트래픽 분산