CSS Tutor Study Hub 메인으로

Computersystemsicherheit 2025/26

실제 시험 문제 56

Web 감사 · Web Sicherheit / 3.4 Phishing

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

Web 감사

문제

근거 신뢰도 높음실제 시험지 대조 완료Web 감사4점

독일어 원문

Ein Administrator von weihnachtsfeier2023.mega-corp.com: Wann kann er Session-Cookies von Blogbesuchern lesen und was kann er damit machen?

한국어 해석

하위 domain 관리자가 언제 blog 방문자의 session cookie를 읽을 수 있고 무엇을 할 수 있는가?

실제 시험 코드 취약 줄 하이라이터

vulnerable lineattacker inputparser/contextimpactfix

실제 WiSe 25/26 시험 코드에서 취약한 줄을 선택하고 영향과 수정법을 말해 보세요.

단계별 힌트

막혔을 때만 한 단계씩 여세요. 정답을 바로 읽는 것보다 기억을 꺼내는 시간이 중요합니다.

0/10
채점 기준으로 내 답안 점검하기
  • 상위 Domain cookie와 host-only 차이를 쓴다.
  • 피해자의 하위 domain 방문 및 Path/Secure 전송 조건을 쓴다.
  • Server의 Cookie header 읽기는 HttpOnly와 무관하고 JavaScript 읽기만 non-HttpOnly 조건임을 구분한다.
  • session hijacking/account takeover 영향을 쓴다.
  • host-only 또는 `__Host-` cookie를 핵심 방어로 쓴다.

답안 슬롯 자가 점검 — 실제로 말하거나 쓴 항목만 체크하세요.

0/5 slots

정답과 핵심 해설 확인하기
summary_ko

Cookie가 host-only가 아니라 `Domain=mega-corp.com`처럼 상위 domain 범위이고 피해자가 악성 하위 domain을 방문하며 Path가 맞고 Secure cookie라면 HTTPS일 때, 하위 domain server는 요청의 Cookie header에서 값을 읽을 수 있다. 이 server-side 경로는 HttpOnly여도 가능하고, JavaScript `document.cookie` 경로에만 non-HttpOnly가 필요하다. 탈취 token을 replay하면 session hijacking이 가능하다.

exam_answer_frame
  • 상위 Domain cookie와 host-only 차이를 쓴다.
  • 피해자의 하위 domain 방문 및 Path/Secure 전송 조건을 쓴다.
  • Server의 Cookie header 읽기는 HttpOnly와 무관하고 JavaScript 읽기만 non-HttpOnly 조건임을 구분한다.
  • session hijacking/account takeover 영향을 쓴다.
  • host-only 또는 `__Host-` cookie를 핵심 방어로 쓴다.
개념부터 다시 보는 상세 풀이

BEGINNER LESSON

웹 보안: 이 문제를 처음부터 이해하기

ZERO-BASE START

정말 아무것도 모른다고 가정하고 시작합니다

전문 용어를 알고 있다고 가정하지 않습니다. 먼저 일상적인 장면을 보고, 그 장면의 사람과 행동에 실제 보안 용어를 하나씩 붙인 뒤, 시스템에서 일어나는 순서를 따라갑니다.

기초 개념 01

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

1타 강사식 시작: 이름은 잠시 가리고 장면부터 봅시다

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

지금은 이 비유를 완벽히 외울 필요가 없습니다. 누가 무엇을 가지고 있고, 무엇을 하려 하며, 어느 지점에서 문제가 생기는지만 찾으면 됩니다.

이제 실제 용어를 하나씩 붙여 봅시다

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

TERMS FROM ZERO

전문 용어를 한 단어씩 풀기

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

XSS

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

Source

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

Sink

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

Output encoding

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

프로그램이나 프로토콜 안에서는 다음 순서로 움직입니다.

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

왜 여기서 많이 틀릴까요?

SQL injection 방어인 prepared statement를 XSS의 직접 해결책으로 쓰거나 client-side filter만 믿으면 안 된다.

조건을 생략하거나 서로 다른 기능을 같은 것으로 취급했는지 확인하세요. 정답 문장을 외우는 것보다 틀린 이유를 말할 수 있어야 변형 문제를 풀 수 있습니다.

기초 개념 02

Browser, server, HTTP, HTML parser

1타 강사식 시작: 이름은 잠시 가리고 장면부터 봅시다

같은 기호도 일반 편지 본문에서는 글자지만 계산식 칸에서는 연산자로 읽힌다. 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에 들어가는지가 보안에 매우 중요하다.

TERMS FROM ZERO

전문 용어를 한 단어씩 풀기

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

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

프로그램이나 프로토콜 안에서는 다음 순서로 움직입니다.

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

왜 여기서 많이 틀릴까요?

입력 문자열 자체만 보고 취약점을 이름 붙이지 말고 source에서 sink까지 실제 흐름을 추적한다.

조건을 생략하거나 서로 다른 기능을 같은 것으로 취급했는지 확인하세요. 정답 문장을 외우는 것보다 틀린 이유를 말할 수 있어야 변형 문제를 풀 수 있습니다.

핵심부터 말하면 cookie의 Domain은 열쇠가 통하는 건물 범위다. 상위 domain 전체용 열쇠를 만들면 신뢰하지 않는 하위 domain 방에도 같은 열쇠가 들어간다.

이 글에서 익힐 것

  • 하위 domain 관리자가 언제 blog 방문자의 session cookie를 읽을 수 있고 무엇을 할 수 있는가?

  • 이 문항에 연결된 2개 기초 개념과 8개 전문 용어를 자신의 말로 설명한다.

  • 정의만 외우지 않고 구체적인 입력·message·code 흐름을 단계별로 재현한다.

  • 시험 답안에서 결론과 근거, 조건 또는 한계를 함께 쓴다.

이 문제가 어려운 이유

문제 문장은 짧지만 초보자가 이미 안다고 가정하는 용어와 중간 단계가 숨어 있습니다. 이 페이지에서는 ‘하위 domain 관리자가 언제 blog 방문자의 session cookie를 읽을 수 있고 무엇을 할 수 있는가?’를 바로 외우지 않고, 아래 연결 개념을 일상 장면에서 시작해 실제 시스템 순서로 바꿉니다.

문제가 묻는 것

하위 domain 관리자가 언제 blog 방문자의 session cookie를 읽을 수 있고 무엇을 할 수 있는가?

문제가 요구하는 동사와 답의 개수를 먼저 표시하고, 등장 주체·입력·처리 순서·보안 효과·남는 한계를 차례로 적습니다.

먼저 알아야 할 개념

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

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

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

  • 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에 들어가는지가 보안에 매우 중요하다.

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

예제로 확인하기

  • XSS와 output encoding을 처음부터 이해하기을 이 문제에 대입하기

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

    1. $_GET 같은 사용자 입력 source를 찾는다.

    2. echo처럼 HTML response에 쓰는 sink를 찾는다.

    3. HTML body, attribute, URL, JavaScript 중 context를 판별한다.

    4. 해당 context용 encoding과 안전한 template API를 적용한다.

    위 순서를 문제 문장 ‘하위 domain 관리자가 언제 blog 방문자의 session cookie를 읽을 수 있고 무엇을 할 수 있는가?’에 적용하면, 이 문항의 핵심 결론은 Cookie가 host-only가 아니라 `Domain=mega-corp.com`처럼 상위 domain 범위이고 피해자가 악성 하위 domain을 방문하며 Path가 맞고 Secure cookie라면 HTTPS일 때, 하위 domain server는 요청의 Cookie header에서 값을 읽을 수 있다. 이 server-side 경로는 HttpOnly여도 가능하고, JavaScript `document.cookie` 경로에만 non-HttpOnly가 필요하다. 탈취 token을 replay하면 session hijacking이 가능하다.입니다.

  • Browser, server, HTTP, HTML parser을 이 문제에 대입하기

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

    1. 사용자 입력이 들어오는 source를 찾는다.

    2. 입력이 출력·DB·명령으로 들어가는 sink를 찾는다.

    3. 그 sink를 어떤 parser가 어떤 context로 읽는지 확인한다.

    4. 공격 영향과 context에 맞는 방어를 연결한다.

    위 순서를 문제 문장 ‘하위 domain 관리자가 언제 blog 방문자의 session cookie를 읽을 수 있고 무엇을 할 수 있는가?’에 적용하면, 이 문항의 핵심 결론은 Cookie가 host-only가 아니라 `Domain=mega-corp.com`처럼 상위 domain 범위이고 피해자가 악성 하위 domain을 방문하며 Path가 맞고 Secure cookie라면 HTTPS일 때, 하위 domain server는 요청의 Cookie header에서 값을 읽을 수 있다. 이 server-side 경로는 HttpOnly여도 가능하고, JavaScript `document.cookie` 경로에만 non-HttpOnly가 필요하다. 탈취 token을 replay하면 session hijacking이 가능하다.입니다.

정답까지 사고 과정

  1. 상위 Domain cookie와 host-only 차이를 쓴다.

  2. 피해자의 하위 domain 방문 및 Path/Secure 전송 조건을 쓴다.

  3. Server의 Cookie header 읽기는 HttpOnly와 무관하고 JavaScript 읽기만 non-HttpOnly 조건임을 구분한다.

  4. session hijacking/account takeover 영향을 쓴다.

  5. host-only 또는 `__Host-` cookie를 핵심 방어로 쓴다.

시험장에서는 이렇게 쓰기

핵심 해설

Cookie가 host-only가 아니라 `Domain=mega-corp.com`처럼 상위 domain 범위이고 피해자가 악성 하위 domain을 방문하며 Path가 맞고 Secure cookie라면 HTTPS일 때, 하위 domain server는 요청의 Cookie header에서 값을 읽을 수 있다. 이 server-side 경로는 HttpOnly여도 가능하고, JavaScript `document.cookie` 경로에만 non-HttpOnly가 필요하다. 탈취 token을 replay하면 session hijacking이 가능하다.

시험 답안으로 정리하기

  • 상위 Domain cookie와 host-only 차이를 쓴다.

  • 피해자의 하위 domain 방문 및 Path/Secure 전송 조건을 쓴다.

  • Server의 Cookie header 읽기는 HttpOnly와 무관하고 JavaScript 읽기만 non-HttpOnly 조건임을 구분한다.

  • session hijacking/account takeover 영향을 쓴다.

  • host-only 또는 `__Host-` cookie를 핵심 방어로 쓴다.

자주 틀리는 지점

  • Same-Origin Policy만 말하고 cookie Domain 규칙을 놓치지 않는다.

  • Secure는 HTTP 전송을 막지만 JavaScript 읽기를 막는 HttpOnly와 다르다.

  • HttpOnly가 attacker subdomain server로 향하는 Cookie header 전송까지 막는다고 생각하지 않는다.

  • Sibling subdomain이 같은 site로 취급될 수 있으므로 SameSite를 host scope 대체재로 제시하지 않는다.

채점 포인트

  • 상위 Domain cookie와 host-only 차이를 쓴다.

  • 피해자의 하위 domain 방문 및 Path/Secure 전송 조건을 쓴다.

  • Server의 Cookie header 읽기는 HttpOnly와 무관하고 JavaScript 읽기만 non-HttpOnly 조건임을 구분한다.

  • session hijacking/account takeover 영향을 쓴다.

  • host-only 또는 `__Host-` cookie를 핵심 방어로 쓴다.

한 줄로 기억하기

cookie의 Domain은 열쇠가 통하는 건물 범위다. 상위 domain 전체용 열쇠를 만들면 신뢰하지 않는 하위 domain 방에도 같은 열쇠가 들어간다.

스스로 확인하기

  • `__Host-` prefix cookie가 이 문제를 줄이는 조건은?

AI 구두시험용 프롬프트

한 문항만 풀어라. 먼저 정답을 열지 말고 90초 안에 답안을 말한 뒤, css-ws2025-26-web-phish-003의 채점 프레임으로 스스로 채점하라. 문제: 하위 domain 관리자가 언제 blog 방문자의 session cookie를 읽을 수 있고 무엇을 할 수 있는가?

학습 기록

이 문항을 얼마나 이해했나요?