힙한 주니어를 위한 프론트엔드 보안힙한 주니어를 위한 프론트엔드 보안
힙한 주니어를 위한 프론트엔드 보안/
1. 웹의 기본 구조

1. 웹의 기본 구조

(1) 클라이언트-서버 모델

우리는 인터넷 네트워크를 통해 다양한 디지털 정보를 공유하고 있다. 웹은 인터넷 상에서 작동하는 정보 검색 시스템이다. 정보 검색은 정보를 요청하고 요청에 응답하는 형태로 이루어지는데, 이 때의 요청자를 클라이언트(client, 손님), 응답자를 서버(server, 제공자)라고 하며, 이와 같은 요청-응답 동작 모델을 클라이언트-서버 모델이라고 부른다.
[그림 2-1] 웹 애플리케이션의 클라이언트-서버 모델[그림 2-1] 웹 애플리케이션의 클라이언트-서버 모델
[그림 2-1] 웹 애플리케이션의 클라이언트-서버 모델
웹의 대부분의 동작은 서버에서 이루어진다. 서버는 계산을 처리하고, 데이터를 가공하고, 클라이언트의 요청을 처리하는 등 서비스를 직접 수행하는 컴퓨터 또는 프로그램이다. 클라이언트는 서버에 접근해 데이터를 제공 받고 사용자에게 보여주는 역할의 컴퓨터 또는 프로그램을 말한다.
대표적인 클라이언트인 웹 브라우저를 떠올려보자. 사용자가 주소창에 사이트 주소를 입력하면 브라우저는 웹 서버로 요청을 보내 HTML, CSS, JavaScript, 이미지 같은 리소스를 응답 받는다. 브라우저가 리소스를 해석하고 화면에 그리는 렌더링 작업 후, 사용자는 웹 페이지와 수많은 상호작용을 시도한다. 그로 인해 추가 컨텐츠 요청이 발생하면 브라우저는 다시 웹 서버로 요청을 보내고, 웹 서버는 애플리케이션 서버로 비동기 요청을 보낸다. 애플리케이션 서버는 비즈니스 로직에 맞게 요청을 처리하고, 필요한 경우 데이터베이스 서버에 CRUD¹⁾ 작업을 요청한다. 이처럼 대부분의 웹 애플리케이션은 클라이언트와 여러 서버의 요청-응답 구조로 동작한다. 이 때의 웹 서버를 프론트엔드 서버, 애플리케이션 서버를 백엔드 서버로 이해해도 좋다.
¹⁾ CRUD(Create/Read/Update/Delete): 데이터 저장소의 핵심 기능인 데이터 생성/조회/수정/삭제 기능을 통칭
 

(2) URL과 도메인 네임

1) URL

우리가 도로명 주소로 각 건물을 식별하듯 웹 리소스의 위치 식별자로는 URL(Uniform Resource Locator, 웹 주소)을 사용한다. 내비게이션에 목적지 주소를 입력하면 해당 주소지를 찾아갈 수 있는 것처럼, 웹 리소스에 접근할 때는 리소스를 제공하는 서버의 주소로 요청을 보내야 한다. URL은 서버를 식별하는 IP 주소와 서버 내 리소스의 경로로 구성되어 있다. 브라우저의 주소창에 URL을 입력하면 브라우저 엔진은 이를 해석하여 해당 IP 주소의 서버에 접속하고 특정 리소스를 요청하게 된다.
URL의 구조: scheme://host[:port][/path][?query]
URL의 구조: scheme://host[:port][/path][?query]
  • scheme: 연결에 사용할 스키마, 즉 HTTP, HTTPS 같은 통신 프로토콜을 지정
  • host: 요청을 보낼 호스트 서버, IP 주소나 도메인 네임으로 표시
  • port: 서버에서 특정 서비스를 위해 열어둔 게이트 번호
  • path: 서비스 내 특정 리소스의 경로
  • query: 리소스에서 조건부 요청에 사용할 추가적인 매개변수

2) 도메인 네임

URL의 host 부분에 주목해보자. 컴퓨터가 서버를 식별하려면 IP 주소가 필요하지만 142.250.207.100 같은 숫자의 나열은 사람이 기억하기 어렵다. 그래서 대체 용도로 IP 주소에 매핑되는 인간 친화적인 문자열을 사용하는데 이를 도메인 네임(domain name)이라고 한다. 우리가 웹 사이트 주소로 기억하는 google.com, map.naver.com 등이 바로 도메인 네임이다.
브라우저 주소창에 도메인 네임을 포함한 URL을 입력하면 브라우저는 DNS(domain name system) 조회를 통해 도메인 네임에 매핑되는 IP 주소를 찾고 URL을 변경하여 요청을 보낸다. 즉, http://www.google.com/search?q=cat과 http://142.250.207.100/search?q=cat는 똑같은 서버로 리소스를 요청한다.
[그림 2-2] http://142.250.207.100/search?q=cat[그림 2-2] http://142.250.207.100/search?q=cat
[그림 2-2] http://142.250.207.100/search?q=cat
 

(3) HTTP

1) 이해

HTTP(HyperText Transfer Protocol, 하이퍼텍스트 전송 규약)는 웹 통신 프로토콜¹⁾이다. 즉 웹에서 클라이언트-서버가 데이터를 주고받을 때 사용하는 통신 방식을 체계화한 것이다. 여기에는 요청-응답의 형식, 에러 상태 표시, 연결 관리, 캐싱, 인증 등 여러 통신 규칙과 절차가 포함된다.
클라이언트가 서버에 HTTP 요청을 보내면, 서버는 클라이언트로 이에 대한 HTTP 응답을 보낸다. 요청과 응답은 HTTP 메시지라는 형식의 텍스트를 주고받는 과정이다. 서버가 응답을 마치면 연결은 끊어지고 지속되지 않는다.(비연결성)²⁾ 또한 각 연결은 독립적이어서 끊어진 연결에 관한 정보는 저장되지 않는다.(무상태성)

2) HTTP 메시지

HTTP 메시지는 클라이언트와 서버가 데이터를 주고받을 때 사용하는 텍스트 메시지 형식을 규약한 것이다. 유형으로 요청(Request)과 응답(Response)이 있는데, 둘의 내용은 다르지만 헤더-빈줄-바디 구조는 같다.
[그림 2-3] 요청과 응답의 헤더-빈줄-바디 구조[그림 2-3] 요청과 응답의 헤더-빈줄-바디 구조
[그림 2-3] 요청과 응답의 헤더-빈줄-바디 구조
헤더는 요청-응답의 메타데이터를 담고 있다. 바디는 요청-응답에서 주고받는 데이터를 나타내며, 데이터가 없다면 생략될 수도 있다. 빈 줄은 헤더와 바디를 구분하는 역할을 한다.

① 헤더(Header)

헤더의 시작 줄에는 주요 정보가 포함된다. 요청 헤더의 시작 줄에는 요청 메서드, URL, HTTP 버전이 표시되며, 응답 헤더의 시작 줄에는 HTTP 버전, 상태 코드, 상태 메시지가 표시된다.
그 이후의 헤더 정보는 줄바꿈으로 구분된다. 공통적으로 포함되는 헤더는 컨텐츠 유형(Content-Type), 컨텐츠 길이(Content-Length) 등이 있다. 그 밖에도 요청 헤더에는 브라우저 정보(User-Agent), 요청 사이트 URL(Host) 등이, 응답 헤더로는 응답하는 서버 소프트웨어(Server) 등이 포함된다.
[그림 2-4] 요청(Request) 메시지[그림 2-4] 요청(Request) 메시지
[그림 2-4] 요청(Request) 메시지
[그림 2-5] 응답(Response) 메시지[그림 2-5] 응답(Response) 메시지
[그림 2-5] 응답(Response) 메시지

② 바디(Body)

바디는 요청-응답 데이터의 본문을 나타낸다. 데이터의 형식은 HTML, JSON, 폼 데이터 등 다양하고 헤더의 Content-Type 필드를 통해 표시된다. 요청 메서드에 따라서는 바디가 생략될 수도 있다.

③ HTTP 메서드(HTTP Method)

HTTP 메서드는 리소스로 수행할 작업을 정의한다. 서버는 메서드에 따라 다른 작업을 수행하고 그에 맞는 응답을 반환한다.
HTTP/1.1 스펙에는 총 8가지의 메서드가 정의되어 있는데, 주로 사용되는 메서드는 GET, POST, PUT, DELETE 4가지이다.
  • GET: 서버에서 리소스를 조회함. 브라우저 주소창을 통한 요청이 GET
  • POST: 서버에 새로운 데이터를 생성함
  • PUT: 서버에 존재하는 리소스를 수정함
  • DELETE: 서버에서 특정 리소스를 삭제함
GET과 DELETE는 클라이언트에서 서버로 전달하는 데이터가 없으므로 바디가 생략될 수 있지만, POST와 PUT은 생성하거나 수정할 데이터를 포함하므로 바디가 필요하다.
그 밖에도 PATCH, HEAD, OPTIONS, TRACE, CONNECT 메서드가 있으며, 이들은 보통 특정 상황에 사용된다.

④ 상태 코드(Status Code)

상태 코드는 서버의 작업 처리 결과를 세자리 숫자 코드로 표현한다. 각 코드에는 지정된 의미가 있으며, 첫번째 자리 숫자에 따라 5개의 클래스로 분류된다.
  • 1xx (정보): 요청이 수신되어 처리 중임
  • 2xx (성공): 요청이 성공적으로 처리됨
  • 3xx (리디렉션): 요청한 리소스가 다른 위치로 이동했음, 추가 조치 필요
  • 4xx (클라이언트 오류): 클라이언트의 요청이 잘못되어 서버가 처리할 수 없음
  • 5xx (서버 오류): 서버에 문제가 있어 요청을 처리하지 못함
상태 코드가 200 OK이면 요청이 정상 처리 되었고, 404 Not Found라면 요청 리소스가 존재하지 않음을 알 수 있다. 클라이언트는 이러한 응답 결과를 기반으로 후속 작업을 수행할 수 있다.

3) HTTP 쿠키와 보안

HTTP는 무상태 프로토콜로 각 요청 간의 상태를 저장하지 않는다. 초기 HTTP는 HTML 문서 제공 기능만을 고려하여 개발되었기 때문에 상태 관리 기능은 필요치 않았다. 하지만 웹의 기능이 다양해지면서 사용자의 로그인 상태나 장바구니 정보 등 상태 정보를 유지할 필요성이 커졌다. 이에 대한 보완책으로 쿠키를 이용한 상태 관리 방법이 등장하게 되었다.
쿠키(HTTP Cookie, Cookie)³⁾는 상태 정보를 저장하는 작은 텍스트 조각이다. 서버가 상태 정보를 쿠키에 담아 클라이언트로 전달하면, 클라이언트는 이것을 브라우저의 쿠키 저장소에 보관하고, 이후 동일한 서버로 요청을 보낼 때 요청 헤더에 자동으로 포함시킨다. 이를 통해 HTTP 통신 과정에서 세션 정보, 사용자 정보 등의 상태 관리가 가능하다. 그러나 주요 정보를 브라우저에 저장하는 쿠키의 특성 때문에 정보가 조작되거나 도난당할 수 있다는 보안 위험이 문제로 남아있었다.
HTTP는 암호화되지 않은 평문 통신이므로, 데이터가 탈취될 경우 그 내용이 바로 노출될 수 있다. HTTPS(HTTP Secure)는 HTTP 통신을 암호화하는 프로토콜로 이런 보안 취약점을 보완한다. HTTPS는 HTTP에 TLS/SSL 암호화 계층을 추가하여 데이터의 기밀성과 무결성을 보장한다. 그 결과 중간에 데이터를 가로채는 스니핑(sniffing)이나 중간자 공격(man-in-the-middle attack)을 방지할 수 있고 쿠키의 사용도 안전할 수 있다. 현재 HTTPS는 개인정보 보호와 데이터 보안을 위해 필수적인 웹 표준으로 자리 잡고 있다. HTTPS에 대한 더 자세한 내용은 6장에서 계속된다.
¹⁾ 프로토콜이란 규칙의 집합이다. 어떤 과정을 시스템화하기 위해 표준을 정해둔 것이며, 통신 프로토콜은 국제 인터넷 표준화 기구(IETF)에서 문서로 작성해 관리하고 있다.
²⁾ 일반적으로 HTTP의 특성에 비연결성, 무상태성을 꼽긴 하지만, HTTP는 많은 기능을 보완하며 발전해왔기 때문에 엄밀히 말해 HTTP의 버전마다 그 특성은 다르다고 할 수 있다. 상용화 버전 HTTP/1.0에서는 각 요청에 별도의 TCP 연결을 생성하므로 비연결적이다. HTTP/1.1에서는 TCP 연결을 재사용하는 지속적 연결(keep-alive)이 가능해졌다. HTTP/3에서는 전송 프로토콜로 TCP 대신 UDP 기반의 QUIC을 사용한다. HTTP/1.1은 현재 대부분의 웹 사이트에서 지원되고 있으며, 상위 버전의 HTTP는 하위 버전과 호환이 가능하기 때문에 이 책에서는 보편적으로 사용하는 1.1 버전을 기준으로 설명한다.
³⁾ 쿠키의 이름은 컴퓨터 과학에서 사용하는 용어 매직 쿠키(magic cookie)에서 유래했다. 매직 쿠키는 프로그램 간에 사용자가 인식하지 못하는 방식으로 전달되는 작은 데이터 조각을 뜻한다.