웹 보안 기초: XXS, SQL Injection, REST API 및 네트워크 기술

쿠키(Cookie) & 세션 (Session)

컴퓨터 네트워크, 특히 웹에서의 사용자 인증 및 정보 저장을 위해 쿠키와 세션은 중요한 역할을 한다. 이 두 기술은 사용자의 정보와 선호도를 저장하고, 사용자를 구별하는 데 도움을 준다.

 

쿠키 (Cookie)

정의: 쿠키는 웹사이트가 사용자의 웹 브라우저에 저장하는 작은 텍스트 파일이다.

목적: 사용자의 선호도, 로그인 정보, 장바구니 정보 등을 저장하여 사용자가 웹사이트를 재방문할 때마다 동일한 정보를 다시 입력하지 않도록 돕는다.

특징:

1. 클라이언트 측에 저장된다.

2. 만료 기간이 있으며, 이 기간이 지나면 자동으로 삭제된다.

3. 보안에 취약할 수 있기 때문에 중요한 정보를 직접 저장하는 것은 권장되지 않는다.

 

세션 (Session)

정의: 세션은 서버 측에서 사용자 정보를 저장하는 방법이다. 사용자가 웹사이트에 접속할 때마다 서버는 해당 사용자에게 고유한 세션 ID를 부여한다.

목적: 사용자의 로그인 상태, 프로필 정보, 장바구니 정보 등을 저장하고 관리한다.

특징:

1. 서버 측에 저장된다.

2. 사용자가 웹사이트를 종료하거나 일정 시간 동안 활동이 없을 경우 세션은 만료될 수 있다.

3. 쿠키에 비해 보안성이 높다. 왜냐하면 사용자의 브라우저에는 세션 ID만 저장되고, 실제 데이터는 서버 측에 저장되기 때문이다.

 

쿠키와 세션의 연동

쿠키와 세션은 종종 함께 사용된다. 예를 들어, 사용자가 웹사이트에 로그인하면 서버는 해당 사용자에게 세션을 생성하고, 이 세션의 고유한 ID를 쿠키로 사용자의 브라우저에 저장할 수 있다. 사용자가 웹사이트를 재방문할 때, 브라우저의 쿠키에 저장된 세션 ID를 통해 서버는 해당 사용자의 세션 데이터에 접근할 수 있다.

결론적으로, 쿠키와 세션은 웹에서 사용자의 정보와 상태를 저장하고 관리하는 데 중요한 역할을 한다. 각각의 방법은 그 특성과 사용 목적에 따라 선택되어야 한다.

 

SOP & CORS

SOP (Same-Origin Policy)와 CORS (Cross-Origin Resource Sharing)는 웹 보안에 관련된 중요한 개념이다. 이 두 개념은 웹 페이지의 리소스가 다른 출처의 리소스와 어떻게 상호작용할 수 있는지를 정의한다.

 

SOP (Same-Origin Policy)

정의: SOP는 웹 페이지의 스크립트가 동일한 출처에서만 리소스에 접근할 수 있도록 제한하는 보안 정책이다.

목적: 악의적인 웹사이트가 사용자의 데이터를 탈취하거나 변조하는 것을 방지하기 위함이다.

동일한 출처의 기준: 프로토콜 (http, https), 도메인 (example.com), 포트 (80, 443 등)가 모두 동일해야 한다.

제한: 예를 들어, https://example.com에서 로딩된 웹 페이지의 스크립트는 SOP 때문에 https://another.com의 API나 리소스에 직접 접근할 수 없다.

 

CORS (Cross-Origin Resource Sharing)

정의: CORS는 SOP의 제한을 안전하게 완화시켜 주는 웹 표준이다. 서버는 CORS 헤더를 사용하여 특정 출처의 브라우저가 자신의 리소스에 접근할 수 있도록 허용할 수 있다.

목적: 다른 출처의 웹 페이지에서 현재 서버의 리소스에 접근할 수 있도록 허용하면서도 보안을 유지하기 위함이다.

작동 방식: 서버는 응답 헤더에 Access-Control-Allow-Origin과 같은 CORS 관련 헤더를 포함시켜, 특정 출처에서의 접근을 허용하거나 제한할 수 있다. 예를 들어, 서버가 응답 헤더에 Access-Control-Allow-Origin: https://example.com을 포함시키면 https://example.com에서 로딩된 웹 페이지는 해당 서버의 리소스에 접근할 수 있게 된다.

 

요약

SOP는 기본적으로 웹 페이지의 스크립트가 다른 출처의 리소스에 접근하는 것을 제한하는 보안 정책이다.

CORS는 이러한 SOP의 제한을 안전한 방법으로 완화시켜주는 메커니즘이다. 서버는 CORS 헤더를 사용하여 어떤 출처의 웹 페이지가 자신의 리소스에 접근할 수 있는지를 지정할 수 있다.

 

REST API란?

REST API는 웹 서비스의 한 형태로, 리소스에 대한 CRUD (생성, 읽기, 업데이트, 삭제) 연산을 수행하기 위한 표준 규약과 원칙을 따르는 API이다. REST는 "Representational State Transfer"의 약자로, 웹 아키텍처의 한 형태를 나타낸다.

 

REST API의 주요 특징 및 원칙

1. Stateless (무상태성): 각 요청은 모든 정보를 포함해야 한다. 서버는 클라이언트의 상태를 저장하거나 기억하지 않는다. 이는 서버와 클라이언트 간의 상호작용을 독립적으로 유지하며, 확장성을 향상시킨다.

2. Client-Server (클라이언트-서버 구조): 클라이언트와 서버는 독립적으로 작동하며, 각각의 역할이 분리되어 있다. 클라이언트는 사용자 인터페이스와 사용자 경험을 담당하고, 서버는 데이터 저장, 검색 및 관리를 담당한다.

3. Cacheable (캐시 가능): 응답은 캐시 될 수 있어야 한다. 적절한 캐싱을 통해 성능을 향상할 수 있다.

4. Layered System (계층화된 시스템): 클라이언트는 종단 시스템에 직접 연결되어 있는지, 중간 계층을 거치는지 알 필요가 없다. 이를 통해 아키텍처의 확장성과 유연성이 향상된다.

5. Uniform Interface (일관된 인터페이스): REST API는 일관된 인터페이스를 제공해야 한다. 이 원칙은 REST 아키텍처의 핵심이며, 다음과 같은 하위 원칙으로 구성된다

5-1. Resource-Based: 리소스는 URI (Uniform Resource Identifier)로 식별된다.

5-2. Stateless Interactions: 각 요청은 모든 필요한 정보를 포함해야 한다.

5-3. Representation: 클라이언트는 리소스의 상태를 JSON, XML 등의 형식으로 교환한다.

5-4. Self-descriptive Messages: 각 메시지는 자체 설명적이어야 한다.

6. Code on Demand (Optional): 서버는 실행 가능한 코드를 클라이언트에 전송하여 기능을 확장할 수 있다. 이 원칙은 선택적이다.

 

REST API는 HTTP 메서드 (GET, POST, PUT, DELETE 등)를 사용하여 리소스에 접근하고, 이를 통해 웹 서비스와 상호작용한다. 이러한 원칙과 규약을 따르는 API를 구현함으로써, 개발자는 표준화된 방식으로 웹 서비스를 제공하고 사용할 수 있다.

 

XXS 공격이란?

XXS (Cross-Site Scripting) 공격은 웹 애플리케이션의 보안 취약점을 이용하여 악의적인 스크립트를 웹 페이지에 삽입하는 공격 방법이다. 이 공격은 사용자의 브라우저에서 실행되며, 공격자는 이를 통해 사용자의 세션 토큰을 탈취하거나, 사용자 인터페이스를 조작하거나, 악의적인 행동을 유도할 수 있다.

 

XXS 공격 유형

1. Stored XXS (저장형 XXS): 악의적인 스크립트가 웹 애플리케이션의 데이터베이스에 저장되어, 다른 사용자가 해당 페이지를 방문할 때마다 스크립트가 실행된다.

2. Reflected XXS (반사형 XXS): 악의적인 스크립트가 URL의 일부로 전달되며, 해당 URL을 클릭한 사용자의 브라우저에서 즉시 실행된다.

3. DOM-based XXS (DOM 기반 XXS): 웹 페이지의 DOM을 조작하여 악의적인 스크립트가 실행되는 방식이다.

 

XXS 공격을 예방하는 방법

1. 입력 검증: 사용자로부터의 모든 입력을 검증하고, 예상되는 데이터 형식에 맞지 않는 입력을 거부한다.

2. 출력 인코딩: 사용자로부터 받은 데이터를 웹 페이지에 출력할 때, 특수 문자를 안전한 형태로 인코딩한다. 예를 들어, <와 > 문자를 &lt;와 &gt;로 변환한다.

3. 콘텐츠 보안 정책 (CSP): CSP 헤더를 사용하여 웹 페이지에서 실행할 수 있는 스크립트의 출처를 제한한다.

4. HTTP-only 쿠키: HttpOnly 플래그를 사용하여 쿠키가 JavaScript에서 접근할 수 없도록 한다. 이렇게 하면, XXS 공격을 통해 세션 쿠키를 탈취하는 것을 방지할 수 있다.

5. 웹 애플리케이션 방화벽 (WAF): WAF를 사용하여 악의적인 요청을 감지하고 차단한다.

6. 정기적인 코드 리뷰 및 보안 테스트: 코드의 보안 취약점을 찾아내고 수정하기 위해 정기적으로 코드 리뷰와 보안 테스트를 수행한다.

이러한 방법들을 통합적으로 적용하여 웹 애플리케이션의 보안을 강화하면 XXS 공격의 위험을 크게 줄일 수 있다.

 

SQL Injection란?

SQL Injection (SQL 삽입)은 웹 애플리케이션의 보안 취약점을 이용하여 악의적인 SQL 코드를 데이터베이스에 삽입하는 공격 방법이다. 이 공격을 통해 공격자는 데이터베이스의 데이터를 조회, 수정, 삭제하거나, 인증을 우회하거나, 기타 악의적인 행동을 수행할 수 있다.

예를 들어, 로그인 폼에서 사용자 이름과 비밀번호를 입력받는 웹 애플리케이션에서 SQL Injection 공격이 가능할 경우, 공격자는 특정 입력을 통해 원래의 SQL 쿼리를 변조하여 인증을 우회할 수 있다.

 

SQL Injection을 예방하는 방법

1. 파라미터화된 쿼리 사용: SQL 쿼리를 작성할 때, 사용자 입력을 직접 쿼리 문자열에 포함시키지 않고, 파라미터화된 쿼리나 바인딩된 변수를 사용한다. 이 방법은 대부분의 프로그래밍 언어와 데이터베이스 시스템에서 지원된다.

2. ORM (Object-Relational Mapping) 사용: ORM은 데이터베이스와 애플리케이션 코드 간의 중간 계층을 제공하여 SQL 쿼리를 직접 작성할 필요가 없게 한다. 이로 인해 SQL Injection의 위험이 줄어든다.

3. 입력 검증: 사용자로부터의 모든 입력을 검증하고, 예상되는 데이터 형식에 맞지 않는 입력을 거부한다.

4. 에스케이프 처리: 사용자 입력을 SQL 쿼리에 포함시키기 전에 특수 문자를 에스케이프 처리하여 SQL 쿼리의 구조를 변조하는 것을 방지한다.

5. 최소 권한 원칙: 애플리케이션의 데이터베이스 계정은 필요한 최소한의 권한만을 가지도록 설정한다. 예를 들어, 특정 데이터만 읽어야 하는 기능에 대해서는 데이터베이스의 쓰기 권한을 부여하지 않는다.

6. 에러 메시지 숨기기: 데이터베이스 에러 메시지를 사용자에게 직접 노출하지 않는다. 이러한 메시지는 공격자에게 데이터베이스의 구조나 취약점에 대한 힌트를 제공할 수 있다.

7. 웹 애플리케이션 방화벽 (WAF) 사용: WAF를 사용하여 악의적인 요청을 감지하고 차단한다.

이러한 방법들을 통합적으로 적용하여 웹 애플리케이션의 보안을 강화하면 SQL Injection 공격의 위험을 크게 줄일 수 있다.