[Network] #5 Application Layer

이 포스트에서는 지난 포스트에 이어 Application Layer 관련 내용들을 정리했다.

 

쿠키와 세션

쿠키는 만료기한이 있는 키-값 저장소이며,  SameSite 옵션을 strict로 설정하지 않았을 경우 다른 도메인에서 요청했을 때 자동 전송되며, 4KB까지 데이터를 저장할 수 있고, 만료 기한을 정할 수 있다.

 

쿠키를 설정할 때는 document.cookie로 쿠키에 접근할 수 없게 HttpOnly 옵션을 거는 것이 중요하며, 클라이언트 또는 서버에서 만료기한 등을 정할 수 있는데 보통 서버에서 만료기한을 정한다.

 

세션은 만료기한이 없는 키-값 저장소, 5MB까지 저장할 수 있다. 로컬 스토리지와 다르게 탭 단위로 세션 스토리지를 형성하며, 탭을 닫을 때 해당 데이터가 삭제된다. HTML5를 지원하지 않는 웹 브라우저에서는 사용할 수 없다. 클라이언트에서만 수정 가능하다.

 

JWT

JWT란 JSON Web Token을 의미하며, Header, Payload, Signature로 이루어져 있고. JSON 객체로 인코딩되고 메시지 인증이나 암호화에 사용된다. 각 부분에 대한 설명은 아래와 같다.

• Header - 토큰 유형과 서명 알고리즘
• Payload - 데이터, 토큰 발급자, 토큰 유효 기간
• Signature - Header와 Payload를 각각 BASE64로 인코딩 한 후 서버의 비밀키와 합쳐서 Header에 정의한 알고리즘으로 암호화한 값

SOP

SOP(Same-Origin Policy)는 브라우저 상에서 오로지 같은 오리진끼리만 요청을 허가하는 보안정책을 말한다.

 

CORS

CORS(cross origin resource sharing)란 HTTP 헤더를 기반으로 브라우저가 다른 오리진에 대한 리소스 로드를 허용할지 말지에 대한 메커니즘을 의미한다.

 

RESTful API의 정의와 특징

정의

REST API의 설계 규칙을 잘 지켜서 설계된 API를 RESTful한 API라고 한다.

 

특징 (출처)

1. Uniform-Interface
   동일한 리소스에 대한 모든 API 요청은 요청의 출처에 관계없이 동일하게 표시되어야 합니다. REST API는 사용자의 이름 또는 이메일 주소와 같은 동일한 데이터가 하나의 통합 리소스 식별자(URI)에만 속하도록 해야 합니다. 리소스가 너무 커서는 안 되며 클라이언트가 필요로 할 수 있는 모든 정보를 포함해야 합니다.
2. Stateless
   REST API는 무상태성이기 때문에 각 요청에는 처리에 필요한 모든 정보가 포함되어야 합니다. 즉, REST API에는 서버 측 세션이 필요하지 않다는 의미입니다. 서버 애플리케이션은 클라이언트 요청과 관련된 데이터를 저장할 수 없습니다.
3. Cacheable
   가능한 경우 클라이언트나 서버 측에서 리소스를 캐시할 수 있어야 합니다. 서버 응답에는 전달된 리소스에 대해 캐싱이 허용되는지 여부에 대한 정보도 포함되어야 합니다. 목표는 클라이언트 측의 성능을 향상시키는 동시에 서버 측의 확장성을 높이는 것입니다.
4. Client-Server 구조
   REST API 설계에서 클라이언트 및 서버 애플리케이션은 서로 완전히 독립적이어야 합니다. 클라이언트 애플리케이션이 알아야 하는 유일한 정보는 요청된 리소스의 URI입니다. 서버 애플리케이션과 다른 방법으로 통신할 수 없습니다. 마찬가지로 서버 애플리케이션은 HTTP를 통해 요청된 데이터에 클라이언트 애플리케이션을 전달하는 것 외에는 클라이언트 애플리케이션을 수정해서는 안 됩니다.
5. Layered System
   REST API에서는 호출과 응답이 서로 다른 계층을 거칩니다. 일반적으로 클라이언트와 서버 애플리케이션이 서로 직접 연결된다고 가정하지 않습니다. 통신 루프에는 다양한 중개자가 있을 수 있습니다. REST API는 클라이언트나 서버가 최종 애플리케이션과 통신하는지 중개자와 통신하는지 알 수 없도록 설계해야 합니다.
6. Code on demand
   REST API는 일반적으로 정적 리소스를 전송하지만 경우에 따라 응답에 실행 코드(예: Java 애플릿)가 포함될 수도 있습니다. 이러한 경우 코드는 온디맨드 방식으로만 실행되어야 합니다.

URI와 URL, URN의 관계

URI는 URL과 URN을 포함한다.

• URI(Identifier): 인터넷 상에서 다양한 자원들의 식별을 위해 사용되는 체계
• URL(Location): 인터넷 상에서 자원의 위치 식별을 위해 사용됨
• URN(Name): 인터넷 상에서 자원을 가리키는 이름
  
  

XSS vs CSRF vs SQL Injection: 각 공격의 정의와 방어법

1. XSS

정의: 공격자가 악성 스크립트를 웹사이트에 삽입하여, 다른 사용자가 해당 웹사이트를 방문할 때 실행되도록 하는 공격이다. 공격자는 이를 통해 사용자 정보(쿠키, 세션 등)를 탈취하거나, 사용자에게 악성 코드를 실행시킬 수 있다.

방어법: 입력 검증, 출력 인코딩, CSP, HttpOnly/Secure 플래그

 

2. CSRF

정의: 사용자가 의도하지 않은 요청을 다른 사이트에 보내는 공격이다. 공격자는 사용자가 인증된 세션을 가지고 있을 때, 사용자가 모르게 악의적인 요청을 보내도록 유도한다.

방어법: CSRF 토큰 사용, SameSite 쿠키 속성, Referer 검증

 

3. SQL Injection

정의: 사용자가 입력한 데이터를 SQL 쿼리문에 삽입하여 데이터베이스를 조작하거나, 데이터베이스에 대한 비정상적인 접근을 유도하는 공격이다. 공격자는 SQL 쿼리를 악의적으로 변경하여 데이터베이스의 민감한 정보를 탈취하거나 수정할 수 있다.

방어법: Prepared Statements, ORM 사용, 입력 검증, 권한 분리

 

프록시 서버 vs 리버스 프록시 서버

Proxy Server

 

프록시 서버는 클라이언트 앞에 위치하여, 인터넷의 사이트 및 서비스에 요청하면 프록시 서버가 이런 요청을 가로채고 중개자처럼 해당 클라이언트를 대신하여 웹 서버와 통신한다. 즉, 프록시 서버에서는 A가 C 대신 B에 요청을 보내고, C가 B에게 응답을 보내고, B가 응답을 A에게 다시 전달한다.

Reverse Proxy Server

 

리버스 프록시 서버는 하나 이상의 웹 서버 앞에 위치하여 클라이언트의 요청을 가로채는 서버이다. 리버스 프록시를 사용하면 클라이언트가 웹 사이트의 origin server에 요청을 보낼 때 리버스 프록시 서버가 Network Edge에서 해당 요청을 가로챈다. 그런 다음 리버스 프록시 서버가 origin server에 요청을 보내고 응답을 받는다. 즉, D의 모든 요청은 F 대신 E로 직접 이동하고, E는 요청을 F에게로 보내며 F로부터 응답을 받습니다. 그 다음, E는 적절한 응답을 D에게 전달한다.

 

다시 말해, 프록시 서버는 origin server가 특정 클라이언트와 직접 통신하지 못하도록 한다. 반면, 리버스 프록시 서버는 어떤 클라이언트도 origin server와 직접 통신하지 못하도록 막는다.

 

로드 밸런서

L4 로드 밸런서와 L7 로드 밸런서

 

L7 스위치를 로드밸런서라고도 부르며, 서버의 부하를 IP, PORT, URL, 헤더, 쿠키 등을 기반으로 분산시키는 기기이다. 서버 이중화와 보안에 강점이 있다. 헬스 체크를 통해 장애가 발생한 서버를 확인하고 해당 서버로 트래픽을 보내지 못하게 하는 역할을 한다.

 

프록시 서버, 리버스 프록시 서버, 로드 밸런서와 관련해서 매우 자세하게 설명한 포스트가 있어 나중에 더 공부하기로 했다.

 

커넥션 타임아웃과 리드 타임아웃

커넥션 타임아웃은 클라이언트가 서버와 연결을 시도할 때, 연결을 시작하기 위해 걸리는 최대시간이며, 그 안에 서버와 연결이 되지 않으면 실패로 간주된다.

 

리드 타임아웃은 서버와 연결이 성공한 후, 클라이언트가 데이터를 요청하고 서버가 응답하는 데 걸리는 최대 시간이다. 응답이 지연되면 실패로 간주된다.