[네트워크] 웹 보안 및 네트워크 기초

1. 쿠키와 세션

1-1. 쿠키란?

쿠키는 작은 데이터 조각으로, 웹 클라이언트(브라우저)에 저장됩니다. 주로 이름과 값의 쌍으로 구성되며, 웹 사이트가 사용자의 정보를 기억하기 위해 사용됩니다.

• 용도:
  • 사용자의 로그인 상태 유지
  • 사용자의 선호 언어나 테마 등의 설정 정보 저장
  • 방문 횟수나 광고 클릭 수 등의 트래킹
• 장기성: 쿠키는 만료 날짜가 정해져 있으며, 그 시점까지 브라우저에 저장됩니다.

1-2. 세션의 정의와 기능

세션은 서버 측에 저장되는 사용자 정보로, 일련의 상호작용을 하나의 상태로 묶기 위해 사용됩니다. 쿠키와 달리 보안에 민감한 정보를 저장하기 적합하며, 각 사용자마다 고유한 세션 ID를 통해 구분됩니다.

• 세션 ID: 사용자마다 고유한 ID. 보통 쿠키를 통해 클라이언트에 전송되며, 이를 통해 서버는 사용자를 식별합니다.
• 용도:
  • 사용자 로그인 후의 상태 유지 (장바구니, 개인화된 설정 등)
  • 보안이 필요한 데이터의 일시적인 저장 (예: 결제 정보)
• 수명: 세션은 일정 시간 동안만 유효하며, 그 후에는 서버에서 자동으로 삭제됩니다.

1-3. 쿠키와 세션의 차이점 및 사용 사례

두 기술 모두 웹에서 사용자 정보를 저장하고 관리하는 데 사용되지만, 여러 면에서 차이점이 있습니다.

• 저장 위치:
  • 쿠키: 클라이언트의 브라우저
  • 세션: 서버 측
• 보안:
  • 쿠키: 암호화되지 않은 텍스트 형태로 저장될 수 있어, 중요한 정보를 저장하기에는 적합하지 않습니다.
  • 세션: 서버에 저장되므로 상대적으로 보안성이 높습니다.
• 수명:
  • 쿠키: 만료 날짜가 지정되어 있거나, 브라우저 세션과 동일하게 설정될 수 있습니다.
  • 세션: 사용자의 활동이 없는 일정 시간 후에 만료됩니다.
• 용량:
  • 쿠키: 각 쿠키는 보통 4KB의 데이터를 저장할 수 있습니다.
  • 세션: 서버의 설정에 따라 다르지만, 일반적으로 더 큰 데이터를 저장할 수 있습니다.

---

2. 웹에서의 보안 이슈와 대응 방안

2-1. SOP (Same-Origin Policy)의 정의와 목적

• 정의: SOP는 웹 브라우저에 내장된 보안 기능으로, 스크립트가 다른 출처의 리소스에 접근하는 것을 제한합니다.
• 보안 메커니즘으로서의 SOP: 웹 페이지는 수많은 리소스로 구성됩니다. 만약 SOP가 없다면 악의적인 스크립트가 사용자의 데이터를 탈취하거나 변조할 수 있습니다.
• 다른 출처의 리소스 요청을 제한하는 이유: 이는 사용자의 정보와 데이터를 보호하기 위한 목적입니다. 특히 인터넷 은행거래나 개인 정보를 처리하는 웹페이지에서 이는 중요한 의미를 지닙니다.

2-2. CORS (Cross-Origin Resource Sharing) 원칙과 작동 방식

• SOP의 제한을 풀기 위한 CORS: 때로는 다른 출처의 리소스에 접근해야 하는 경우가 있습니다. 이때 CORS를 설정하여 안전하게 리소스 공유를 할 수 있습니다.
• 서버 설정 예제

// 예시로 Express.js 사용
app.use(cors({
    origin: 'http://example.com'
}));

• 클라이언트에서의 활용: 클라이언트에서는 서버가 보내준 CORS 헤더를 확인하여 안전하게 데이터를 요청하거나 전송할 수 있습니다.

2-3. XXS (Cross-Site Scripting) 공격과 예방 방법

• XXS의 정의: 공격자가 웹 페이지에 악의적인 스크립트를 주입하는 공격 기법입니다.
• 공격 시나리오: 예를 들어, 댓글 기능이 있는 웹페이지에서 스크립트를 포함한 댓글을 작성하면, 이 페이지를 방문하는 모든 사용자의 브라우저에서 해당 스크립트가 실행될 수 있습니다.
• 안전한 코드 작성과 예방 기법: 사용자 입력을 그대로 출력하지 말고, 항상 입력값을 검증하거나 이스케이프 처리해야 합니다.

2-4. SQL Injection의 위험성과 보호 기법

• 공격 원리: 사용자 입력값을 그대로 SQL 쿼리에 포함시킬 경우, 악의적인 쿼리를 주입받아 데이터베이스가 탈취되거나 변조될 위험이 있습니다.
• 파라미터화된 쿼리와 ORM의 활용: 입력값을 직접 쿼리에 넣는 것이 아니라, 파라미터로 전달하는 방식을 사용하거나 ORM(Object Relational Mapping)을 사용하여 SQL Injection을 방지할 수 있습니다.

---

3. REST API

3-1. REST API의 정의

REST (Representational State Transfer)는 웹의 장점을 최대한 활용할 수 있는 아키텍처 중 하나입니다. REST API는 이 REST 아키텍처를 따르는 웹 서비스 API를 의미합니다.

3-2. 웹 상의 상호 운용성을 제공하는 방식

웹에서 정보는 리소스로 표현되며, 이 리소스는 URL(Uniform Resource Locator)에 의해 고유하게 식별됩니다. RESTful 웹 서비스는 표준 HTTP 메서드를 사용하여 이 리소스와 상호작용합니다.

• GET : 리소스를 조회합니다.
• POST : 새로운 리소스를 생성합니다.
• PUT : 리소스를 수정합니다.
• DELETE : 리소스를 삭제합니다.

3-3 CRUD 연산과 그 표현 방식

웹 서비스에서 데이터 관련 작업은 주로 CRUD(Create, Read, Update, Delete) 연산을 기반으로 합니다. REST API에서는 다음과 같이 이를 표현합니다:

• Create : POST 메서드를 사용
• Read : GET 메서드를 사용
• Update : PUT 메서드를 사용
• Delete : DELETE 메서드를 사용

3-4. REST API의 제약 조건

REST는 여섯 가지의 주요 제약 조건을 갖습니다:

1. Client-Server Architecture : 클라이언트와 서버의 역할이 명확히 구분됩니다.
2. Stateless : 각 요청은 서버에서 어떠한 상태 정보도 유지하지 않습니다.
3. Cacheable : 클라이언트는 응답을 캐싱할 수 있어야 합니다.
4. Layered System : 클라이언트는 종단 시스템만을 바라봅니다. 중간 서버가 있을 수 있습니다.
5. Uniform Interface : 인터페이스의 일관성을 유지해야 합니다.
6. Code-on-Demand (optional) : 필요에 따라 클라이언트에 코드를 전송할 수 있어야 합니다.

3-5. 실제 API 구현 예제와 활용 방안

from flask import Flask, jsonify, request

app = Flask(__name__)

tasks = []

@app.route('/tasks', methods=['GET'])
def get_tasks():
    return jsonify(tasks)

@app.route('/tasks', methods=['POST'])
def add_task():
    new_task = request.json
    tasks.append(new_task)
    return jsonify(new_task), 201

# ... (PUT, DELETE 메서드 구현 부분 등)

---

4. 토큰과 웹 인증

4-1. 토큰의 기본 개념

토큰은 간단히 말하면 시스템이 사용자를 식별하기 위한 임시적인 정보입니다. 로그인 후에 서버는 토큰을 생성하여 클라이언트에게 전달하게 되고, 클라이언트는 이 토큰을 사용하여 서버에 요청을 보낼 때 자신을 인증합니다.

4-2. 디지털 인증의 핵심 요소로서의 토큰

토큰 기반 인증은 다음과 같은 이유로 널리 사용되고 있습니다:

1. 상태 유지 불필요: 서버는 토큰이 유효한지만 확인하면 되므로, 전통적인 세션 기반 인증보다 메모리 사용량이 줄어듭니다.
2. 확장성: 로드 밸런서나 여러 서버 사이에서도 쉽게 인증 정보를 공유할 수 있습니다.
3. 보안: 토큰은 일정 시간이 지나면 만료되기 때문에, 도난당할 위험이 상대적으로 낮습니다.

4-3. JWT와 같은 토큰 형식 소개

JWT (JSON Web Token)는 현재 가장 널리 사용되는 토큰 형식 중 하나입니다. JWT는 헤더, 페이로드, 시그니처의 세 부분으로 구성되어 있습니다. 헤더는 토큰의 타입과 해싱 알고리즘 정보를 담고 있으며, 페이로드에는 실제 인증에 필요한 데이터를 담게 됩니다. 시그니처는 서버에서 비밀키를 사용하여 생성되며, 이를 통해 토큰의 무결성을 검증할 수 있습니다.

4-4. 토큰의 사용 예와 보안

1. 사용 예
   • 로그인 시: 사용자가 로그인을 하면, 서버는 사용자 정보와 일정한 비밀 정보를 기반으로 토큰을 생성하여 반환합니다.
   • API 요청 시: 클라이언트는 이 토큰을 헤더나 본문에 포함시켜 서버에 요청을 보냅니다. 서버는 토큰을 검증하고 요청을 처리합니다.
2. 보안
   • 만료 시간 설정: 토큰의 유효기간을 짧게 설정하여 토큰이 탈취될 위험을 줄입니다.
   • HTTPS: 통신 경로를 암호화하여 토큰을 중간에서 가로채는 것을 방지합니다.
   • 블랙리스트: 특정 토큰을 무효화하고 싶을 때 사용하는 방법입니다.

토큰 기반 인증은 현대 웹과 모바일 앱에서 광범위하게 사용되고 있으며, 그 효율성과 보안성 때문에 앞으로도 계속 주목받을 기술 중 하나입니다.

5. 웹 식별자 (URL, URN, URI)

5-1. URI (Uniform Resource Identifier)

• 정의: 웹 상의 리소스를 고유하게 식별하기 위한 문자열입니다.
• 용도: 웹에 있는 모든 자원 (텍스트, 이미지, 다운로드 가능한 파일, 서비스 등)에 대한 고유한 주소나 이름을 제공합니다.
• 예제: https://www.example.com, mailto:john.doe@example.com, ftp://files.example.com

5-2. URL (Uniform Resource Locator)

• 정의: 웹 리소스의 위치를 나타내며, 해당 리소스에 액세스하기 위한 프로토콜을 포함한 특정한 형태의 URI입니다.
• 용도: 웹 리소스의 실제 위치를 특정하고, 어떻게 그 자원에 접근할 수 있는지도 나타냅니다.
• 예제: https://www.example.com/pages/about.html, ftp://files.example.com/download.zip

5-3. URN (Uniform Resource Name)

• 정의: 웹 리소스의 이름을 나타내는, 위치에 독립적인 특정한 형태의 URI입니다.
• 용도: 리소스의 영구적인, 위치에 독립적인 이름을 제공합니다. 이 이름은 시간이 지나도 변하지 않으므로, 실제 위치가 변경되더라도 해당 리소스를 찾아낼 수 있습니다.
• 예제: urn:isbn:0451450523 (책의 ISBN 번호를 나타냄)

5-4. 차이점 및 관계

• URI는 가장 광범위한 개념으로, URL과 URN은 모두 URI의 하위 카테고리입니다.
• URL은 **"어디에 있는가?"**를, URN은 **"무엇인가?"**를 나타냅니다.
• 실제 웹 개발에서는 대부분 URL을 사용하게 되지만, URN은 도서, 특허, 표준 등을 나타내기 위해 사용되기도 합니다.

---

6. 웹 최적화 (웹 캐시, 프록시 서버)

6-1. 웹 캐시의 역할 및 중요성

1. 웹 성능 향상을 위한 캐싱의 필요성

웹 캐시는 사용자의 브라우저나 서버 사이에 위치하여 자주 사용되는 웹 리소스를 임시로 저장하는 기술입니다. 캐시를 통해 서버의 부하를 줄이고, 빠른 응답 시간을 제공하며, 데이터 사용량을 줄일 수 있습니다.

2. 캐시의 종류 및 활용 방안

• 브라우저 캐시: 사용자의 브라우저에 저장되며, 재방문 시 리소스 다운로드 없이 해당 리소스를 활용합니다.
• CDN (Content Delivery Network): 전 세계 여러 위치에 데이터 센터를 두고 사용자에게 가장 가까운 위치에서 리소스를 제공하여 속도를 높입니다.
• 프록시 캐시: 기업 네트워크 등에서 사용되며, 여러 사용자가 요청하는 동일한 리소스를 캐시하여 중복 다운로드를 방지합니다.

6-2. 포워드 프록시와 리버스 프록시의 정의와 차이점

1. 각 프록시 서버의 역할과 활용 케이스

• 포워드 프록시: 클라이언트와 인터넷 사이에 위치하며, 사용자의 요청을 대신 전송하고 결과를 반환합니다. 주로 보안 및 접근 제어, 캐싱 등의 목적으로 사용됩니다.
  • 기업 네트워크에서 특정 사이트의 접근을 제한하거나 모니터링하는 경우
  • 사용자의 IP를 숨기고자 할 때 (예: VPN)
• 활용 케이스:
• 리버스 프록시: 서버와 클라이언트 사이에 위치하여 클라이언트의 요청을 받아 해당 요청을 내부 서버로 전달하고 그 응답을 클라이언트에게 반환합니다. 주로 부하 분산, SSL 암호화, 캐싱 등의 목적으로 사용됩니다.
  • 여러 대의 서버로 부하를 분산하고자 할 때
  • 일관된 SSL 암호화를 제공하고자 하는 경우
• 활용 케이스:

2. 설정 예제와 최적화 전략

포워드 프록시 예제: Squid는 대표적인 포워드 프록시 소프트웨어입니다. Squid를 설정하여 특정 사이트의 접근을 제한하거나 캐싱 기능을 활용할 수 있습니다.

리버스 프록시 예제: Nginx나 Apache와 같은 웹 서버 소프트웨어를 리버스 프록시로 설정할 수 있습니다. 설정을 통해 부하 분산이나 SSL 종단 간 암호화를 적용할 수 있습니다.