CSS Tutor Study Hub 메인으로

Computersystemsicherheit 2025/26

17. XSS·Output encoding 완전 초보 강의

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

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

CSS 1타 강사 · CONCEPT 17/25

사용자 입력이 언제 단순 문자열이 아니라 Browser의 코드가 될까요?

XSS는 attacker-controlled input이 response에 들어가 Browser가 이를 data가 아니라 HTML/JavaScript code로 해석할 때 발생합니다. 핵심 방어는 출력 위치에 맞는 context-sensitive encoding이며 CSP는 추가 방어층입니다.

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

게시판 이름 칸에 적은 글이 명찰로 인쇄되지 않고 작업 지시서로 실행되는 상황입니다.

문자열이 Browser에서 HTML/JavaScript로 실행되는 문제

00

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

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

검색어 q가 HTML response의 <div> 안에 그대로 삽입되고 공격자가 <script>...</script>를 입력한 상황을 따라갑니다.

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

  • 이름 칸에 쓴 문장이 작업 지시로 읽힘data가 HTML/JS code로 해석됨
  • 입력이 들어오는 입구source
  • browser parser 앞의 출력 위치sink/context

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

01

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

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

XSS와 output encoding을 처음부터 이해하기

Cross-Site Scripting(XSS)은 공격자 입력이 피해자 browser에서 신뢰된 사이트의 HTML 또는 JavaScript로 해석되어 실행되는 취약점이다. Reflected XSS는 request의 입력이 곧바로 response에 반사되는 형태다. 방어의 핵심은 출력 위치에 맞는 output encoding으로 특별한 문자를 데이터로만 해석하게 만드는 것이다.

TERMS FROM ZERO

XSS와 output encoding을 처음부터 이해하기 핵심 용어

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

XSS

공격자 입력이 victim browser에서 data가 아니라 HTML 또는 JavaScript code로 실행되는 취약점입니다.

Source

공격자 입력이 들어오는 URL, form, database record 같은 시작점입니다.

Sink

입력이 HTML이나 script로 해석될 수 있는 위험한 사용 지점입니다.

Output encoding

출력 context에서 특수문자가 code 문법이 아니라 data로 표현되도록 변환하는 방어입니다.

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 방법을 결정합니다.

02

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

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

예시를 단계별로 해체하기

  1. 1단계Attacker-controlled input이 URL·form·database 등 source에서 들어옵니다.
  2. 2단계Server가 값을 HTML response의 특정 context에 출력합니다.
  3. 3단계Encoding이 없으면 Browser parser가 입력을 data가 아니라 markup 또는 script로 해석할 수 있습니다.
  4. 4단계Script가 victim origin에서 실행되어 cookie 접근·request 전송·화면 변조를 수행할 수 있습니다.
  5. 5단계방어는 HTML text·attribute·JavaScript·URL 등 출력 context에 맞는 encoding입니다.
  6. 6단계CSP는 추가 방어층이며 근본적인 output encoding을 대체하지 않습니다.

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

손으로 따라가는 초보 예제

검색어 `<img ...>`가 HTML element가 되는 순간

Server가 `<div>검색: USER_INPUT</div>`에 사용자의 검색어를 그대로 연결합니다.

  1. 1단계공격자는 URL query에 HTML 문법을 포함한 값을 넣습니다.
  2. 2단계Server가 이를 encoding 없이 response HTML의 `<div>` 안에 붙입니다.
  3. 3단계Browser HTML parser는 입력을 글자가 아니라 새 element와 event handler로 해석할 수 있습니다.
  4. 4단계실행된 script는 victim이 보고 있는 site origin의 권한으로 request를 보내거나 화면을 바꿀 수 있습니다.
  5. 5단계HTML text context에서는 `<` 등이 data로 보이도록 HTML encoding해야 합니다.
  6. 6단계Attribute, JavaScript, URL context는 필요한 encoding 규칙이 다르며 CSP는 추가 방어층입니다.

그래서 무엇을 배웠나? XSS는 ‘나쁜 문자열’ 문제가 아니라 attacker input이 어떤 browser context의 parser에 도달했는가의 문제입니다.

03

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

XSS와 output encoding을 처음부터 이해하기

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

먼저 떠올릴 장면 · 설문 답변 칸에 쓴 문장을 사회자가 그대로 읽어야 하는데, 답변이 무대 지시문으로 해석되어 조명과 문을 조작하는 상황과 같다.

정확한 뜻 · Cross-Site Scripting(XSS)은 공격자 입력이 피해자 browser에서 신뢰된 사이트의 HTML 또는 JavaScript로 해석되어 실행되는 취약점이다. Reflected XSS는 request의 입력이 곧바로 response에 반사되는 형태다. 방어의 핵심은 출력 위치에 맞는 output encoding으로 특별한 문자를 데이터로만 해석하게 만드는 것이다.

  1. 1단계$_GET 같은 사용자 입력 source를 찾는다.
  2. 2단계echo처럼 HTML response에 쓰는 sink를 찾는다.
  3. 3단계HTML body, attribute, URL, JavaScript 중 context를 판별한다.
  4. 4단계해당 context용 encoding과 안전한 template API를 적용한다.

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에 맞는 방어를 연결한다.

04

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

XSS 실행 위치·영향·reflected 흐름를 보여 주는 대표 슬라이드입니다. 먼저 위의 초보 설명을 읽고, 원본에서는 같은 개념이 어떤 기호와 독일어·영어 용어로 표현되는지 확인하세요.

XSS·Output encoding 관련 강의 스크립트 대표 슬라이드
원본 Vorlesung/10 Web Application Security.pdf · p.21, p.18, p.23 · XSS 실행 위치·영향·reflected 흐름
  • 10 Web Application Security.pdf · p.21, p.18, p.23

05

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

  • XSS와 output encoding을 처음부터 이해하기 · SQL injection 방어인 prepared statement를 XSS의 직접 해결책으로 쓰거나 client-side filter만 믿으면 안 된다.
  • Browser, server, HTTP, HTML parser · 입력 문자열 자체만 보고 취약점을 이름 붙이지 말고 source에서 sink까지 실제 흐름을 추적한다.

서술형 답안 골격

source → sink/output context → 실행 가능한 payload 종류 → impact → context-aware encoding 순서로 답합니다.

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

30초 자가 확인

책을 덮고 “사용자 입력이 언제 단순 문자열이 아니라 Browser의 코드가 될까요?”에 대해 핵심 용어 두 개, 작동 단계 세 개, 대표 함정 하나를 말해 보세요.

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

  1. Source와 sink의 차이는?
  2. HTML text와 JavaScript string에 같은 encoding을 쓰면 안 되는 이유는?
  3. CSP가 output encoding을 대체하지 못하는 이유는?