[Network 스터디 6회차]

쿠키나 세션, 토큰이 필요한 이유
HTTP는 기본적으로 상태가 없는(stateless) 프로토콜이기 때문에, 이전 요청과 관련된 정보가 새로운 요청에 자동으로 전달되지 않기에, HTTP 상태를 유지하기 위해 클라이언트와 서버가 상호작용시 이전 정보를 기억할 수 있게 해주는 방법으로 사용한다.

쿠키

쿠키(Cookie)는 웹사이트에서 사용자의 정보를 추적하고 관리하기 위해 사용되는 기술 중 하나로, 웹사이트가 사용자의 컴퓨터에 저장하는 작은 텍스트 파일이다.

쿠키를 통한 HTTP 상태유지 작동 방식

1. 클라이언트가 서버에 처음 요청을 보낸다.
2. 서버는 응답과 함께 Set-Cookie 헤더를 사용하여 쿠키를 클라이언트에게 전달합니다. 이 헤더는 쿠키의 이름, 값, 만료일, 도메인, 경로 등의 정보를 포함한다.
3. 클라이언트는 쿠키를 브라우저에 저장한다.
4. 클라이언트가 서버에 추가 요청을 보낼 때, 브라우저는 자동으로 쿠키를 포함한 Cookie 헤더를 요청에 추가한다.
5. 서버는 클라이언트로부터 받은 쿠키 정보를 사용하여 이전 상태를 파악하고, 그에 따른 적절한 응답을 클라이언트에게 전달한다.

장점
1. 사용자 경험 개선: 사용자의 환경 설정, 로그인 상태 등과 같은 정보를 기억하여 웹 사이트 방문 시 사용자에게 맞춤화된 경험을 제공할 수 있다.
2. 서버 부하 감소: 클라이언트 측에 데이터를 저장함으로써 서버의 저장 공간과 처리 부하를 줄일 수 있다.

단점
1. 보안 문제: 쿠키는 클라이언트 측에 저장되기 때문에 악의적인 사용자가 쿠키를 탈취하거나 변조할 가능성이 있기에, 중요한 정보는 쿠키에 저장하지 않는 것이 좋다.
2. 용량 제한: 쿠키는 용량이 제한되어 있어(약 4KB) 많은 정보를 저장할 수 없다.
3. 브라우저 호환성: 일부 브라우저에서는 쿠키를 지원하지 않거나 사용자가 쿠키를 비활성화할 수 있다. 이 경우 쿠키를 사용한 상태 유지 기능이 작동하지
않기에 이러한 상황에 대비해야 한다.
4. 개인 정보 침해 우려: 쿠키는 사용자의 행동을 추적하고 개인화된 경험을 제공하기 위해 사용되기 때문에, 사용자의 개인 정보 보호에 대한 우려가 있다. 이러한 이유로 일부 사용자들은 쿠키를 비활성화하거나 정기적으로 삭제할 수 있다.

세션

세션(Session)은 사이트에서 사용자의 정보를 추적하고 관리하기 위해 사용되는 기술 중 하나로, 서버와 클라이언트 사이의 일시적인 상호작용을 의미한다.

세션을 통한 HTTP 상태유지 작동 방식

1. 클라이언트가 서버에 요청을 보낸다(예: 로그인 요청).
2. 서버는 요청을 처리한 후, 세션을 생성하고 세션 ID를 생성한다. 이 세션 ID는 클라이언트와 서버 간의 상호 작용을 식별하는데 사용된다.
3. 서버는 응답과 함께 Set-Cookie 헤더를 사용하여 세션 ID를 클라이언트에게 전달한다.
4. 클라이언트는 세션 ID를 쿠키로 저장하고, 이후 요청 시 세션 ID를 포함한 Cookie 헤더를 요청에 추가한다.
5. 서버는 클라이언트로부터 받은 세션 ID를 사용하여 해당 세션에 저장된 정보를 조회하고, 이를 기반으로 적절한 응답을 클라이언트에게 전달한다.

장점
1. 보안: 중요한 정보가 서버 측에서 관리되기 때문에 클라이언트에서 정보가 탈취되거나 변조될 가능성이 줄어든다.
2. 저장 용량: 세션은 서버에서 관리되므로 쿠키보다 더 많은 정보를 저장할 수 있다.
3. 사용자 개인화: 사용자의 환경 설정, 로그인 상태 등과 같은 정보를 저장하여 웹 사이트 방문 시 사용자에게 맞춤화된 경험을 제공할 수 있다.

단점
1. 서버 부하 증가: 세션 정보가 서버에 저장되기 때문에 서버의 저장 공간과 처리 부하가 증가할 수 있다. 이를 해결하기 위해 세션 정보를 분산 저장하거나, 서버의 자원을 적절히 관리해야 한다.
2. 세션 타임아웃: 세션은 일정 시간동안 유효하며, 이 시간이 지나면 세션 정보가 삭제된다. 따라서 사용자가 웹사이트를 오랫동안 방문하지 않을 경우, 저장된 정보가 소멸되어 사용자가 다시 로그인해야 하는 등의 불편함이 발생할 수 있다.
3. 확장성 문제: 웹 사이트의 규모가 커질수록 세션 관리에 필요한 자원과 처리 과정이 복잡해질 수 있습니다. 이를 해결하기 위해 로드 밸런서, 세션 클러스터링 등의 기술을 사용할 수 있다.

토큰

토큰은 클라이언트와 서버 간에 인증, 권한 부여, 정보 전달 등의 목적으로 사용되는 문자열로, 웹 서비스에서 상태 유지를 위한 중요한 기술이다. 토큰은 일반적으로 암호화되어 안전하게 전송되며, 서버는 토큰을 통해 사용자를 식별하고 인증한다.

토큰을 통한 HTTP 상태유지 작동 방식

1. 클라이언트가 서버에 로그인 요청을 한다.
2. 서버는 사용자의 인증 정보를 확인한 후, 토큰을 생성하고 클라이언트에게 전달한다.
3. 클라이언트는 받은 토큰을 저장한 후, 이후 요청에서 토큰을 헤더에 포함시켜 서버에 전송한다.
4. 서버는 클라이언트로부터 받은 토큰을 검증하고, 사용자의 인증 상태와 권한을 확인한다.
5. 클라이언트의 요청에 따라 서버는 적절한 응답을 전송한다.

장점
1. 상태를 저장하지 않는 서버: 토큰은 클라이언트 측에서 관리되기 때문에, 서버는 상태를 저장할 필요가 없어서, 서버의 부하를 줄이고, 확장성을 높여준다.
2. 보안성: 토큰은 암호화되어 전송되기 때문에, 사용자 인증 정보를 안전하게 보호할 수 있다.

단점
1. 토큰 크기: 토큰은 인증 정보와 메타데이터를 포함하므로, 쿠키에 비해 상대적으로 크기가 클 수 있어, 네트워크 부하가 증가할 수 있다.
2. 저장 및 관리: 클라이언트는 토큰을 저장하고 관리해야 하며, 이에 따른 보안 문제가 발생할 수 있다. 예를 들어, 토큰이 노출되거나 탈취당할 경우, 사용자의 인증 정보가 위험에 노출될 수 있다.

CORS

CORS(Cross-Origin Resource Sharing, 교차 출처 리소스 공유)는 웹 페이지가 다른 도메인의 리소스에 액세스할 수 있도록 하는 웹 보안 메커니즘이다.

Same-Origin Policy(동일 출처 정책)는 웹 보안의 핵심 원칙 중 하나로, 웹 페이지가 다른 출처의 리소스에 액세스하는 것을 제한한다. 출처는 URL의 스키마(http, https 등), 호스트(도메인) 및 포트 번호의 조합으로 구성된다. 동일 출처 정책은 사용자의 정보를 보호하고 악의적인 사이트로부터의 공격을 방지하기 위해 사용된다.

기본적으로 웹 브라우저의 보안 정책인 SOP로 인해, 웹 페이지는 동일한 출처에서만 리소스를 로드할 수 있지만, CORS를 사용하여 서버는 다른 출처의 요청에 대한 액세스를 허용할 수 있다.

CORS에 대한 프론트엔드의 관점

1. 프론트엔드 웹 애플리케이션은 다른 출처의 API나 리소스에 액세스하려 할 때, 브라우저가 자동으로 CORS 요청을 생성한다. 이 요청에는 Origin 헤더가 포함되어, 요청이 보내지는 출처를 나타낸다.
2. 브라우저는 서버로부터 받은 응답의 CORS 관련 헤더(Access-Control-Allow-Origin 등)를 검사하여, 해당 요청이 허용되는지 여부를 결정한다. 허용되면 응답을 처리하고, 그렇지 않으면 에러를 발생시킨다.

CORS에 대한 백엔드의 관점

1. 백엔드 서버는 클라이언트로부터의 요청을 받을 때, 해당 요청이 CORS 요청인지 확인한다. CORS 요청인 경우, 요청 헤더의 Origin 값을 확인하여 출처를 검사한다.
2. 서버는 서버에서 설정한 규칙에 따라 출처를 허용하거나 거부할 수 있다. 출처를 허용하는 경우, 서버는 응답 헤더에 Access-Control-Allow-Origin과 같은 CORS 관련 헤더를 추가하고, 응답을 클라이언트에 전달한다.

CORS를 사용하면 다른 출처의 리소스에 액세스할 수 있지만, 안전하게 정보를 공유하려면 백엔드 서버에서 적절한 CORS 정책을 설정해야 한다. 서버에서 너무 많은 출처를 허용하면 보안에 취약해질 수 있으므로, 필요한 출처만 허용하는 것이 좋다.

REST

REST(Representational State Transfer)는 분산 시스템을 설계하는 아키텍처 스타일로, 웹 서비스와 API의 디자인에 널리 사용된다.

REST는 웹 서비스가 확장성, 성능, 간편함, 수정 용이성, 신뢰성 등의 특징을 가지도록 설계하는 데 도움을 줍니다.

REST 아키텍처의 6가지 원칙

1. 클라이언트-서버 구조(Client-Server): 클라이언트와 서버가 독립적으로 구성되어 서로의 발전과 변화에 영향을 주지 않으면서 상호 작용한다.
2. 무상태(Stateless): 각 요청이 서버에 필요한 모든 정보를 포함하며, 서버는 클라이언트의 상태를 저장하지 않는다. 이를 통해 서버의 확장성과 관리가 용이해진다.
3. 캐시 가능(Cacheable): 서버는 응답을 캐시할 수 있는지 여부를 명시할 수 있으며, 클라이언트는 캐시된 응답을 사용해야한다. 이를 통해 클라이언트의 성능과 효율성이 향상된다.
4. 계층 구조(Layered System): 시스템은 여러 계층으로 구성될 수 있으며, 각 계층은 독립적으로 작동한다. 이를 통해 시스템의 유연성과 재사용성이 증가한다.
5. 코드 온 디맨드(Code on Demand, 선택적): 클라이언트는 서버로부터 실행 가능한 코드를 받아 기능을 확장할 수 있다. 이를 통해 클라이언트의 기능이 동적으로 변경될 수 있다.
6. 인터페이스 일관성(Uniform Interface): REST는 일관된 인터페이스를 통해 자원에 액세스하고 조작한다. 이를 통해 시스템의 단순화와 상호 운용성이 향상된다.

RESTful

RESTful이란, REST 원칙을 따르는 시스템을 의미한다. REST API의 설계 규칙을 올바르게 지킨 시스템을 RESTful하다 말할 수 있다.

REST API

REST 원칙에 따라 설계된 API(Application Programming Interface)이다. 클라이언트와 서버 간의 통신을 가능하게 하는 인터페이스로, 클라이언트가 서버의 자원에 액세스하고 조작할 수 있다.
URI는 정보의 자원을 표현해야하며, 자원에 대한 행위는 HTTP Method (GET, PUT, POST, DELETE등등)로 표현

특징

• 자원 지향(Resource-Oriented): REST API는 웹 자원을 중심으로 설계되며, 각 자원은 고유한 URI(Uniform Resource Identifier)로 식별된다.
• 표준화된 인터페이스: REST API는 일관된 인터페이스를 사용하여 자원에 액세스하고 조작한다. 이를 통해 클라이언트와 서버 간의 상호 운용성이 향상된다.
• HTTP 메서드 활용: REST API는 HTTP 메서드(GET, POST, PUT, DELETE 등)를 활용하여 자원에 대한 작업을 수행한다. 이를 통해 API의 사용이 단순화되고 이해하기 쉬워진다.
• 상태 코드(Status Code) 활용: REST API는 HTTP 상태 코드를 사용하여 요청의 결과를 명확하게 전달한다. 이를 통해 클라이언트가 에러 처리를 쉽게 수행할 수 있다.

REST 원칙에 따라 설계된 API는 확장성, 성능, 간편함 등의 이점을 제공하여, 다양한 플랫폼과 기기에서 효율적으로 사용할 수 있으며, 이를 통해 웹 서비스와 애플리케이션의 개발 및 유지 보수가 용이해진다.

XSS

XSS(Cross-Site Scripting)는 웹 사이트의 보안 취약점 중 하나로, 공격자가 웹 사이트에 악성 스크립트를 삽입하여 다른 사용자의 정보를 탈취하거나 조작하는 공격이다. XSS 공격은 주로 웹 사이트가 사용자로부터 입력 받은 데이터를 충분히 검증하지 않고 사용할 때 발생한다.

XSS의 공격방식

• Stored XSS(저장형 XSS): 공격자가 웹 사이트의 데이터베이스에 악성 스크립트를 저장하고, 다른 사용자가 해당 데이터를 조회할 때 실행되는 공격이다. 예를 들어, 게시판이나 댓글 등에 악성 스크립트를 포함한 글을 작성하는 경우이다.
• Reflected XSS(반사형 XSS): 공격자가 웹 사이트의 URL에 악성 스크립트를 포함시켜 다른 사용자가 해당 링크를 클릭할 때 실행되는 공격이다. 이메일, 메신저 등을 통해 악성 URL을 전달하는 경우가 대표적이다.
• DOM-based XSS(DOM 기반 XSS): 공격자가 웹 페이지의 DOM(Document Object Model)을 조작하여 악성 스크립트가 실행되게 하는 공격이다. 클라이언트 측에서 데이터 처리를 수행하는 자바스크립트 코드에 취약점이 있는 경우 발생한다.

XSS에 대한 대응방식

• 입력 데이터 검증: 사용자로부터 입력 받은 데이터에 대해 충분한 검증을 수행하고, 스크립트 코드가 포함되어 있는지 확인하여 악성 스크립트의 삽입을 방지할 수 있다.
• 출력 데이터 인코딩: 사용자가 입력한 데이터를 웹 페이지에 출력할 때, HTML 인코딩을 수행하여 스크립트 코드가 실행되지 않도록 한다. 예를 들어, '<'와 '>' 같은 문자를 '<'와 '>'로 변환하는 것이다.
• 콘텐츠 보안 정책(CSP, Content Security Policy): 웹 서버가 웹 페이지에 대한 보안 정책을 설정하여, 허용된 출처의 스크립트만 실행되도록 할 수 있고, 악성 스크립트의 실행을 차단할 수 있다.

SQL Injection

SQL Injection은 웹 애플리케이션의 보안 취약점 중 하나로, 공격자가 악의적인 SQL 쿼리를 주입하여 데이터베이스를 조작하거나 민감한 정보를 탈취하는 공격이다.

SQL 인젝션은 주로 웹 애플리케이션에서 사용자로부터 입력받은 데이터를 처리할 때, 충분한 검증 없이 SQL 쿼리에 사용되는 경우 발생한다.

SQL 인젝션의 대표적인 공격 방식

• 공격자가 로그인 폼의 아이디 또는 비밀번호 입력 필드에 악성 SQL 쿼리를 입력하여 인증을 우회하는 방법
• 공격자가 웹 사이트의 검색 기능을 이용하여 악성 SQL 쿼리를 주입하고, 데이터베이스에서 민감한 정보를 탈취하는 방법
• 공격자가 URL의 쿼리 문자열에 악성 SQL 쿼리를 포함시켜 서버에 전달하고, 웹 애플리케이션이 그대로 쿼리를 실행하여 공격에 성공하는 방법

SQL 인젝션 공격에 대한 대응 방식

• 입력 데이터 검증: 사용자로부터 입력 받은 데이터에 대해 충분한 검증을 수행하고, SQL 쿼리에 사용되기 전에 필터링하는 것이 중요하다. 이를 통해 악성 쿼리의 주입을 방지할 수 있다.
• 파라미터화된 쿼리 사용: 데이터베이스 쿼리에 사용자 입력 값을 직접 포함시키지 않고, 파라미터를 사용하여 값이 쿼리에 대입되도록 한다. 이를 통해 공격자가 쿼리의 구조를 변경할 수 없게 만들 수 있다.
• 저장 프로시저 사용: 저장 프로시저를 사용하면 SQL 쿼리의 구조를 고정시킬 수 있어, 공격자가 쿼리를 변경하는 것을 어렵게 만든다. 하지만 저장 프로시저 자체에 취약점이 없도록 주의해야 한다.
• 최소 권한 원칙 적용: 데이터베이스 계정에 대해 최소한의 권한만 부여하여, 공격자가 성공한 경우에도 피해를 최소화할 수 있다.

URL, URI, URN

URI (Uniform Resource Identifier): 인터넷에서 자원을 식별하는 고유한 문자열이다.

URL (Uniform Resource Locator): 인터넷에서 자원의 위치를 나타내는 문자열이다. URL은 프로토콜(예: HTTP, FTP), 도메인, 경로, 쿼리 문자열 등을 통해 자원의 위치를 표현한다. 예를 들어, "https://www.example.com/index.html"과 같은 형태를 가진다.

URN (Uniform Resource Name): 인터넷에서 자원의 고유한 이름을 나타내는 문자열이다. URN은 자원의 실제 위치와 관계없이 고유한 이름을 부여하며, 자원의 이름만으로 식별이 가능하다. 예를 들어, "urn:isbn:0451450523"과 같은 형태를 가집니다.

• URI는 인터넷 자원을 식별하기 위한 가장 상위 개념으로, URL과 URN을 포함합니다.
• URL은 자원의 실제 위치를 나타내는 것으로, 프로토콜, 도메인, 경로 등을 포함하여 자원의 위치를 명시적으로 표현합니다.
• URN은 자원의 고유한 이름을 나타내는 것으로, 자원의 실제 위치와 관계없이 자원을 식별할 수 있는 고유한 이름을 부여합니다.

웹 캐시

웹 캐시는 웹 페이지나 파일 등의 자원을 일시적으로 저장해두는 저장소를 의미한다. 웹 캐시를 사용하면 이전에 요청했던 자원을 빠르게 다시 불러올 수 있다. 웹 캐시는 주로 웹 브라우저, 프록시 서버, CDN(Content Delivery Network) 등에서 사용된다.

웹 캐시를 사용했을 때의 이점

• 네트워크 부하 감소: 캐싱된 자원은 원본 서버에서 다시 요청할 필요가 없기 때문에, 네트워크 트래픽과 서버 부하를 줄일 수 있다.

• 빠른 로딩 속도: 캐싱된 자원은 로컬 저장소나 가까운 프록시 서버에서 불러올 수 있으므로, 원격 서버에서 자원을 가져오는 것보다 훨씬 빠르게 로딩된다. 이로 인해 사용자 경험이 향상되며, 웹 사이트의 성능이 개선된다.

• 대역폭 절약: 캐싱된 자원은 원본 서버와의 통신을 최소화하기 때문에, 대역폭 사용량을 줄일 수 있다. 이는 특히 데이터 전송 비용이 중요한 모바일 환경에서 큰 이점이 된다.

• 내구성과 가용성 향상: 원본 서버에 문제가 발생하거나 접속이 불가능한 경우에도, 캐싱된 자원을 통해 웹 사이트의 일부 기능이나 콘텐츠를 계속 사용할 수 있다.

웹 캐시를 사용하면 네트워크 부하를 줄이고, 로딩 속도를 높이며, 대역폭을 절약하고, 서비스의 내구성과 가용성을 향상시킬 수 있지만, 웹 캐시를 사용할 때 주의해야 할 점도 있다.
예를 들어, 캐시된 자원이 최신 정보를 반영하지 못하는 경우가 있을 수 있으므로, 캐시 정책을 적절하게 설정하고 관리해야 한다.

웹 프록시

웹 프록시란 클라이언트와 서버 간의 통신을 중계하는 중간 서버다. 클라이언트가 서버에 요청을 보내면, 웹 프록시가 그 요청을 받아 서버로 전달하고, 서버로부터 받은 응답을 클라이언트에게 전달한다. 웹 프록시는 보안, 성능 최적화, 로드 밸런싱 등 다양한 목적으로 사용된다.

웹 프록시의 사용 예시:

• 캐싱: 웹 프록시는 자주 사용되는 웹 페이지나 파일을 캐시하여 저장해두고, 캐싱된 자원이 요청될 때 원본 서버에 접근하지 않고 빠르게 응답할 수 있다.
• 필터링: 웹 프록시를 사용하여 특정 웹 사이트에 대한 접근을 차단하거나, 악성 코드가 포함된 사이트를 필터링할 수 있다.
• 익명성: 웹 프록시를 통해 서버와의 통신이 이루어지기 때문에, 클라이언트의 IP 주소를 숨기고 실제 원격 서버에 익명으로 접근할 수 있다.

웹 프록시는 주로 포워드 프록시와 리버스 프록시로 구분된다.

포워드 프록시

포워드 프록시는 클라이언트 측에서 사용되며, 클라이언트의 요청을 원격 서버로 전달하여, 캐싱, 필터링, 익명성 보장 등의 기능을 제공한다. 예를 들어, 기업이나 학교 네트워크에서 특정 웹 사이트에 대한 접근을 제한하거나, 개인정보를 보호하기 위해 포워드 프록시를 사용할 수 있다.

리버스 프록시

리버스 프록시는 서버 측에서 사용되며, 외부 클라이언트의 요청을 내부 서버로 전달하여 로드 밸런싱, SSL 암호화, 캐싱 등의 기능을 제공한다. 예를 들어, 웹 서비스에서 리버스 프록시를 사용하여 여러 서버에 분산된 요청을 처리하거나, 안전한 암호화 통신을 위해 SSL 인증서를 관리할 수 있다.