웹 기초 지식

Lee·2022년 9월 14일

dreamhack의 Cookie와 Session관련 워게임을 풀기 위해 웹에 대한 기초적인 지식을 정리함.

아래의 그림은 dreamhack 웹 사이트에 접속 시 나타는 과정들을 표현한 그림입니다. (출처:dreamhack)

이 장에서는 사용자(웹 브라우저)와 웹 서버가 데이터를 주고받는 과정의 원리와 기술을 단계별로 알아보고자 합니다.

Web Browser

문서 편집은 워드 프로세서 소프트웨어, 데이터 분석, 경리 및 회계 등의 계산은 스프레드시트 소프트웨어를 사용합니다. 마찬가지로 웹을 사용하기 위해 웹 브라우저를 사용합니다. 웹 브라우저는 HTTP를 통해 인터넷 상에서 통신을 하며 서버로부터 전달받은 다양한 웹 리소스들을 가공해 사용자가 웹과 HTTP의 동작 원리를 알지 못해도 웹을 사용할 수 있도록 도와주는 소프트웨어입니다.

대중적인 웹 브라우저는 Chrome, Edge, Safari, Firefox 등이 있습니다. 각 브라우저들이 수행하는 기본적인 기능은 동일하지만 HTML/CSS/JS 해석 및 실행을 빠르게 하거나 내장 로그인을 통해 브라우저를 사용하는 모든 디바이스 동기화 기능 등이 차별화되어 선택하여 사용할 수 있습니다. 각 브라우저별 특징은 아래와 같습니다.

HTTP의 원리와 동작 방식을 몰라도 웹 브라우저를 통해 웹을 불편함 없이 이용할 수 있습니다. 다만 모든 취약점은 사용자의 입력 값에서부터 발생합니다. 사용자의 입력 값은 웹 브라우저를 통해 전송되기 때문에 웹 해킹을 공부하기 위해서는 브라우저가 하는 행위를 필수적으로 이해하고 있어야 합니다.

다음은 웹 브라우저로 http://example.com/index.html 에 접속할 때 이루어지는 통신을 간단하게 보여주는 그림입니다.

네트워크 프로그램

nc또는 telnet과 같은 네트워크 프로그램을 통해 웹을 사용하기 위해서는 웹 서버가 이해하고 해석할 수 있는 형태(HTTP)의 데이터를 직접 작성하여 전송하여야 합니다.

CLI 프로그램

curl, wget과 같은 CLI 프로그램을 통해 웹을 사용하게 되면 서버가 응답하여 주는 데이터를 단순히 출력만 하게 됩니다. 즉 html을 해석하여 화면에 출력하는 기능, css로 스타일을 입혀주는 기능, 자바스크립트를 실행하는 기능 등은 포함되어 있지 않습니다.

웹 브라우저

먼저 웹 브라우저에서 웹을 사용하기 위해서는 주소창에 접속하고자 하는 주소를 입력합니다. 웹 브라우저는 사용자가 요청한 주소를 대신 접속해 서버에서 응답한 데이터를 해석한 후 화면에 출력합니다.

Web Resource

웹 리소스는 웹에서 사용하는 콘텐츠를 의미합니다. 웹 브라우저의 주소창에 http://dreamhack.io/index.html 주소를 입력하게 되면 dreamhack.io에 존재하는 /index.html 리소스에 대해 요청을 수행하는 것을 의미합니다.

웹 리소스를 가리키는 주소는 URL(Uniform Resource Locator)이라고 합니다. 초기 웹에서는 경로가 실제 서버 내에 존재하는 파일의 실제 위치와 동일한 경우가 많았으나 최근 들어 웹 브라우저의 본래 목적인 추상화된 경로를 사용하고 있습니다.

사용자가 웹 브라우저를 통해 보게 되는 페이지를 구성하는 대표적인 웹 리소스들은 아래와 같습니다.

HTML (Hyper Text Markup Language)
웹 문서의 뼈대를 구축하기 위한 마크업 언어입니다.
정해진 태그와 속성을 지정하여 문서를 구성합니다.
CSS (Cascading Style Sheets)
HTML이 표시되는 방법을 정의하는 스타일 시트 언어입니다.
이미지, 태그, 글자 등 다양한 웹 리소스들의 출력 시 스타일을 설정합니다.
JS (JavaScript)
HTML과 CSS는 화면에 출력되는 뼈대를 그리는 것이며, JS와 같은 Client Side Script를 이용하여 페이지 내에서의 행위들을 설정할 수 있습니다.
Etc
문서, 이미지, 동영상, 폰트 등

아래 탭에서는 HTML, CSS, JS를 이용하여 간단한 웹 페이지를 구성한 화면과 코드의 예시입니다. 사용자의 요청이 들어오면 서버는 아래 코드와 같은 웹 리소스들로 응답하며, 웹 브라우저는 사용자가 볼 수 있는 형태로 가공하여 화면에 출력합니다.

index.html

theme.css

main.js

HTML Editor

아래 탭에 존재하는 코드 창에 HTML/CSS/JS 코드를 삽입하면 브라우저에서 해석한 화면을 확인해 볼 수 있습니다.

URI (URL)

URI는 Uniform Resource Identifier의 약자로 리소스를 식별하기 위한 식별자입니다.
우리에게 좀 더 친숙한 용어인 URL은 Uniform Resource Locator의 약자로 리소스의 위치를 식별하기 위한 URI의 하위 개념입니다.

웹에 접속할 때 웹 사이트의 주소(위치)를 이용해 접근하는 것은 URL이자 URI를 사용한 것입니다.
최근 들어 URI와 URL을 혼용해서 사용하는 추세이기 때문에 드림핵에서는 상위 개념인 URI로 통합하여 설명합니다.

URI는 Scheme, Authority (Userinfo, Host, Port), Path, Query, Fragment의 구성 요소를 가집니다.
각 요소에 대한 상세한 설명은 해당 요소를 이용한 공격 기법을 다룰 때 설명하고, 지금은 웹에 접속할 때 사용되는 가장 기본적인 요소만 다루겠습니다.

아래 그림은 URI를 구성 요소 별로 나눈 그림입니다.

아래는 자주 쓰이는 웹 URI 구성 요소를 설명합니다.

Scheme
웹 서버에 접속할 때 어떤 체계(프로토콜)를 이용할지에 대한 정보를 담고 있습니다.
Host
Authority의 일부로써 접속할 웹 서버의 호스트(서버 주소)에 대한 정보를 가지고 있습니다.
Port
Authority의 일부로써 접속할 웹 서버의 포트에 대한 정보를 가지고 있습니다.
Path
접속할 웹 서버의 경로에 대한 정보를 가지고 있으며 / 문자로 구분됩니다.
Query
웹 서버에 전달하는 파라미터 (추가적인 정보)이며 URI에서 ? 문자 뒤에 붙습니다.
Fragment
메인 리소스 내에 존재하는 서브 리소스에 접근할 때 이를 식별하기 위한 정보를 담고 있으며 URI에서 # 문자 뒤에 붙습니다.

아래 탭에서 원하는 URI를 입력하면 해당 URI의 구조를 볼 수 있습니다.

또한 추가적인 URI의 정보는 공식 스펙(RFC)인 RFC 3986에서 확인할 수 있습니다.

Encoding

Encoding(인코딩)은 문자 또는 기호 등의 정보, 형태를 표준화, 보안 등의 목적으로 다른 형태나 형식으로 변환하는 처리 혹은 그 처리 방식을 말합니다. 이렇게 변환된 형태를 원래 형태로 변경하는 것을 Decoding(디코딩)이라고 합니다.

Encoding (인코딩) : 알고리즘이 모두 공개되어 있고 키와 같은 요소가 포함되어 있지 않아서 모두가 원래의 정보로 복원이 가능합니다.
Encryption (인크립션) : 양방향 암호 알고리즘입니다. 일치한 알고리즘과 유효한 키를 가지고 있다면 원래의 정보로 복원이 가능합니다.

웹에서 사용하는 대표적인 인코딩은 URL과 HTML Entity가 있습니다.

URL Encoding(percent encoding)

URI 구조내에서 예약어(구분자)로 사용되는 문자들을 전송하고자 할 때 사용합니다. 예약어는 URI 구조내에서 문법적으로 중요한 의미를 가지고 있기 때문에 문법적으로 사용하지 않을 경우에는 반드시 인코딩해 사용해야 합니다.

GET 메소드로 a=?b,c=&d의 데이터를 보내기 위해서는 http://example.com/?a=%3Fb&c=%26d의 형태로 전송되어야 서버에서도 정상적으로 데이터를 해석하여 처리할 수 있습니다.

HTTP

웹 브라우저를 사용할 때 주소창에서 HTTP 또는 HTTPS 라는 글자를 볼 수 있습니다. 예를 들어 웹 브라우저로 드림핵 홈페이지에 접속하면 주소창에 https://dreamhack.io가 입력되어 있는 것을 볼 수 있습니다.

HTTP 또는 HTTPS는 URI의 구성 요소 중 Scheme (Protocol)에 해당합니다. Protocol(프로토콜)은 컴퓨터 내부 혹은 컴퓨터 사이에서 어떻게 데이터를 교환할지를 정의하는 규칙 체계입니다. 즉, https://dreamhack.ioURI는 HTTPS 방식으로 dreamhack.io 서버와 통신한다는 것을 의미합니다.

HyperText Transfer Protocol(HTTP), HyperText Transfer Protocol Secure Socket Layer(HTTPS)은 웹에서 이루어지는 통신을 정의한 프로토콜입니다. TCP 혹은 TLS(암호화된 TCP)를 사용해 통신하고 기본 포트로 80(HTTP), 443(HTTPS) 포트를 사용합니다.

포트 번호는 서버의 설정을 통해 변경 가능합니다. 무조건 서버의 포트 번호가 80, 443으로 서비스되는 것은 아닙니다. 예를 들어, 웹 서버 중 많이 사용되고 있는 톰캣 서버의 기본 포트 번호는 8080입니다.

HTTPS는 HTTP의 문제점인 데이터의 평문 전송을 보완하기 위해 등장하였습니다. 하지만 HTTP와 HTTPS의 핵심 구조 및 동작 원리는 동일하기 때문에 HTTP로 통칭하기도 합니다.

HTTP는 사용자가 서버에 요청을 하는 Request와 사용자의 요청에 대한 서버의 응답인 Response로 나뉘어집니다.

오른쪽 탭에서는 HTTP의 Request와 Response의 간단한 데이터 구조입니다. 커서를 데이터 위에 올려보면 각각 어떤 속성인지 확인할 수 있습니다.

HTTP Request

HTTP Request는 서버에 대한 요청을 의미합니다. 사용자와 서버가 서로 통신을 하기 위해서는 서로가 이해할 수 있는 데이터 구조를 전달해야 합니다.

HTTP의 구조에서 각각의 줄은 CRLF로 줄 바꿈이 이루어져야 합니다.
HTTP Request의 구조 중 가장 첫번째 줄에는 사용자가 서버에 요청 시 수행하고자 하는 동작인 Method, 요청하는 웹 리소스의 경로인 Path, 사용하는 HTTP의 버전을 나타내는 Version으로 구성됩니다.

두 번째 줄부터는 Header 부분입니다. Header는 이름: 값 형태로 이루어집니다. Header는 상황에 따라 많은 데이터를 포함할 수 있기 때문에 Header 부분의 끝을 표시하기 위한 CRLF을 한 번 더 출력합니다.
마지막으로 사용자의 데이터를 담는 부분인 Body가 있습니다.

GET

POST

Request 구성요소

Method
서버에 요청 시 수행하고자 하는 동작을 나타냅니다.
Path
사용자가 서버에 요청하는 웹 리소스의 경로입니다.
Version
HTTP의 버전을 나타냅니다.
Header
서버에 추가 정보를 전달하는 데이터 부분입니다. 사용자가 입력한 데이터를 전달하기 위한 부분보다는 사용자와 서버가 상호작용하기 위한 정보를 담는 부분으로 사용됩니다.
e.g. 사용자 데이터의 처리 방식 및 형식에 대한 정보, 서버에서 사용자를 식별하기 위한 쿠키 정보 등
Body
사용자가 입력한 데이터가 서버에 전달 시 데이터를 담는 부분입니다.

Method

메소드들은 각각의 목적을 두고 설계되었지만, 서버에서 설정하는 방식이나 웹 어플리케이션의 처리에 따라 수행하는 방식이 다르게 사용될 수 있습니다.
OPTIONS

요청하는 리소스가 허용하는 메소드 목록을 반환합니다. 예를 들어 /login페이지가 OPTIONS, GET, POST 메소드만 허용하는 경우 OPTIONS, GET, POST가 반환됩니다.

HEAD
GET 메소드와 동일하지만, Response의 Body 부분은 받지 않고, Header만 받습니다. (e.g. 서버의 상태 확인 등)
GET
리소스를 요청합니다. (e.g. 게시물/프로필 보기, 이미지 등)
POST
특정 리소스 생성 및 데이터 추가를 위해 값을 제출할 때 사용합니다. (e.g. 게시물/프로필 생성 등)
PUT
특정 리소스의 내용을 보낸 값으로 설정합니다. (e.g. 생성/업데이트 등)
PATCH
특정 리소스의 내용 중 보낸 값의 key만 변경합니다. (e.g. 게시글 업데이트 등)
DELETE
특정 리소스를 삭제합니다. (e.g. 게시물 삭제 등)
TRACE
요청받은 값을 Response의 Body로 다시 클라이언트에게 되돌려줍니다.

Header

Host
데이터를 보내는 서버의 주소를 의미합니다.
Cookie
사용자를 식별하기 위해 사용하는 정보입니다.
User-Agent
사용자가 사용하는 프로그램의 정보를 나타냅니다.
Referer
페이지 이동 시 이전 URI의 정보를 나타냅니다.
Content-Type
사용자가 전달하는 데이터의 처리 방식과 형식을 나타냅니다. 사용자와 서버 간의 데이터 처리 방식이 일치되어야 정상적으로 데이터 통신이 이루어집니다.

위에서 설명한 헤더 외에도 HTTP에서 사용되고 있는 헤더들은 다양합니다. 자세한 내용은 MDN docs에서 확인할 수 있습니다.

HTTP Response

HTTP Response는 사용자의 요청에 대한 서버의 응답을 의미합니다. Response의 구조도 Request의 구조와 마찬가지로 각 줄은 CRLF로 줄 바꿈이 이루어져야 합니다.

HTTP Response의 구조 중 가장 첫번째 줄에는 Version과 사용자의 요청에 대한 서버의 상태 응답 코드인 Status code로 구성됩니다. 두 번째 줄부터는 Header 부분입니다. Header 부분의 각 줄은 이름: 값의 형태로 이루어집니다. Header의 끝을 표시하기 위해 CRLF를 한 번 더 출력한 후, 서버의 응답 데이터 부분인 Body로 구성됩니다.

웹 해킹에서는 사용자의 입력에 의한 서버의 응답을 주목해야 합니다. 예를 들어 악의적인 입력을 보냈을 때 500 Status code(Internal Server Error)를 응답하면 해당 입력이 서버에 어떠한 영향을 끼쳤다고 짐작할 수 있고 취약점으로 도출해낼 수도 있습니다.

200 OK

404 Not Found

500 Internal Server Error

Response 구성요소

Version
HTTP의 버전을 나타냅니다.
Status code
사용자의 요청에 대한 서버의 처리 결과를 나타냅니다.
Header
사용자와 상호작용하기 위한 데이터를 담는 부분으로 사용됩니다.
e.g. 사용자(웹 브라우저)에서 서버의 응답 데이터를 처리하는 방식 및 형식에 대한 정보, 서버에서 사용자를 식별하기 위한 쿠키 발급 정보 등
Body
서버가 사용자에게 응답하는 데이터를 담는 부분입니다.

Status code

Status code 중 주로 사용되는 code들에 설명입니다. 다른 code들에 대한 내용은 mozilla docs에서 확인할 수 있습니다.

200번 영역
사용자의 요청에 대한 서버의 처리가 성공하였음을 나타냅니다.
-200 OK
-201 Created
300번 영역
사용자가 요청한 리소스가 다른 경로로 변경된 경우를 나타내는 영역입니다. 웹 브라우저에서 300번 영역의 응답 상태 코드가 반환되면, Response Header에 포함되어 있는 Location 헤더의 값으로 리다이렉션 합니다.
-301 Moved Permanently
-302 Found
400번 영역
사용자가 서버에 요청하는 구조 또는 데이터가 잘못되었음을 나타내는 영역입니다.
-400 Bad Request
사용자가 전달한 데이터 또는 구조의 잘못된 문법으로 인하여 서버가 요청을 이해할 수 없음을 의미합니다.
-403 Forbidden
사용자가 해당 웹 리소스에 접근할 권리를 가지고 있지 않음을 나타냅니다.
-404 Not Found
사용자가 요청한 웹 리소스의 경로에 대해 응답할 데이터가 없음을 나타냅니다.
-405 Method Not Allowed
사용자가 요청한 Method가 서버에서는 허용하지 않는 Method임을 나타냅니다.
500번 영역
서버의 에러와 관련된 영역입니다.
-500 Internal Server Error
서버의 에러가 발생하였음을 나타냅니다.
-503 Service Unavailable
서버가 사용자의 요청을 처리할 준비가 되지 않았음을 나타냅니다.

Header

Content-Type
서버의 응답 데이터를 웹 브라우저에서 처리할 방식과 형식을 나타냅니다.
Content-Length
서버가 사용자에게 응답해주는 데이터의 길이를 나타냅니다.
Server
서버가 사용하는 소프트웨어의 정보를 나타냅니다.
Allow
허용되는 Method 목록을 사용자에게 알려줄 때 사용합니다.
Location
300번 영역의 응답 코드 사용 시 변경된 웹 리소스의 주소를 나타냅니다.
Set-Cookie
사용자에게 쿠키를 발급할 때 사용합니다. 해당 헤더를 받은 웹 브라우저는 해당 쿠키를 저장합니다.

HTTP Request & Response

이 페이지에서는 HTTP Request와 Response의 실제 데이터를 각 Method 별로 확인해 볼 수 있습니다.
아래 탭에서 원하는 Method를 선택하여 전송(Send)하면 오른쪽 탭에서 HTTP 요청 및 응답 데이터의 구조를 확인해 볼 수 있습니다.

HTTP는 하나의 Request와 Response의 쌍이 독립적으로 구성되어 통신하는 connectionless, stateless 프로토콜입니다.

connectionless 속성은 하나의 요청에 하나의 응답을 한 후 네트워크 연결을 끝맺는 것을 의미합니다. 불특정 다수의 사용자에게 서비스되어야 하는 웹의 특성상 계속해서 연결상태를 유지하는 것은 서버 부하로 이어질 가능성이 있어 connectionless를 갖게 되었습니다.

과거에는 네트워크, 서버 등의 부하로 인해 connectionless 속성이 강조되었지만, 최근에는 네트워크, 서버 등의 성능 향상으로 HTTP/1.1 부터 Keep-Alive 를 통해 일정 시간 동안 사용자와 서버가 계속 연결을 맺고 있는 방식을 사용합니다.

stateless 속성은 네트워크가 연결이 끝맺을 때 상태를 유지하지 않는 것을 의미합니다. HTTP 요청마다 새로운 커넥션을 열기 때문에 사용자 인증을 계속해서 해야 한다는 단점이 있습니다. 이러한 단점을 개선하기 위해 상태를 유지하기 위한 Cookie(쿠키)가 탄생했습니다.

웹 브라우저는 HTTP Response의 Set-Cookie Header나 Javascript document.cookie를 통해 데이터를 쿠키에 저장합니다.

HTTP Response

Javascript

데이터를 key=value; 쌍으로 쿠키에 저장하고 ;뒤에 쿠키의 만료시간, 접근할 수 있는 도메인 등 추가 옵션을 설정할 수 있습니다.

추후 HTTP 요청을 보낼 때 웹 브라우저가 자동으로 헤더에 쿠키를 추가해 전송합니다.

쿠키는 인증 상태를 포함할 수 있습니다. 오른쪽 탭의 value 에 guest를 넣어 전송하면 브라우저는 Cookie: id=guest;를 서버에 보내고 서버는 해당 정보를 통해 인증된 사용자의 정보를 응답합니다. value 값을 변경하면서 어떠한 응답 값을 반환하는지 확인합니다.

쿠키는 사용자의 브라우저에 저장됩니다. 인증 상태를 쿠키에 저장하게 되면 아래와 같은 상황이 발생하게 됩니다.

Session

쿠키에 인증 상태를 포함한 데이터를 저장하면 사용자가 임의 사용자로 인증된 것 처럼 요청을 조작할 수 있습니다. 따라서 서버에 데이터를 저장하기 위해 Session(세션)을 사용합니다. 세션을 활용하면 데이터를 서버에 저장하고 해당 데이터에 접근할 수 있는 유추할 수 없는 랜덤한 문자열 키를 만들어 응답하며, 이를 보통 Session ID라고 부릅니다. 브라우저는 해당 키를 쿠키에 저장하고 이후에 HTTP 요청을 보내면 서버에서 키에 해당하는 데이터를 가져와 인증 상태를 확인합니다.

쿠키는 데이터 자체를 사용자가 저장하며, 세션은 서버가 저장한다는 핵심적인 차이가 있습니다. 오른쪽 탭에 있는 모듈을 활용해 서버의 세션 저장소에 admin 인증 정보를 담고 있는 키를 갖고와 value 에 넣어봅니다.

웹 브라우저에는 localStorage라는 저장공간도 존재하는데 Session ID가 쿠키에 국한되지 않고 localStorage 등 다양한 곳에 저장되어 사용될 수 있습니다.

HTTP / HTTPS

웹은 업무, 은행, 쇼핑 등 다양한 분야에서 사용되고 있고 웹 서비스와 통신하는 요청과 응답에 개인 정보(이름, 전화번호, 주소, 카드번호) 및 기업의 자산 등 민감한 정보들이 포함될 수 있습니다.

HTTP는 모든 데이터를 암호화 되지 않은 평문으로 전송합니다. 네트워크에서 전송된 데이터를 감청할 수 있다면 HTTP로 통신하는 데이터는 평문으로 노출되고 웹에서 민감한 정보를 다룰 때 문제가 될 수 있습니다.

HTTPS는 Transport Layer Security(TLS), Secure Sockets Layer(SSL)를 사용해서 암호화합니다. 공개키 암호화를 사용해서 클라이언트와 서버가 키를 교환하기 때문에 비교적 안전합니다.

오른쪽 탭에서는 Wireshark를 통해 사용자의 컴퓨터에서 전송되고 서버에서 그에 해당하는 응답 값을 전달하는 과정을 네트워크 단계에서 확인한 결과입니다. 빨간 글자는 요청 값에 해당하며, 파란 글자는 응답 값에 해당합니다. 두 그림의 차이를 통해 실제 네트워크에서 HTTP와 HTTPS의 차이를 알 수 있습니다.

HTTP
HTTP는 네트워크상에서 평문으로 통신을 하며 상위 네트워크 장비, 같은 네트워크 상의 MITM 공격 등에 의해 통신이 노출될 경우 평문 정보를 그대로 출력되기 때문에 민감한 정보가 노출되며 심각한 위험을 초래하게 됩니다.

HTTPS
HTTPS는 네트워크상에서 데이터들이 암호화되어 전달되기 때문에 일반적으로 어떤 내용의 통신을 하는지 알 수 없게 됩니다.

Domain Name / Host Name

URI 구성 요소 중 Host는 웹 브라우저가 어디에 연결할지 정하게 됩니다. Domain Name이나 Internet Protocol(IP) Address가 Host에 사용됩니다.
e.g. http://example.com/path1?search=1#fragment => Host: example.com

IP Adress는 네트워크상에서 통신이 이루어질 때 장치를 식별하기 위해 사용되는 주소입니다. 불규칙한 숫자로 이루어진 IP Address를 사람이 외우기 쉽고, 의미를 부여하기 위해 Domain Name을 사용합니다.

Domain Name을 이용해 Host를 조회할 때는 Domain Name과 IP Adress 정보를 매핑해 저장하는 Domain Name Server(DNS)에서 조회해 등록된 IP Address를 가져와 사용합니다. 웹 브라우저에서 http://example.com/ 주소로 접속할 경우 DNS에서 example.com(Domain Name)의 IP와 통신합니다.

nslookup 명령어를 사용해 Domain Name의 정보를 확인할 수 있습니다.

웹 서버 어플리케이션 - 1

Web Server

웹 서버는 사용자의 HTTP 요청을 해석하여 처리한 후 응답하여 주는 역할을 합니다.

대표적으로 nginx, Apache, Tomcat, IIS 등이 있습니다.

웹 서버는 사용자로부터 받는 요청을 웹 서버 자체적으로 처리할지, 들어온 요청에 알맞은 내부 서비스로 연결할지를 정할 수 있습니다. 예를 들어 클라이언트가 접근한 URI가 .html 확장자를 가진 리소스라면 웹 서버에서 해당 경로의 html을 반환해주고, .php 확장자를 가진 리소스라면 php 엔진을 통해 해당 요청을 처리합니다. 또한 /payment/ 경로로 시작하는 요청에 대해서는 payment를 처리하기 위한 어플리케이션에 요청을 연결해주는 역할을 수행하는 것이 가능합니다.

Web Application

웹 어플리케이션은 사용자의 요청을 동적으로 처리할 수 있도록 만들어진 어플리케이션입니다.

웹 어플리케이션을 작성할 때는 사용자가 요청한 내용을 동적으로 처리하기 위해 Web Application Language가 사용되며 대표적으로 PHP, NodeJS, Python, Java 등이 존재합니다.

이 외에도 굉장히 많은 언어가 존재하며 Python의 django와 flask, Java의 spring처럼 웹 개발을 편하게 해주는 프레임워크도 많이 존재합니다.

또한 웹 어플리케이션은 서버에서 동작하기 때문에 웹 어플리케이션 구현체에서 취약점이 발생하게 되면 서버에 직접적인 영향을 끼치게 됩니다.

웹 서버 어플리케이션 - 2

DataBase Management System

DataBase Management System (DBMS)은 데이터베이스 내의 데이터 조회/수정/삽입을 용이하게 할 수 있도록 도와주는 서버 어플리케이션입니다. MySQL, MS-SQL 등을 DBMS라 하며 해당 어플리케이션들이 관리하는 데이터를 데이터베이스라고 합니다. 데이터베이스에는 사용자의 인증, 상품, 문서 등 중요한 개인 정보가 포함된 여러 가지 내용이 존재하기 때문에 보안에 각별히 신경써야 합니다.

프로그래머는 데이터베이스 내용을 조회/수정/삽입하기 위해 DBMS를 사용합니다. DBMS는 SQL Query를 통해 제어하는데, 이때 사용자의 입력 값을 SQL Query에 필터링 없이 사용하게 되면 SQL Injection 공격에 노출되게 됩니다. 이에 관한 자세한 내용은 나중에 다루겠습니다.