CSS Tutor Study Hub 메인으로

Computersystemsicherheit 2025/26

15. HTTP request·GET·POST·TLS 완전 초보 강의

비유, 단계별 예시, 자체 흐름도, 강의 스크립트 원본, 시험 답안까지 한 페이지에서 연결합니다.

시험 구조와 출제 신호Crypto / AuthNetwork / DNS / BGP / TLSWeb / Software SecurityPrivacy / Forensics / SecLab

CSS 1타 강사 · CONCEPT 15/25

GET·POST·TLS는 각각 무엇을 바꾸며 왜 POST만으로 비밀번호가 안전하지 않을까요?

GET parameter는 URL에 들어가 history, log, bookmark, Referer 등에 남기 쉽습니다. POST는 body에 값을 넣지만 그 자체로 암호화하지 않습니다. Login secret은 POST와 TLS를 함께 사용해야 전송 중 노출을 줄일 수 있습니다.

전문 용어를 보기 전에 이 장면부터 잡으세요

GET은 엽서 겉면, POST는 봉투 안쪽에 쓰는 것과 비슷하지만, TLS가 없으면 봉투 자체가 투명할 수 있습니다.

POST는 숨김 버튼이 아니라 전송 형식입니다

00

한 장면으로 문제를 시작해 봅시다

이번 페이지에서 끝까지 따라갈 예시

Login form이 username과 password를 GET query string으로 보내는 경우와 POST body over TLS로 보내는 경우를 비교합니다.

비유와 실제 시스템을 정확히 연결하기

  • 엽서 겉면에 적힌 값GET URL query
  • 편지 body 안의 값POST request body
  • 운송 중 편지를 잠그는 봉투TLS

이 예시에서 사람·장치·데이터·화살표를 먼저 찾습니다. 아직 용어를 완벽히 몰라도 “누가 무엇을 가지고, 어떤 처리를 거쳐, 무엇이 달라지는가”를 말할 수 있으면 출발점은 충분합니다.

01

긴 이름을 작은 용어로 분리하기

한 제목에 여러 단어가 들어 있어도 같은 기능을 뜻하지 않습니다. 아래 카드를 하나씩 읽고 각 용어의 대상과 역할을 따로 잡으세요.

Browser, server, HTTP, HTML parser

Browser는 사용자의 client 프로그램이고 web server는 request를 받아 response를 만드는 프로그램이다. HTTP request에는 method, URL, header, body가 있고 response에는 status, header, body가 있다. Browser는 response body를 단순 글자가 아니라 HTML, JavaScript 같은 문법으로 해석(parse)한다. 외부 입력이 처음 들어오는 곳을 source, 그 입력이 실제 기능에 사용되는 위험한 도착점을 sink라고 부른다. 따라서 입력이 어느 문법 위치와 sink에 들어가는지가 보안에 매우 중요하다.

TERMS FROM ZERO

Browser, server, HTTP, HTML parser 핵심 용어

아래 단어는 이미 안다고 가정하지 않습니다. 먼저 쉬운 뜻을 읽고, 본문에서 같은 단어가 나오면 이 정의로 다시 바꾸어 읽으세요.

HTTP request

Browser나 client가 server에 method, path, headers, body를 담아 보내는 message입니다.

HTTP response

Server가 status, headers, body를 담아 client에 돌려주는 message입니다.

Parser / Interpreter

문자열을 HTML, JavaScript, SQL, shell 같은 문법으로 해석하는 구성요소입니다.

Context

같은 문자가 어느 문법의 어느 위치에 놓였는지를 뜻하며 올바른 encoding 방법을 결정합니다.

GET과 POST, 그리고 TLS는 각각 무엇을 바꾸는가

GET request의 parameter는 보통 URL query string에 들어가 browser history, bookmark, 화면, proxy·server access log, Referer에 남을 수 있다. POST는 데이터를 request body에 넣어 URL 노출을 줄이지만 자체적으로 암호화하지는 않는다. 전송 중 내용을 보호하려면 HTTPS/TLS가 함께 필요하다.

TERMS FROM ZERO

GET과 POST, 그리고 TLS는 각각 무엇을 바꾸는가 핵심 용어

아래 단어는 이미 안다고 가정하지 않습니다. 먼저 쉬운 뜻을 읽고, 본문에서 같은 단어가 나오면 이 정의로 다시 바꾸어 읽으세요.

GET

주로 resource 조회에 쓰며 parameter가 URL query에 들어가기 쉬운 HTTP method입니다.

POST

주로 상태 변경이나 form 제출에 쓰며 data를 request body에 담을 수 있는 HTTP method입니다.

URL query

`?name=value` 형태로 URL에 붙는 parameter 부분입니다.

TLS

GET이나 POST와 별개로 전송 구간을 암호화하고 server를 인증하는 protocol입니다.

TLS가 대칭키와 공개키를 함께 사용하는 이유

TLS는 HTTPS 연결에서 통신 상대를 확인하고 전송 내용을 보호하는 프로토콜이다. 공개키 암호(asymmetric cryptography)는 공개키와 개인키가 달라 키 교환과 서명에 편리하지만 큰 데이터를 처리하기에는 상대적으로 느리다. 대칭키 암호(symmetric cryptography)는 양쪽이 같은 비밀키를 사용하며 빠르다. 그래서 실제 TLS는 인증과 세션키 합의에 공개키 기술을 사용하고, 이후 데이터에는 빠른 대칭키 암호를 사용하는 hybrid 방식이다.

TERMS FROM ZERO

TLS가 대칭키와 공개키를 함께 사용하는 이유 핵심 용어

아래 단어는 이미 안다고 가정하지 않습니다. 먼저 쉬운 뜻을 읽고, 본문에서 같은 단어가 나오면 이 정의로 다시 바꾸어 읽으세요.

TLS

Browser와 server 사이 통신의 기밀성·무결성 및 server 인증을 제공하는 protocol입니다.

Hybrid encryption

공개키 기법으로 key를 합의하거나 보호하고, 실제 대량 데이터는 빠른 대칭키 암호로 처리하는 조합입니다.

Session key

한 연결이나 제한된 기간 동안 실제 application data 암호화에 사용하는 대칭 key입니다.

Handshake

암호 suite와 key material을 정하고 상대를 인증하는 TLS 연결 초기 단계입니다.

02

실제 시스템에서는 이 순서로 움직입니다

모바일에서는 그림 안을 좌우로 움직이며 번호 순서대로 읽으세요.

예시를 단계별로 해체하기

  1. 1단계Browser가 method·path·headers·body로 이루어진 HTTP request를 만듭니다.
  2. 2단계GET parameter는 URL query에 들어가 history·log·bookmark·Referer에 남기 쉽습니다.
  3. 3단계POST는 값을 request body로 옮기지만 network encryption을 제공하지 않습니다.
  4. 4단계TLS가 HTTP request 전체를 전송 중 암호화하고 server certificate를 검증합니다.
  5. 5단계Login secret은 POST와 TLS를 함께 사용하고 server log에도 남기지 않아야 합니다.

이 단계들은 시험 답안에서 원인과 결과가 빠지지 않도록 만든 설명 순서입니다.

손으로 따라가는 초보 예제

같은 login을 GET, POST, POST+TLS로 비교하기

Username `alice`, password `BlueHorse!7`을 server에 보냅니다.

  1. 1단계GET form은 `/login?user=alice&password=BlueHorse!7`처럼 secret을 URL에 넣을 수 있습니다.
  2. 2단계URL은 browser history, server/proxy log, bookmark, Referer 등에 남기 쉽습니다.
  3. 3단계POST는 값을 body로 옮겨 URL 노출을 줄이지만 packet 내용을 암호화하지 않습니다.
  4. 4단계HTTP 위의 POST만 사용하면 network observer가 body를 읽을 수 있습니다.
  5. 5단계HTTPS에서는 TLS가 method, path 이후의 HTTP data를 전송 중 보호하고 server certificate를 검증합니다.
  6. 6단계Login에는 POST over TLS를 쓰고 application log에도 password가 남지 않게 해야 합니다.

그래서 무엇을 배웠나? GET/POST는 HTTP message 배치와 의미를, TLS는 network 전송 보호를 결정합니다.

03

관련 개념도 하나씩 따로 이해하기

Browser, server, HTTP, HTML parser

비유에서 실제 시스템으로 옮겨 보기

먼저 떠올릴 장면 · 같은 기호도 일반 편지 본문에서는 글자지만 계산식 칸에서는 연산자로 읽힌다. Browser도 입력이 HTML text, attribute, script 중 어디에 들어갔는지에 따라 다르게 해석한다.

정확한 뜻 · Browser는 사용자의 client 프로그램이고 web server는 request를 받아 response를 만드는 프로그램이다. HTTP request에는 method, URL, header, body가 있고 response에는 status, header, body가 있다. Browser는 response body를 단순 글자가 아니라 HTML, JavaScript 같은 문법으로 해석(parse)한다. 외부 입력이 처음 들어오는 곳을 source, 그 입력이 실제 기능에 사용되는 위험한 도착점을 sink라고 부른다. 따라서 입력이 어느 문법 위치와 sink에 들어가는지가 보안에 매우 중요하다.

  1. 1단계사용자 입력이 들어오는 source를 찾는다.
  2. 2단계입력이 출력·DB·명령으로 들어가는 sink를 찾는다.
  3. 3단계그 sink를 어떤 parser가 어떤 context로 읽는지 확인한다.
  4. 4단계공격 영향과 context에 맞는 방어를 연결한다.

GET과 POST, 그리고 TLS는 각각 무엇을 바꾸는가

비유에서 실제 시스템으로 옮겨 보기

먼저 떠올릴 장면 · GET은 엽서 겉면에 비밀번호를 쓰는 것, POST는 봉투 안에 넣는 것에 가깝다. 하지만 봉투 자체가 투명하지 않게 보호되는 역할은 TLS가 한다.

정확한 뜻 · GET request의 parameter는 보통 URL query string에 들어가 browser history, bookmark, 화면, proxy·server access log, Referer에 남을 수 있다. POST는 데이터를 request body에 넣어 URL 노출을 줄이지만 자체적으로 암호화하지는 않는다. 전송 중 내용을 보호하려면 HTTPS/TLS가 함께 필요하다.

  1. 1단계Login credential을 URL에 넣지 않는다.
  2. 2단계POST body로 전송한다.
  3. 3단계전체 연결에 HTTPS를 사용한다.
  4. 4단계Server log와 error message에도 credential을 기록하지 않는다.

TLS가 대칭키와 공개키를 함께 사용하는 이유

비유에서 실제 시스템으로 옮겨 보기

먼저 떠올릴 장면 · 처음 만날 때 신분증과 봉인된 절차로 둘만의 회의실 열쇠를 안전하게 정한 다음, 긴 회의 동안에는 그 열쇠로 빠르게 문을 여닫는 것과 같다.

정확한 뜻 · TLS는 HTTPS 연결에서 통신 상대를 확인하고 전송 내용을 보호하는 프로토콜이다. 공개키 암호(asymmetric cryptography)는 공개키와 개인키가 달라 키 교환과 서명에 편리하지만 큰 데이터를 처리하기에는 상대적으로 느리다. 대칭키 암호(symmetric cryptography)는 양쪽이 같은 비밀키를 사용하며 빠르다. 그래서 실제 TLS는 인증과 세션키 합의에 공개키 기술을 사용하고, 이후 데이터에는 빠른 대칭키 암호를 사용하는 hybrid 방식이다.

  1. 1단계Browser가 server의 certificate와 domain name을 검증한다.
  2. 2단계Handshake에서 양쪽이 session key를 합의한다.
  3. 3단계Application data는 합의된 대칭키로 빠르게 보호한다.
  4. 4단계암호화가 계산 시간을 없애거나 거래 내용을 절대적으로 안전하게 만들지는 않는다.

04

강의 스크립트 원본과 연결하기

POST login form과 URL/parameter 처리를 보여 주는 대표 슬라이드입니다. 먼저 위의 초보 설명을 읽고, 원본에서는 같은 개념이 어떤 기호와 독일어·영어 용어로 표현되는지 확인하세요.

HTTP request·GET·POST·TLS 관련 강의 스크립트 대표 슬라이드
원본 Vorlesung/10 Web Application Security.pdf · p.11, p.12, p.15 · POST login form과 URL/parameter 처리
  • 10 Web Application Security.pdf · p.11, p.12, p.15

05

시험 함정과 답안에 적용하기

  • Browser, server, HTTP, HTML parser · 입력 문자열 자체만 보고 취약점을 이름 붙이지 말고 source에서 sink까지 실제 흐름을 추적한다.
  • GET과 POST, 그리고 TLS는 각각 무엇을 바꾸는가 · POST만 쓰면 네트워크에서 비밀번호가 암호화된다고 생각하면 안 된다.
  • TLS가 대칭키와 공개키를 함께 사용하는 이유 · HTTPS가 오직 asymmetric cryptography만 사용한다거나, certificate가 있는 사이트는 정직한 상점이라고 단정하면 안 된다.

서술형 답안 골격

URL/history/log/Referer 노출을 말하고 대안으로 POST over TLS를 씁니다.

정의 → 등장 주체 또는 입력 → 작동 순서 → 보안 효과 → 조건과 한계 순서로 쓰고, 위 단계별 예시에서 필요한 문장을 골라 붙이세요.

30초 자가 확인

책을 덮고 “GET·POST·TLS는 각각 무엇을 바꾸며 왜 POST만으로 비밀번호가 안전하지 않을까요?”에 대해 핵심 용어 두 개, 작동 단계 세 개, 대표 함정 하나를 말해 보세요.

다음 개념으로 넘어가기 전 확인

  1. POST가 encryption이 아닌 이유는?
  2. GET login이 남길 수 있는 노출 위치 세 곳은?
  3. HTTPS에서 certificate 검증이 필요한 이유는?