CSS Tutor Study Hub 메인으로

Computersystemsicherheit 2025/26

3.1. Multiple Choice

실제 시험 Abschnitt 3.1 · 8개 학습 항목 초보 해설

3. Websicherheit / Web Security · 실제 시험 Abschnitt 3.1

3.1. Multiple Choice

Web security MC 8개를 SameSite부터 CSP까지 시험지 a–h 순서 그대로 학습합니다.

이 페이지는 비슷한 주제를 임의로 다시 묶지 않고 실제 시험지의 Chapter → subsection → 소문제 순서를 그대로 따릅니다.

ACTUAL EXAM · VERBATIM TRANSCRIPT

시험지 원문 1:1 전사

아래 내용은 해설자가 바꿔 쓴 요약이 아닙니다. 실제 시험 전사본의 문장·순서·수치·배점·코드·표를 그대로 두고, Markdown 기호만 읽기 쉬운 제목·표·코드 모양으로 표시했습니다.

3.1. Multiple Choice (16 Punkte)

Bitte kreuzen Sie für jede der folgenden Aussagen „Wahr“ oder „Falsch“ an.

Nur eine der beiden Auswahlmöglichkeiten ist richtig.

Jede korrekte Antwort gibt zwei Punkte und erfordert keine weitere Begründung.

Nr.WahrFalschAussage
a)Das SameSite-Attribut verhindert, dass ein Cookie bei Cross-Site-Anfragen mitgesendet wird.
b)Das HttpOnly-Cookie-Attribut veranlasst, dass ein Cookie nur im Browser innerhalb der JavaScript Umgebung gelesen werden kann.
c)Parameterisierte Queries (stored procedures) sind ein effektiver serverseitiger Schutz gegen SQL-Injection.
d)Die Same-Origin Policy (SOP) erlaubt es Skripten standardmäßig, Daten von beliebigen anderen Domänen auszulesen.
e)Bei SSRF wird ein Server dazu gebracht, unautorisierte Anfragen an interne Ressourcen zu stellen.
f)HSTS ist ein Mechanismus, der Cross-Site Request Forgery (CSRF) Angriffe vollständig unterbindet.
g)Ein SRI Hash wird verwendet, um die Integrität von Skripten zu validieren, die über ein CDN geladen werden.
h)Die Content Security Policy (CSP) definiert, welche Skripte, Styles und Datenquellen eine Webseite als vertrauenswürdig eingestuft sind.

근거: CSS_Altklausur_WiSe_2526.pdfcomputersystemsicherheit_wise25-26_questions_only.md · Abschnitt 3.1

VISUAL MAP

Web MC의 담당 경계 찾기 왼쪽에서 오른쪽으로 읽은 뒤 아래 실제 소문제에서 같은 순서를 반복합니다.
  1. 01 속성·공격 이름
  2. 02 Browser·Server
  3. 03 막는 동작
  4. 04 막지 못하는 동작
  5. 05 판정

FIXED SOLVING METHOD

이 묶음의 고정 풀이 순서

  1. 주어가 cookie attribute, browser policy, server defense 중 무엇인지 분류합니다.
  2. 그 기능이 제어하는 정확한 동작을 적습니다.
  3. same-site와 same-origin처럼 비슷한 용어를 분리합니다.
  4. ‘완전히’, ‘임의의’ 같은 범위 표현을 반례로 검사합니다.
  5. Wahr/Falsch를 결정합니다.

ZERO-BASE CONCEPT LESSONS

이 묶음을 풀기 전에 필요한 개념

카드를 열고 닫는 방식 대신 한 방향으로 이어지는 글로 구성했습니다. 비유 → 용어의 쉬운 뜻 → 실제 작동 → 시험에서의 경계 순서로 천천히 읽으세요.

기초 개념 01

Browser, server, HTTP, HTML parser

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

이제 전문 용어를 붙이면 다음과 같습니다. 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 방법을 결정합니다.

실제 시스템에서는 이렇게 작동합니다. 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. 사용자 입력이 들어오는 source를 찾는다.
  2. 입력이 출력·DB·명령으로 들어가는 sink를 찾는다.
  3. 그 sink를 어떤 parser가 어떤 context로 읽는지 확인한다.
  4. 공격 영향과 context에 맞는 방어를 연결한다.

여기서 넘지 말아야 할 경계: 입력 문자열 자체만 보고 취약점을 이름 붙이지 말고 source에서 sink까지 실제 흐름을 추적한다.

15. HTTP request·GET·POST·TLS 독립 강의 →

기초 개념 02

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

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

이제 전문 용어를 붙이면 다음과 같습니다. XSS은(는) 공격자 입력이 victim browser에서 data가 아니라 HTML 또는 JavaScript code로 실행되는 취약점입니다. Source은(는) 공격자 입력이 들어오는 URL, form, database record 같은 시작점입니다. Sink은(는) 입력이 HTML이나 script로 해석될 수 있는 위험한 사용 지점입니다. Output encoding은(는) 출력 context에서 특수문자가 code 문법이 아니라 data로 표현되도록 변환하는 방어입니다.

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

  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만 믿으면 안 된다.

17. XSS·Output encoding 독립 강의 →

기초 개념 03

SQL injection과 prepared statement

먼저 장면으로 이해해 봅시다. 주문서의 이름 칸에 ‘주문 취소하고 금고 열기’라고 썼을 때 직원이 그것을 이름이 아니라 새 지시로 실행하는 문제다. Prepared statement는 이름 칸을 끝까지 데이터 칸으로 고정한다.

이제 전문 용어를 붙이면 다음과 같습니다. SQL query은(는) Database에 조회·삽입·변경 등을 요청하는 SQL 문장입니다. SQL injection은(는) 공격자 입력이 SQL data가 아니라 query 구조와 명령으로 해석되는 취약점입니다. Prepared statement은(는) SQL 구조를 먼저 고정하고 사용자 값을 별도 parameter로 전달하는 방식입니다. Parameter binding은(는) 입력값을 SQL syntax와 분리된 data slot에 연결하는 과정입니다.

실제 시스템에서는 이렇게 작동합니다. SQL은 database에 질문하는 언어다. 프로그램이 SQL 문자열과 사용자 입력을 단순히 이어 붙이면 입력의 따옴표나 연산자가 데이터가 아니라 SQL 문법으로 해석될 수 있다. 이것이 SQL injection이다. Prepared statement는 SQL 구조를 먼저 고정하고 사용자 값은 별도 parameter로 전달해 값이 명령 문법이 되지 못하게 한다.

  1. $_GET, $_POST 같은 입력 source를 찾는다.
  2. SQL 문자열 연결 또는 interpolation 지점을 찾는다.
  3. 입력이 query 구조를 바꿀 수 있는지 확인한다.
  4. Prepared statement와 bound parameter로 구조와 값을 분리한다.
  5. Database account 권한도 최소화한다.

여기서 넘지 말아야 할 경계: 따옴표를 몇 개 치환하는 blacklist나 client-side validation만으로 해결하려 하지 않는다.

18. SQL Injection·Prepared statement 독립 강의 →

기초 개념 04

보안이란 무엇을 지키는 것인가

먼저 장면으로 이해해 봅시다. 봉투에 넣어 내용을 가리는 것은 기밀성, 봉인 스티커로 개봉 여부를 확인하는 것은 무결성, 발신인의 도장을 확인하는 것은 진위성, 우체국이 문을 열어 편지를 계속 전달하는 것은 가용성에 가깝다.

이제 전문 용어를 붙이면 다음과 같습니다. Asset은(는) 공격자로부터 지키려는 대상입니다. 파일, 비밀번호, 서비스 가용성, 사람의 개인정보가 모두 asset이 될 수 있습니다. Confidentiality은(는) 허가받지 않은 사람이 내용을 읽지 못하게 하는 기밀성입니다. Integrity은(는) 데이터나 시스템이 허가 없이 바뀌지 않았음을 보장하려는 무결성입니다. Availability은(는) 정당한 사용자가 필요할 때 서비스와 데이터에 접근할 수 있는 가용성입니다.

실제 시스템에서는 이렇게 작동합니다. 컴퓨터 보안은 막연히 ‘안전하게 만들기’가 아니라 지켜야 할 성질을 구분하는 일에서 시작한다. 기밀성(Vertraulichkeit, confidentiality)은 허가받지 않은 사람이 내용을 읽지 못하게 하는 것, 무결성(Integrität, integrity)은 내용이 몰래 바뀌지 않았음을 확인하는 것, 진위성(Authentizität, authenticity)은 상대나 데이터의 출처가 주장과 맞는지 확인하는 것이다. 서비스가 필요할 때 계속 동작하는 성질은 가용성(Verfügbarkeit, availability)이라고 한다.

  1. 문제에서 숨김, 변조 탐지, 신원 확인, 서비스 중단 중 무엇을 묻는지 찾는다.
  2. 한 기술이 네 목표를 모두 자동으로 제공한다고 가정하지 않는다.
  3. 공격자가 무엇을 할 수 있는지와 지켜야 할 목표를 한 문장씩 분리한다.

여기서 넘지 말아야 할 경계: TLS, 암호화, 서명, hash처럼 익숙한 단어가 나오더라도 그 기술이 제공하지 않는 목표까지 확대해서 쓰면 안 된다.

01. 평문·암호문·키 독립 강의 →

QUESTION-BY-QUESTION COMMENTARY

실제 시험 소문제별 해설

시험지의 번호와 순서를 그대로 유지했습니다. 각 항목을 열어 원문 → 쉬운 개념 설명 → 이번 문제의 단계별 풀이 → 답안 → 함정 순서로 읽으세요.

ACTUAL EXAM SUBSECTION 3.1

3.1. Multiple Choice

8개 학습 항목 · 16점

3.1 a) SameSite 속성은 cross-site 요청에 cookie가 전송되는 것을 막는다. 기존 71문항 학습 번호 37 · 2점 Wahr/Falsch

3.1 a) · 실제 시험 원문

Das SameSite-Attribut verhindert, dass ein Cookie bei Cross-Site-Anfragen mitgesendet wird.

한국어로 요구사항만 풀어 읽기

SameSite 속성은 cross-site 요청에 cookie가 전송되는 것을 막는다.

Browser, server, HTTP, HTML parser

TERMS FOR 3.1 a)

이 소문제의 중요한 용어부터 이해하기

전문 용어를 알고 있다고 가정하지 않습니다. 아래 정의의 굵은 용어를 문제 문장 속 같은 단어와 바꾸어 읽은 뒤 풀이로 넘어가세요.

01SameSite

Cookie가 cross-site 요청에 자동으로 포함되는 범위를 조절하는 속성입니다. Strict, Lax, None 값의 동작이 서로 다릅니다.

작은 예: Lax는 일부 top-level 이동에서 cookie 전송을 허용하므로 ‘모든 cross-site 전송 차단’과 같지 않습니다.

02HTTP request

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

03HTTP response

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

04Parser / Interpreter

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

05Context

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

ZERO-BASE MINI LESSON · 3.1 a)

이 소문제만을 위한 0부터 시작하는 미니 강의

아래 설명은 이 과목의 선행 지식을 가정하지 않습니다. 개념 → 비유의 대응 → 눈으로 읽는 구조 → 작은 예제 순서로 읽은 뒤 실제 시험 풀이로 넘어가세요.

1 · 먼저 알아야 할 개념

Cookie는 웹사이트가 브라우저에 맡겨 두는 작은 문자열입니다. 로그인 성공 뒤 받은 session cookie를 브라우저가 다음 요청에 자동으로 붙이면 서버는 같은 사용자의 요청임을 알아봅니다. 이 자동 전송 때문에 편리하지만, 공격 사이트가 만든 요청에도 cookie가 붙을 수 있다는 문제가 생깁니다.

Same-site와 same-origin은 같은 말이 아닙니다. Origin은 scheme·host·port의 조합이고, site 판정은 대체로 scheme과 등록 가능 도메인을 기준으로 합니다. 이 문항의 Cross-Site는 사용자가 보고 있는 site와 요청 대상 site가 다른 상황을 뜻합니다.

SameSite는 하나의 켜기/끄기 스위치가 아니라 Strict, Lax, None이라는 값에 따라 cookie 전송 범위를 정하는 속성입니다. Strict는 cross-site 전송을 가장 강하게 제한하고, Lax는 일반적인 top-level 안전한 navigation 같은 일부 경우를 허용하며, NoneSecure와 함께 쓰면 cross-site 전송을 허용합니다.

2 · 일상 장면으로 먼저 잡기

회사 출입증을 다른 건물에서 온 방문 요청에 언제 보여 줄지 정하는 규칙이라고 생각해 봅시다.

  • 회사 출입증 브라우저가 보관하는 session cookie
  • 외부 건물에서 시작된 방문 cross-site request
  • 외부 요청에는 절대 제시하지 않음 SameSite=Strict
  • 정문으로 직접 들어오는 일부 방문은 허용 SameSite=Lax의 제한적 예외

비유의 경계 실제 SameSite 판정은 단순한 물리적 건물 구분이 아니라 브라우저의 site 계산, request method, top-level navigation 여부에 따릅니다. 또한 SameSite만으로 모든 CSRF를 해결한다고 볼 수 없습니다.

3 · 눈으로 관계 읽기 Cross-site 요청에서 SameSite 값별 cookie
  1. 01 Strict

    cross-site context에서 cookie 전송을 강하게 제한

  2. 02 Lax + POST

    일반적인 cross-site POST에는 전송하지 않음

  3. 03 Lax + top-level GET

    일부 navigation에는 전송될 수 있음

  4. 04 None; Secure

    HTTPS cross-site 요청에도 전송 허용

같은 cookie라도 SameSite 값과 요청 형태가 달라지면 전송 결과가 달라집니다.

4 · TOY EXAMPLE

세 SameSite 값으로 같은 요청 비교하기

주어진 것과 목표 사용자는 bank.example에 로그인해 session=ABC cookie를 가지고 있습니다. 이후 evil.example의 링크나 form이 https://bank.example/transfer로 요청을 일으킵니다.

  1. 01
    SameSite=Strict인 경우를 대입합니다.

    왜? Strict는 다른 site에서 시작된 요청에 cookie를 보내지 않는 것이 기본이기 때문입니다.

    중간 결과 공격 site가 만든 cross-site 요청에는 session=ABC가 빠져 인증된 송금 요청이 되기 어렵습니다.

  2. 02
    SameSite=Lax에서 공격자가 POST form을 자동 제출하는 경우를 봅니다.

    왜? Lax는 모든 cross-site 요청을 허용하지 않고, 일반적인 cross-site POST에는 cookie를 제한합니다.

    중간 결과 이 POST에는 보통 session cookie가 붙지 않습니다.

  3. 03
    SameSite=Lax에서 사용자가 top-level GET 링크를 누르는 경우를 봅니다.

    왜? Lax는 일부 top-level 안전한 navigation을 허용하기 때문입니다.

    중간 결과 조건에 따라 cookie가 전송될 수 있으므로 ‘SameSite가 있으면 전부 차단’이라는 문장은 성립하지 않습니다.

  4. 04
    SameSite=None; Secure를 대입합니다.

    왜? None은 제3자·cross-site 용도를 명시하는 값입니다.

    중간 결과 HTTPS 요청이면 cross-site에서도 cookie가 전송될 수 있습니다.

예제 결론 SameSite의 효과는 속성의 존재가 아니라 선택한 값과 요청 상황에 의해 결정됩니다.

실제 시험으로 옮기기 시험 문장은 값을 한정하지 않은 채 cross-site 전송을 모두 막는다고 일반화했으므로 정답은 Falsch입니다.

개념 근거와 더 깊은 설명

시험 문구·배점은 실제 시험 PDF를 따르고, 위 개념 설명은 연결된 강의 자료의 해당 페이지를 기준으로 구성했습니다.

이번 문제는 이 단계로 풀어야 했습니다

먼저 문제에서 직접 주어진 값과 최종적으로 구할 값을 분리합니다. 그다음 각 값·용어·경로를 왜 선택했는지 확인하며, 앞 단계의 중간 결과를 다음 단계의 입력으로 사용합니다.

START HERE

먼저 문제를 식과 조건으로 정리하기

계산을 시작하기 전에 주어진 것구할 것을 분리합니다. 그다음 아래 관계식을 위에서 아래로 사용하면, 숫자가 어디서 왔는지 놓치지 않을 수 있습니다.

강사가 문제의 요구사항을 쉬운 말로 바꾸면

시험 문장이 요구하는 것: SameSite 속성은 cross-site 요청에 cookie가 전송되는 것을 막는다.

이 문제의 풀이 전략: 이 소문제에서는 절대 표현을 찾는다 → 속성의 가능한 값을 나열한다 → 가장 명확한 반례를 대입한다 → Lax의 예외도 구분한다 → 판정을 적는다 순서로 진행합니다. 마지막에는 ‘Strict·Lax·None을 각각 별도 정책으로 기억하고, 문장에 값이 없으면 절대 차단 명제를 의심합니다.’라는 교정 기준으로 답을 다시 확인합니다.

문제에서 주어진 정보
  • 실제 시험이 준 상황·문장

    SameSite 속성은 cross-site 요청에 cookie가 전송되는 것을 막는다.

  • 이 문항의 첫 출발점

    문장은 SameSite가 cross-site 요청의 cookie 전송을 막는다고 값과 예외 없이 말합니다.

    `항상`, `전부`, 값의 생략처럼 반례 하나로 깨질 수 있는 표현인지 봅니다.

최종적으로 구해야 하는 것
  • 마지막에 도달할 답안

    Falsch. SameSite는 값에 따라 cross-site 전송을 제한하거나 허용합니다.

  • 정답을 지탱하는 이유

    정답은 Falsch입니다. `SameSite=Strict`는 cross-site cookie 전송을 강하게 제한하지만 `Lax`에는 일부 top-level navigation 예외가 있고, `SameSite=None; Secure`는 HTTPS cross-site 전송을 명시적으로 허용합니다. 따라서 SameSite 속성이라는 이름만으로 모든 cross-site 요청에서 cookie가 빠진다고 할 수 없습니다.

사용할 공식·판정 관계
  • 이 소문제만의 풀이 사슬

    절대 표현을 찾는다 → 속성의 가능한 값을 나열한다 → 가장 명확한 반례를 대입한다 → Lax의 예외도 구분한다 → 판정을 적는다

    같은 cookie라도 SameSite 값과 요청 형태가 달라지면 전송 결과가 달라집니다.

  1. 01

    절대 표현을 찾는다

    구체적으로 문장은 SameSite가 cross-site 요청의 cookie 전송을 막는다고 값과 예외 없이 말합니다.

    여기서 검산 항상, 전부, 값의 생략처럼 반례 하나로 깨질 수 있는 표현인지 봅니다.

    다음 단계로 여기서 확인한 내용을 다음 ‘속성의 가능한 값을 나열한다’ 단계의 출발점으로 사용합니다.

  2. 02

    속성의 가능한 값을 나열한다

    구체적으로 Strict, Lax, None이 있고 각각의 전송 정책이 다릅니다.

    여기서 검산 SameSite를 단순 boolean 속성으로 취급하지 않았는지 확인합니다.

    다음 단계로 여기서 확인한 내용을 다음 ‘가장 명확한 반례를 대입한다’ 단계의 출발점으로 사용합니다.

  3. 03

    가장 명확한 반례를 대입한다

    구체적으로 SameSite=None; Secure cookie는 HTTPS cross-site 요청에 전송될 수 있습니다.

    여기서 검산 문장의 보편 명제를 깨는 실제 설정 하나가 제시됐는지 확인합니다.

    다음 단계로 여기서 확인한 내용을 다음 ‘Lax의 예외도 구분한다’ 단계의 출발점으로 사용합니다.

  4. 04

    Lax의 예외도 구분한다

    구체적으로 Lax도 일부 top-level navigation에서 cookie 전송을 허용할 수 있습니다.

    여기서 검산 Strict의 동작을 SameSite 전체의 동작으로 잘못 확장하지 않았는지 봅니다.

    다음 단계로 여기서 확인한 내용을 다음 ‘판정을 적는다’ 단계의 출발점으로 사용합니다.

  5. 05

    판정을 적는다

    구체적으로 Falsch. SameSite는 값에 따라 cross-site 전송을 제한하거나 허용합니다.

    여기서 검산 Falsch와 값별 차이가 함께 들어갔는지 확인합니다.

    다음 단계로 앞 단계의 결과를 모아 채점 가능한 최종 답안으로 정리합니다.

정답과 해설

Falsch. SameSite는 값에 따라 동작한다. Strict는 강하게 제한하지만 Lax는 일부 top-level navigation을 허용하고 None은 cross-site 전송을 허용한다.

시험 답안 골격

  1. Falsch로 표시한다.
  2. SameSite는 값에 따라 동작한다. Strict는 강하게 제한하지만 Lax는 일부 top-level navigation을 허용하고 None은 cross-site 전송을 허용한다.

정답이 이렇게 되는 이유

정답은 Falsch입니다. SameSite=Strict는 cross-site cookie 전송을 강하게 제한하지만 Lax에는 일부 top-level navigation 예외가 있고, SameSite=None; Secure는 HTTPS cross-site 전송을 명시적으로 허용합니다. 따라서 SameSite 속성이라는 이름만으로 모든 cross-site 요청에서 cookie가 빠진다고 할 수 없습니다.

초보자가 가장 자주 뒤집는 지점

잘못된 생각 SameSite라는 속성을 붙이면 값과 관계없이 외부 site의 모든 요청에서 cookie가 차단된다.

왜 틀렸나 속성과 그 값의 정책을 구분하지 않았고 Lax의 예외 및 None의 허용 동작을 놓쳤습니다.

고쳐 말하면 Strict·Lax·None을 각각 별도 정책으로 기억하고, 문장에 값이 없으면 절대 차단 명제를 의심합니다.

한 문제만 더: 개념이 정말 연결됐는지 확인

질문 SameSite=None인 session cookie를 현대 브라우저에서 cross-site HTTPS 용도로 쓰려면 보통 함께 필요한 속성은 무엇입니까?

정답 Secure입니다. 따라서 cookie는 HTTPS 연결에서만 전송됩니다.

이 문제의 오답 함정

  • SameSite라는 속성이 존재하기만 하면 모든 cross-site 전송이 차단된다고 단정하지 않는다.
ACTIVE RECALL

이 소문제를 점수로 바꾸는 6개의 작은 훈련

해설을 닫은 상태에서 1번부터 수행하세요. 정답을 읽은 직후보다 직접 문제 지도를 만들고 답을 꺼낸 뒤 채점할 때 기억이 더 정확해집니다. 작성 내용과 복습 판정은 이 브라우저에 자동 저장됩니다.

  1. 01 · 30초 문제 지도

    해설을 보지 말고 주어진 정보 → 구할 것 → 사용할 공식·판정 관계를 한 줄씩 복원하세요.

    막힐 때만 첫 단서 열기

    SameSite는 값에 따라 동작한다. Strict는 강하게 제한하지만 Lax는 일부 top-level navigation을 허용하고 None은 cross-site 전송을 허용한다.

  2. 02 · 90초 닫힌책 답안

    SameSite 속성은 cross-site 요청에 cookie가 전송되는 것을 막는다.

    정답 문장만 말하지 말고 근거·중간값·메시지 흐름 중 이 문항에 필요한 것을 빈 종이에 남기세요.

  3. 03 · 부분점수 자가채점

    작성한 뒤에만 아래 기준을 열고, 실제로 쓴 항목만 체크하세요.

    답안 작성 후 채점 기준 열기

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

    0/2 slots

  4. 04 · 문항별 후속 질문·조건 전이
    • Strict, Lax, None의 차이를 말해 보라.
    • 원문의 판정을 반대로 만들 수 있는 최소 조건 변경 하나를 제시하고, 바뀐 문장이 정의의 어느 조건을 만족하는지 설명하세요.

    조건 변형: 원문의 강한 표현(예: muss, immer, vollständig)을 조건부 표현으로 하나 고쳐 쓰고, 그 변경 뒤에는 판정이 왜 달라지거나 유지되는지 반례와 함께 설명하세요.

  5. 05 · 대표 오답 복구

    고칠 답안: SameSite라는 속성이 존재하기만 하면 모든 cross-site 전송이 차단된다고 단정하지 않는다.

    복구 힌트: SameSite는 값에 따라 동작한다. Strict는 강하게 제한하지만 Lax는 일부 top-level navigation을 허용하고 None은 cross-site 전송을 허용한다.

    오답의 첫 잘못된 전제를 한 줄로 지우고, 올바른 조건과 결론을 두 줄로 다시 쓰세요.

  6. 06 · 확신도 보정·다음 복습 결정

    채점 전 예상과 실제 채점 결과가 달랐는지 확인한 뒤 상태를 남기세요. ‘숙달’은 근거와 중간 과정까지 무힌트로 재현했을 때만 선택합니다.

    현재 확신도
    아직 복습 판정을 남기지 않았습니다.
모든 훈련을 마친 뒤 핵심 정답 다시 확인

Falsch. SameSite는 값에 따라 동작한다. Strict는 강하게 제한하지만 Lax는 일부 top-level navigation을 허용하고 None은 cross-site 전송을 허용한다.

3.1 b) HttpOnly cookie는 오직 브라우저의 JavaScript 환경 안에서만 읽을 수 있게 한다. 기존 71문항 학습 번호 38 · 2점 Wahr/Falsch

3.1 b) · 실제 시험 원문

Das HttpOnly-Cookie-Attribut veranlasst, dass ein Cookie nur im Browser innerhalb der JavaScript Umgebung gelesen werden kann.

한국어로 요구사항만 풀어 읽기

HttpOnly cookie는 오직 브라우저의 JavaScript 환경 안에서만 읽을 수 있게 한다.

XSS와 output encoding을 처음부터 이해하기Browser, server, HTTP, HTML parser

TERMS FOR 3.1 b)

이 소문제의 중요한 용어부터 이해하기

전문 용어를 알고 있다고 가정하지 않습니다. 아래 정의의 굵은 용어를 문제 문장 속 같은 단어와 바꾸어 읽은 뒤 풀이로 넘어가세요.

01HttpOnly

Browser가 cookie를 HTTP 요청에는 사용할 수 있게 하되 JavaScript의 document.cookie에서는 읽지 못하게 하는 속성입니다.

작은 예: XSS가 있어도 session cookie 값을 직접 훔치는 난도를 높이지만 XSS 자체를 제거하지는 않습니다.

02XSS

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

03Source

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

04Sink

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

05Output encoding

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

06HTTP request

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

07HTTP response

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

08Parser / Interpreter

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

ZERO-BASE MINI LESSON · 3.1 b)

이 소문제만을 위한 0부터 시작하는 미니 강의

아래 설명은 이 과목의 선행 지식을 가정하지 않습니다. 개념 → 비유의 대응 → 눈으로 읽는 구조 → 작은 예제 순서로 읽은 뒤 실제 시험 풀이로 넘어가세요.

1 · 먼저 알아야 할 개념

브라우저 안에서 cookie는 두 경로로 사용될 수 있습니다. 첫째, 브라우저의 네트워크 기능이 대상 domain과 path에 맞는 cookie를 HTTP(S) 요청의 Cookie header에 자동으로 붙입니다. 둘째, 페이지의 JavaScript가 허용된 cookie를 document.cookie로 읽거나 쓸 수 있습니다.

HttpOnly는 두 번째 경로, 즉 JavaScript의 직접 읽기·쓰기를 막기 위한 cookie 속성입니다. 이름의 뜻은 ‘HTTP 요청에서만 사용하도록 두고 script에는 감춘다’에 가깝습니다. 브라우저는 HttpOnly cookie를 여전히 서버 요청에 자동으로 붙일 수 있습니다.

HttpOnly의 주된 장점은 XSS가 성공해도 공격 script가 session cookie 값을 직접 복사하기 어렵게 만드는 것입니다. 그러나 XSS script가 사용자 권한으로 요청을 보내는 것까지 모두 막는 것은 아니며, HTTPS를 강제하는 Secure나 cross-site 전송을 조절하는 SameSite와 역할도 다릅니다.

2 · 일상 장면으로 먼저 잡기

호텔 직원만 전달할 수 있는 봉인된 객실 카드가 있다고 생각해 봅시다.

  • 봉인된 객실 카드 HttpOnly session cookie
  • 프런트 직원이 요청 때 자동 전달 브라우저가 HTTP(S) 요청 header에 cookie를 자동 첨부
  • 객실 손님이 봉인을 열어 번호를 읽지 못함 JavaScript의 document.cookie 접근 차단
  • 카드를 사용한 서비스 요청은 여전히 가능 XSS가 cookie를 읽지 못해도 same-origin 요청을 보낼 수 있음

비유의 경계 HttpOnly는 운영체제 수준의 비밀 금고가 아닙니다. 브라우저가 요청에 cookie를 쓰는 것은 허용하며, 서버·브라우저 취약점이나 사용자의 인증된 동작 대행까지 전부 해결하지 않습니다.

3 · 눈으로 관계 읽기 HttpOnly cookie의 두 접근 경로
  1. 01 Server

    Set-Cookie: session=ABC; HttpOnly 전달

  2. 02 Cookie jar

    브라우저가 값을 보관

  3. 03 JavaScript

    document.cookie로 session 값을 읽지 못함

  4. 04 HTTP(S) request

    조건이 맞으면 브라우저가 session 값을 자동 첨부

HttpOnly는 script 방향 화살표를 막지만 브라우저의 요청 방향 화살표는 유지합니다.

4 · TOY EXAMPLE

같은 cookie를 JavaScript와 네트워크에서 관찰하기

주어진 것과 목표 서버가 Set-Cookie: session=ABC; HttpOnly; Secure를 보냈고 사용자가 같은 사이트의 /profile을 엽니다.

  1. 01
    페이지 script에서 document.cookie를 확인합니다.

    왜? HttpOnly가 JavaScript 노출 경로를 차단하는지 보기 위해서입니다.

    중간 결과 session=ABC 값은 document.cookie 결과에 나타나지 않습니다.

  2. 02
    브라우저가 HTTPS /profile 요청을 만들게 합니다.

    왜? HttpOnly가 네트워크 전송까지 막는지 구분하기 위해서입니다.

    중간 결과 Domain·Path 조건이 맞으면 브라우저는 Cookie: session=ABC를 자동으로 붙입니다.

  3. 03
    XSS payload가 fetch('/change-email', ...)을 실행한다고 가정합니다.

    왜? HttpOnly의 한계를 확인하기 위해서입니다.

    중간 결과 script가 cookie 값을 읽지는 못해도 브라우저가 인증 cookie를 붙이는 same-origin 요청은 일으킬 수 있습니다.

예제 결론 HttpOnly는 JavaScript 전용 cookie가 아니라 JavaScript에서 감춘 cookie입니다.

실제 시험으로 옮기기 시험 문장은 HttpOnly가 cookie를 JavaScript 환경에서만 읽게 한다고 정반대로 설명했으므로 Falsch입니다.

개념 근거와 더 깊은 설명

시험 문구·배점은 실제 시험 PDF를 따르고, 위 개념 설명은 연결된 강의 자료의 해당 페이지를 기준으로 구성했습니다.

이번 문제는 이 단계로 풀어야 했습니다

먼저 문제에서 직접 주어진 값과 최종적으로 구할 값을 분리합니다. 그다음 각 값·용어·경로를 왜 선택했는지 확인하며, 앞 단계의 중간 결과를 다음 단계의 입력으로 사용합니다.

START HERE

먼저 문제를 식과 조건으로 정리하기

계산을 시작하기 전에 주어진 것구할 것을 분리합니다. 그다음 아래 관계식을 위에서 아래로 사용하면, 숫자가 어디서 왔는지 놓치지 않을 수 있습니다.

강사가 문제의 요구사항을 쉬운 말로 바꾸면

시험 문장이 요구하는 것: HttpOnly cookie는 오직 브라우저의 JavaScript 환경 안에서만 읽을 수 있게 한다.

이 문제의 풀이 전략: 이 소문제에서는 문장의 방향을 확인한다 → HttpOnly 정의를 대입한다 → 요청 전송과 읽기를 분리한다 → 보안 효과의 범위를 적는다 → 판정을 완성한다 순서로 진행합니다. 마지막에는 ‘HttpOnly = HTTP 요청에는 사용 가능, JavaScript 직접 읽기는 불가로 두 칸을 나누어 기억합니다.’라는 교정 기준으로 답을 다시 확인합니다.

문제에서 주어진 정보
  • 실제 시험이 준 상황·문장

    HttpOnly cookie는 오직 브라우저의 JavaScript 환경 안에서만 읽을 수 있게 한다.

  • 이 문항의 첫 출발점

    시험 문장은 ‘오직 JavaScript 환경 안에서 읽을 수 있다’고 주장합니다.

    `JavaScript만 허용`인지 `JavaScript를 차단`인지 방향을 정확히 읽습니다.

최종적으로 구해야 하는 것
  • 마지막에 도달할 답안

    Falsch. HttpOnly는 JavaScript 읽기를 허용하는 것이 아니라 금지합니다.

  • 정답을 지탱하는 이유

    정답은 Falsch입니다. HttpOnly cookie는 `document.cookie` 같은 JavaScript API에서 값을 읽지 못하게 합니다. 반면 브라우저는 Domain·Path·Secure 등의 조건이 맞으면 그 cookie를 HTTP(S) 요청에 자동으로 붙입니다. 즉 시험 문장은 접근 방향을 정확히 뒤집어 놓았습니다.

사용할 공식·판정 관계
  • 이 소문제만의 풀이 사슬

    문장의 방향을 확인한다 → HttpOnly 정의를 대입한다 → 요청 전송과 읽기를 분리한다 → 보안 효과의 범위를 적는다 → 판정을 완성한다

    HttpOnly는 script 방향 화살표를 막지만 브라우저의 요청 방향 화살표는 유지합니다.

  1. 01

    문장의 방향을 확인한다

    구체적으로 시험 문장은 ‘오직 JavaScript 환경 안에서 읽을 수 있다’고 주장합니다.

    여기서 검산 JavaScript만 허용인지 JavaScript를 차단인지 방향을 정확히 읽습니다.

    다음 단계로 여기서 확인한 내용을 다음 ‘HttpOnly 정의를 대입한다’ 단계의 출발점으로 사용합니다.

  2. 02

    HttpOnly 정의를 대입한다

    구체적으로 HttpOnly는 client-side script의 document.cookie 접근을 막습니다.

    여기서 검산 속성 이름을 근거 없이 ‘HTTP를 막는다’고 해석하지 않습니다.

    다음 단계로 여기서 확인한 내용을 다음 ‘요청 전송과 읽기를 분리한다’ 단계의 출발점으로 사용합니다.

  3. 03

    요청 전송과 읽기를 분리한다

    구체적으로 브라우저는 해당 cookie를 적합한 HTTP(S) 요청에 여전히 자동 첨부할 수 있습니다.

    여기서 검산 읽기 차단과 전송 차단을 같은 것으로 쓰지 않았는지 봅니다.

    다음 단계로 여기서 확인한 내용을 다음 ‘보안 효과의 범위를 적는다’ 단계의 출발점으로 사용합니다.

  4. 04

    보안 효과의 범위를 적는다

    구체적으로 XSS가 session 값을 직접 탈취하는 위험은 줄이지만 XSS 자체나 인증된 요청 대행을 완전히 막지 않습니다.

    여기서 검산 HttpOnly를 만능 XSS 방어로 표현하지 않습니다.

    다음 단계로 여기서 확인한 내용을 다음 ‘판정을 완성한다’ 단계의 출발점으로 사용합니다.

  5. 05

    판정을 완성한다

    구체적으로 Falsch. HttpOnly는 JavaScript 읽기를 허용하는 것이 아니라 금지합니다.

    여기서 검산 정반대 정의가 분명하게 드러나는지 확인합니다.

    다음 단계로 앞 단계의 결과를 모아 채점 가능한 최종 답안으로 정리합니다.

정답과 해설

Falsch. HttpOnly는 정반대로 JavaScript의 document.cookie 접근을 막고 HTTP(S) 요청에는 브라우저가 cookie를 붙일 수 있게 한다.

시험 답안 골격

  1. Falsch로 표시한다.
  2. HttpOnly는 정반대로 JavaScript의 document.cookie 접근을 막고 HTTP(S) 요청에는 브라우저가 cookie를 붙일 수 있게 한다.

정답이 이렇게 되는 이유

정답은 Falsch입니다. HttpOnly cookie는 document.cookie 같은 JavaScript API에서 값을 읽지 못하게 합니다. 반면 브라우저는 Domain·Path·Secure 등의 조건이 맞으면 그 cookie를 HTTP(S) 요청에 자동으로 붙입니다. 즉 시험 문장은 접근 방향을 정확히 뒤집어 놓았습니다.

초보자가 가장 자주 뒤집는 지점

잘못된 생각 HttpOnly는 HTTP에서 cookie를 쓰지 못하게 하고 JavaScript에서만 쓰게 한다.

왜 틀렸나 HttpOnly라는 이름을 ‘HTTP 제외’로 잘못 해석한 것입니다. 실제 목적은 script 노출을 줄이는 것입니다.

고쳐 말하면 HttpOnly = HTTP 요청에는 사용 가능, JavaScript 직접 읽기는 불가로 두 칸을 나누어 기억합니다.

한 문제만 더: 개념이 정말 연결됐는지 확인

질문 HttpOnly와 Secure는 각각 무엇을 제한합니까?

정답 HttpOnly는 JavaScript의 직접 cookie 접근을 제한하고, Secure는 cookie의 네트워크 전송을 HTTPS 연결로 제한합니다.

이 문제의 오답 함정

  • HttpOnly를 'JavaScript 전용'으로 뒤집어 외우지 않는다.
ACTIVE RECALL

이 소문제를 점수로 바꾸는 6개의 작은 훈련

해설을 닫은 상태에서 1번부터 수행하세요. 정답을 읽은 직후보다 직접 문제 지도를 만들고 답을 꺼낸 뒤 채점할 때 기억이 더 정확해집니다. 작성 내용과 복습 판정은 이 브라우저에 자동 저장됩니다.

  1. 01 · 30초 문제 지도

    해설을 보지 말고 주어진 정보 → 구할 것 → 사용할 공식·판정 관계를 한 줄씩 복원하세요.

    막힐 때만 첫 단서 열기

    HttpOnly는 정반대로 JavaScript의 document.cookie 접근을 막고 HTTP(S) 요청에는 브라우저가 cookie를 붙일 수 있게 한다.

  2. 02 · 90초 닫힌책 답안

    HttpOnly cookie는 오직 브라우저의 JavaScript 환경 안에서만 읽을 수 있게 한다.

    정답 문장만 말하지 말고 근거·중간값·메시지 흐름 중 이 문항에 필요한 것을 빈 종이에 남기세요.

  3. 03 · 부분점수 자가채점

    작성한 뒤에만 아래 기준을 열고, 실제로 쓴 항목만 체크하세요.

    답안 작성 후 채점 기준 열기

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

    0/2 slots

  4. 04 · 문항별 후속 질문·조건 전이
    • HttpOnly가 XSS 자체를 막는가, 아니면 cookie 탈취 피해를 줄이는가?
    • 원문의 판정을 반대로 만들 수 있는 최소 조건 변경 하나를 제시하고, 바뀐 문장이 정의의 어느 조건을 만족하는지 설명하세요.

    조건 변형: 원문의 강한 표현(예: muss, immer, vollständig)을 조건부 표현으로 하나 고쳐 쓰고, 그 변경 뒤에는 판정이 왜 달라지거나 유지되는지 반례와 함께 설명하세요.

  5. 05 · 대표 오답 복구

    고칠 답안: HttpOnly를 'JavaScript 전용'으로 뒤집어 외우지 않는다.

    복구 힌트: HttpOnly는 정반대로 JavaScript의 document.cookie 접근을 막고 HTTP(S) 요청에는 브라우저가 cookie를 붙일 수 있게 한다.

    오답의 첫 잘못된 전제를 한 줄로 지우고, 올바른 조건과 결론을 두 줄로 다시 쓰세요.

  6. 06 · 확신도 보정·다음 복습 결정

    채점 전 예상과 실제 채점 결과가 달랐는지 확인한 뒤 상태를 남기세요. ‘숙달’은 근거와 중간 과정까지 무힌트로 재현했을 때만 선택합니다.

    현재 확신도
    아직 복습 판정을 남기지 않았습니다.
모든 훈련을 마친 뒤 핵심 정답 다시 확인

Falsch. HttpOnly는 정반대로 JavaScript의 document.cookie 접근을 막고 HTTP(S) 요청에는 브라우저가 cookie를 붙일 수 있게 한다.

3.1 c) parameterized query는 SQL injection에 효과적인 server-side 방어다. 기존 71문항 학습 번호 39 · 2점 Wahr/Falsch

3.1 c) · 실제 시험 원문

Parameterisierte Queries (stored procedures) sind ein effektiver serverseitiger Schutz gegen SQL-Injection.

한국어로 요구사항만 풀어 읽기

parameterized query는 SQL injection에 효과적인 server-side 방어다.

SQL injection과 prepared statement

TERMS FOR 3.1 c)

이 소문제의 중요한 용어부터 이해하기

전문 용어를 알고 있다고 가정하지 않습니다. 아래 정의의 굵은 용어를 문제 문장 속 같은 단어와 바꾸어 읽은 뒤 풀이로 넘어가세요.

01Parameterized Query

SQL 명령 구조와 사용자 값을 분리해서 database에 전달하는 방식입니다.

작은 예: 입력에 작은따옴표가 있어도 SQL 문법이 아니라 하나의 값으로 처리됩니다.

02Stored Procedure

Database server 안에 저장해 이름으로 호출하는 SQL 프로그램입니다. 내부에서 문자열 SQL을 안전하지 않게 만들면 여전히 injection이 생길 수 있습니다.

작은 예: 저장 위치가 server 내부라는 사실만으로 parameterization이 자동 보장되지는 않습니다.

03SQL Injection

사용자 입력이 SQL 데이터가 아니라 SQL 문법으로 해석되어 query 구조를 바꾸는 취약점입니다.

작은 예: 문자열 결합 query에 `' OR 1=1 -- `을 넣으면 조건식과 주석 문법이 생길 수 있습니다.

04SQL query

Database에 조회·삽입·변경 등을 요청하는 SQL 문장입니다.

05Prepared statement

SQL 구조를 먼저 고정하고 사용자 값을 별도 parameter로 전달하는 방식입니다.

06Parameter binding

입력값을 SQL syntax와 분리된 data slot에 연결하는 과정입니다.

ZERO-BASE MINI LESSON · 3.1 c)

이 소문제만을 위한 0부터 시작하는 미니 강의

아래 설명은 이 과목의 선행 지식을 가정하지 않습니다. 개념 → 비유의 대응 → 눈으로 읽는 구조 → 작은 예제 순서로 읽은 뒤 실제 시험 풀이로 넘어가세요.

1 · 먼저 알아야 할 개념

SQL query는 DB가 해석하는 프로그램 문장입니다. 예를 들어 SELECT * FROM users WHERE login = 'alice'에서 SELECT, WHERE, 따옴표는 구조이고 alice는 비교할 데이터입니다. 사용자 입력을 문자열 덧셈으로 query에 넣으면 입력 속 따옴표나 주석 기호가 구조로 재해석될 수 있습니다.

Parameterized query는 SQL template과 사용자 값을 별도로 DB driver에 전달합니다. SELECT ... WHERE login = ?라는 구조를 먼저 준비하고, ? 자리에 들어갈 값을 bind하면 입력에 ' OR 1=1 -- 가 있어도 전체가 한 데이터 값으로 처리됩니다.

방어의 핵심은 ‘stored procedure라는 이름’ 자체가 아니라 parameter binding과 동적 SQL 문자열 결합의 제거입니다. Stored procedure 안에서 다시 입력을 이어 붙여 동적 SQL을 만들면 여전히 injection이 생길 수 있습니다. 시험 문장은 parameterized query라는 올바른 방식을 묻습니다.

2 · 일상 장면으로 먼저 잡기

식당 주문서에서 인쇄된 명령 칸과 손님이 적는 메뉴 칸을 물리적으로 분리하는 장면입니다.

  • 미리 인쇄된 ‘메뉴 하나 가져오기’ 지시 고정된 SQL query template
  • 손님이 채우는 메뉴 이름 칸 bound parameter
  • 메뉴 칸에 ‘가게 문을 열어라’라고 써도 메뉴명으로만 읽음 SQL 문법 문자가 parameter 데이터 안에 머묾
  • 주문서 전체를 손님 문장과 이어 붙임 취약한 string concatenation

비유의 경계 Parameterization은 값 자리에 효과적이지만 table 이름이나 정렬 방향 같은 SQL 식별자를 임의 parameter로 바꿀 수 없는 경우가 있습니다. 그런 구조 선택은 allowlist로 제한해야 합니다.

3 · 눈으로 관계 읽기 문자열 결합과 parameter binding
  1. 01 취약한 입력

    alice' OR 1=1 --

  2. 02 문자열 결합

    입력 일부가 SQL operator와 comment로 재해석

  3. 03 고정 template

    WHERE login = ?로 구조 확정

  4. 04 Bound value

    전체 입력이 하나의 login 문자열로 비교됨

같은 입력도 SQL 문장에 붙이면 코드가 되고 parameter 통로로 보내면 데이터로 남습니다.

4 · TOY EXAMPLE

악성 문자열을 결합 방식과 binding 방식에 넣기

주어진 것과 목표 입력값은 alice' OR 1=1 -- 이고, 목표 query는 login이 일치하는 한 사용자를 찾는 것입니다.

  1. 01
    문자열 결합 방식으로 완성된 SQL을 만듭니다.

    왜? 입력이 어느 parser에서 구조로 변하는지 보기 위해서입니다.

    중간 결과 WHERE login = 'alice' OR 1=1 -- '가 되어 OR 1=1과 comment가 SQL 문법으로 작동할 수 있습니다.

  2. 02
    WHERE login = ? template을 DB에 준비합니다.

    왜? SQL 구조를 사용자 값보다 먼저 확정하기 위해서입니다.

    중간 결과 DB는 placeholder 하나가 값 자리라는 사실을 알고 query 구조를 고정합니다.

  3. 03
    전체 입력을 parameter로 bind합니다.

    왜? driver가 사용자 문자열을 한 값으로 전달하게 하기 위해서입니다.

    중간 결과 DB는 이름이 문자 그대로 alice' OR 1=1 -- 인 사용자를 찾을 뿐, OR--를 명령으로 실행하지 않습니다.

  4. 04
    stored procedure 내부 구현을 점검합니다.

    왜? 저장 프로시저라는 명칭만으로 안전하다는 오해를 피하기 위해서입니다.

    중간 결과 내부에서도 parameter를 사용하면 안전하지만 동적 SQL 결합을 하면 같은 위험이 돌아옵니다.

예제 결론 SQL 구조와 값을 서로 다른 통로로 보내면 입력이 명령으로 승격되지 않습니다.

실제 시험으로 옮기기 Parameterized query가 효과적인 server-side SQL injection 방어라는 시험 문장은 Wahr입니다.

개념 근거와 더 깊은 설명

시험 문구·배점은 실제 시험 PDF를 따르고, 위 개념 설명은 연결된 강의 자료의 해당 페이지를 기준으로 구성했습니다.

  • Vorlesung/10 Web Application Security.pdf p.10, p.12, p.16 · SQL injection 정의·login query 예시·parameterized 방어 연결 개념 강의 열기

이번 문제는 이 단계로 풀어야 했습니다

먼저 문제에서 직접 주어진 값과 최종적으로 구할 값을 분리합니다. 그다음 각 값·용어·경로를 왜 선택했는지 확인하며, 앞 단계의 중간 결과를 다음 단계의 입력으로 사용합니다.

START HERE

먼저 문제를 식과 조건으로 정리하기

계산을 시작하기 전에 주어진 것구할 것을 분리합니다. 그다음 아래 관계식을 위에서 아래로 사용하면, 숫자가 어디서 왔는지 놓치지 않을 수 있습니다.

강사가 문제의 요구사항을 쉬운 말로 바꾸면

시험 문장이 요구하는 것: parameterized query는 SQL injection에 효과적인 server-side 방어다.

이 문제의 풀이 전략: 이 소문제에서는 공격 원인을 정의한다 → Parameterized query의 경계를 확인한다 → 공격 payload를 대입한다 → Stored procedure의 조건을 단다 → 판정을 쓴다 순서로 진행합니다. 마지막에는 ‘안전성의 기준을 명칭이 아니라 placeholder와 bound parameter 사용 여부로 확인합니다.’라는 교정 기준으로 답을 다시 확인합니다.

문제에서 주어진 정보
  • 실제 시험이 준 상황·문장

    parameterized query는 SQL injection에 효과적인 server-side 방어다.

  • 이 문항의 첫 출발점

    SQL injection은 신뢰하지 않는 입력이 SQL 구조와 합쳐져 DB parser가 명령으로 해석할 때 생깁니다.

    단순히 ‘특수문자가 나쁘다’가 아니라 code와 data의 혼합을 원인으로 잡습니다.

최종적으로 구해야 하는 것
  • 마지막에 도달할 답안

    Wahr. 올바르게 parameterized된 query는 효과적인 server-side SQL injection 방어입니다.

  • 정답을 지탱하는 이유

    정답은 Wahr입니다. Prepared/parameterized query는 SQL 구조와 사용자가 제공한 값을 분리합니다. 따라서 공격 문자열 안의 따옴표나 SQL keyword가 query 구조를 바꾸지 못하고 하나의 데이터 값으로 취급됩니다. 다만 stored procedure 내부에서 다시 문자열을 결합한다면 보호가 사라질 수 있습니다.

사용할 공식·판정 관계
  • 이 소문제만의 풀이 사슬

    공격 원인을 정의한다 → Parameterized query의 경계를 확인한다 → 공격 payload를 대입한다 → Stored procedure의 조건을 단다 → 판정을 쓴다

    같은 입력도 SQL 문장에 붙이면 코드가 되고 parameter 통로로 보내면 데이터로 남습니다.

  1. 01

    공격 원인을 정의한다

    구체적으로 SQL injection은 신뢰하지 않는 입력이 SQL 구조와 합쳐져 DB parser가 명령으로 해석할 때 생깁니다.

    여기서 검산 단순히 ‘특수문자가 나쁘다’가 아니라 code와 data의 혼합을 원인으로 잡습니다.

    다음 단계로 여기서 확인한 내용을 다음 ‘Parameterized query의 경계를 확인한다’ 단계의 출발점으로 사용합니다.

  2. 02

    Parameterized query의 경계를 확인한다

    구체적으로 SQL template과 parameter value가 별도로 전달되어 query 구조가 먼저 고정됩니다.

    여기서 검산 escape 문자열 결합과 parameter binding을 같은 것으로 쓰지 않습니다.

    다음 단계로 여기서 확인한 내용을 다음 ‘공격 payload를 대입한다’ 단계의 출발점으로 사용합니다.

  3. 03

    공격 payload를 대입한다

    구체적으로 따옴표·OR·--까지 전부 한 값으로 bind되어 SQL operator가 되지 않습니다.

    여기서 검산 입력이 parser에 도착했을 때 값 타입으로 남는지 확인합니다.

    다음 단계로 여기서 확인한 내용을 다음 ‘Stored procedure의 조건을 단다’ 단계의 출발점으로 사용합니다.

  4. 04

    Stored procedure의 조건을 단다

    구체적으로 Stored procedure도 내부에서 parameter를 안전하게 사용해야 하며 동적 문자열 결합은 피해야 합니다.

    여기서 검산 이름만으로 모든 구현이 안전하다고 과장하지 않습니다.

    다음 단계로 여기서 확인한 내용을 다음 ‘판정을 쓴다’ 단계의 출발점으로 사용합니다.

  5. 05

    판정을 쓴다

    구체적으로 Wahr. 올바르게 parameterized된 query는 효과적인 server-side SQL injection 방어입니다.

    여기서 검산 효과적이라는 말과 절대적·무조건 안전하다는 말을 구분합니다.

    다음 단계로 앞 단계의 결과를 모아 채점 가능한 최종 답안으로 정리합니다.

정답과 해설

Wahr. SQL 구조와 사용자 값을 별도로 전달하면 입력이 SQL 명령으로 재해석되지 않는다. 단순 문자열 연결을 하지 않아야 한다.

시험 답안 골격

  1. Wahr로 표시한다.
  2. SQL 구조와 사용자 값을 별도로 전달하면 입력이 SQL 명령으로 재해석되지 않는다. 단순 문자열 연결을 하지 않아야 한다.

정답이 이렇게 되는 이유

정답은 Wahr입니다. Prepared/parameterized query는 SQL 구조와 사용자가 제공한 값을 분리합니다. 따라서 공격 문자열 안의 따옴표나 SQL keyword가 query 구조를 바꾸지 못하고 하나의 데이터 값으로 취급됩니다. 다만 stored procedure 내부에서 다시 문자열을 결합한다면 보호가 사라질 수 있습니다.

초보자가 가장 자주 뒤집는 지점

잘못된 생각 Stored procedure를 호출하기만 하면 내부 코드가 어떻게 작성됐든 SQL injection이 불가능하다.

왜 틀렸나 Stored procedure도 입력으로 동적 SQL 문자열을 만들 수 있고 그 경우 같은 code/data 혼합이 발생합니다.

고쳐 말하면 안전성의 기준을 명칭이 아니라 placeholder와 bound parameter 사용 여부로 확인합니다.

한 문제만 더: 개념이 정말 연결됐는지 확인

질문 ORDER BY ?로 열 이름까지 자유롭게 안전하게 바꿀 수 없다면 어떤 방식을 써야 합니까?

정답 허용할 열 이름을 서버의 allowlist에서 선택해 고정된 SQL 조각으로 매핑해야 합니다. 사용자 문자열을 그대로 붙이면 안 됩니다.

이 문제의 오답 함정

  • stored procedure라는 이름만으로 안전한 것은 아니며 내부에서도 parameter binding을 해야 한다.
ACTIVE RECALL

이 소문제를 점수로 바꾸는 6개의 작은 훈련

해설을 닫은 상태에서 1번부터 수행하세요. 정답을 읽은 직후보다 직접 문제 지도를 만들고 답을 꺼낸 뒤 채점할 때 기억이 더 정확해집니다. 작성 내용과 복습 판정은 이 브라우저에 자동 저장됩니다.

  1. 01 · 30초 문제 지도

    해설을 보지 말고 주어진 정보 → 구할 것 → 사용할 공식·판정 관계를 한 줄씩 복원하세요.

    막힐 때만 첫 단서 열기

    SQL 구조와 사용자 값을 별도로 전달하면 입력이 SQL 명령으로 재해석되지 않는다. 단순 문자열 연결을 하지 않아야 한다.

  2. 02 · 90초 닫힌책 답안

    parameterized query는 SQL injection에 효과적인 server-side 방어다.

    정답 문장만 말하지 말고 근거·중간값·메시지 흐름 중 이 문항에 필요한 것을 빈 종이에 남기세요.

  3. 03 · 부분점수 자가채점

    작성한 뒤에만 아래 기준을 열고, 실제로 쓴 항목만 체크하세요.

    답안 작성 후 채점 기준 열기

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

    0/2 slots

  4. 04 · 문항별 후속 질문·조건 전이
    • 문자열 연결과 prepared statement의 데이터 흐름 차이는?
    • 원문의 판정을 반대로 만들 수 있는 최소 조건 변경 하나를 제시하고, 바뀐 문장이 정의의 어느 조건을 만족하는지 설명하세요.

    조건 변형: 원문의 강한 표현(예: muss, immer, vollständig)을 조건부 표현으로 하나 고쳐 쓰고, 그 변경 뒤에는 판정이 왜 달라지거나 유지되는지 반례와 함께 설명하세요.

  5. 05 · 대표 오답 복구

    고칠 답안: stored procedure라는 이름만으로 안전한 것은 아니며 내부에서도 parameter binding을 해야 한다.

    복구 힌트: SQL 구조와 사용자 값을 별도로 전달하면 입력이 SQL 명령으로 재해석되지 않는다. 단순 문자열 연결을 하지 않아야 한다.

    오답의 첫 잘못된 전제를 한 줄로 지우고, 올바른 조건과 결론을 두 줄로 다시 쓰세요.

  6. 06 · 확신도 보정·다음 복습 결정

    채점 전 예상과 실제 채점 결과가 달랐는지 확인한 뒤 상태를 남기세요. ‘숙달’은 근거와 중간 과정까지 무힌트로 재현했을 때만 선택합니다.

    현재 확신도
    아직 복습 판정을 남기지 않았습니다.
모든 훈련을 마친 뒤 핵심 정답 다시 확인

Wahr. SQL 구조와 사용자 값을 별도로 전달하면 입력이 SQL 명령으로 재해석되지 않는다. 단순 문자열 연결을 하지 않아야 한다.

3.1 d) SOP는 script가 기본적으로 임의의 다른 domain 데이터를 읽도록 허용한다. 기존 71문항 학습 번호 40 · 2점 Wahr/Falsch

3.1 d) · 실제 시험 원문

Die Same-Origin Policy (SOP) erlaubt es Skripten standardmäßig, Daten von beliebigen anderen Domänen auszulesen.

한국어로 요구사항만 풀어 읽기

SOP는 script가 기본적으로 임의의 다른 domain 데이터를 읽도록 허용한다.

Browser, server, HTTP, HTML parser보안이란 무엇을 지키는 것인가

TERMS FOR 3.1 d)

이 소문제의 중요한 용어부터 이해하기

전문 용어를 알고 있다고 가정하지 않습니다. 아래 정의의 굵은 용어를 문제 문장 속 같은 단어와 바꾸어 읽은 뒤 풀이로 넘어가세요.

01Same-Origin Policy (SOP)

한 origin의 script가 다른 origin의 응답 내용을 마음대로 읽지 못하게 하는 Browser의 기본 격리 규칙입니다.

작은 예: https://a.example의 script가 기본적으로 https://bank.example의 응답 본문을 읽지 못하게 합니다.

02Origin

URL의 scheme, host, port 세 요소로 정해지는 Browser 보안 경계입니다.

작은 예: https://example.com과 http://example.com은 scheme이 달라 다른 origin입니다.

03HTTP request

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

04HTTP response

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

05Parser / Interpreter

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

06Context

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

07Asset

공격자로부터 지키려는 대상입니다. 파일, 비밀번호, 서비스 가용성, 사람의 개인정보가 모두 asset이 될 수 있습니다.

08Confidentiality

허가받지 않은 사람이 내용을 읽지 못하게 하는 기밀성입니다.

ZERO-BASE MINI LESSON · 3.1 d)

이 소문제만을 위한 0부터 시작하는 미니 강의

아래 설명은 이 과목의 선행 지식을 가정하지 않습니다. 개념 → 비유의 대응 → 눈으로 읽는 구조 → 작은 예제 순서로 읽은 뒤 실제 시험 풀이로 넘어가세요.

1 · 먼저 알아야 할 개념

Origin은 일반적으로 scheme://host:port 세 요소로 정해집니다. https://shop.example:443https://api.example:443은 host가 다르므로 다른 origin이고, 같은 host라도 httphttps는 scheme이 달라 다른 origin입니다.

Same-Origin Policy(SOP)는 한 origin의 script가 다른 origin의 민감한 응답 내용을 마음대로 읽지 못하게 하는 브라우저의 기본 격리 규칙입니다. 예를 들어 공격 사이트 script가 사용자의 은행 페이지 응답을 읽어 잔액을 훔치는 것을 기본적으로 차단합니다.

중요한 구분은 ‘요청을 보낼 수 있는가’와 ‘응답 내용을 읽을 수 있는가’입니다. Image, form, link 등으로 cross-origin 요청이 발생할 수는 있지만 SOP 때문에 script가 응답 본문을 읽지 못할 수 있습니다. 서버가 CORS header로 특정 origin을 허용하면 예외적으로 읽기가 가능합니다.

2 · 일상 장면으로 먼저 잡기

아파트마다 우편을 보낼 수는 있지만 다른 집의 우편함을 열어 내용을 읽을 수는 없는 상황입니다.

  • 각 아파트 호수 scheme·host·port로 정한 origin
  • 다른 집에 편지 보내기 cross-origin 요청 발생
  • 다른 집 우편함 내용을 읽지 못함 SOP의 cross-origin response 읽기 제한
  • 집주인이 특정 이웃에게 열쇠 허용 서버가 명시한 CORS 허용

비유의 경계 웹의 세부 규칙은 resource 종류, request 방식, CORS preflight, credential 설정에 따라 다릅니다. ‘요청은 항상 가능하고 읽기만 불가’도 모든 API에 적용되는 절대 문장은 아닙니다.

3 · 눈으로 관계 읽기 Cross-origin fetch의 두 관문
  1. 01 evil.example script

    fetch(bank.example/balance) 호출

  2. 02 Network request

    요청이 은행 서버로 갈 수 있음

  3. 03 Bank response

    응답이 브라우저에 도착

  4. 04 SOP/CORS check

    허용이 없으면 evil script의 본문 읽기 차단

요청 화살표가 존재해도 응답 본문이 공격 script로 넘어가는 화살표는 SOP가 막을 수 있습니다.

4 · TOY EXAMPLE

evil.example script가 bank.example을 읽으려 할 때

주어진 것과 목표 사용자가 https://evil.example을 열었고 그 페이지의 JavaScript가 fetch('https://bank.example/balance')를 실행합니다.

  1. 01
    두 URL의 scheme·host·port를 비교합니다.

    왜? SOP 적용의 기준인 origin이 같은지 결정하기 위해서입니다.

    중간 결과 host가 evil.examplebank.example로 다르므로 cross-origin입니다.

  2. 02
    브라우저가 요청을 만들 가능성과 script 읽기 권한을 나눕니다.

    왜? 네트워크 전송과 응답 노출은 별도 판단이기 때문입니다.

    중간 결과 요청이 서버에 도달할 수 있어도 script가 balance 응답을 읽는 것은 기본적으로 차단됩니다.

  3. 03
    은행 응답의 CORS header를 확인합니다.

    왜? 서버가 명시적으로 읽기 예외를 부여할 수 있기 때문입니다.

    중간 결과 적절한 Access-Control-Allow-Origin 허용이 없다면 공격 script는 응답 본문에 접근하지 못합니다.

  4. 04
    시험 문장의 ‘임의 domain 읽기 허용’과 비교합니다.

    왜? 문장이 SOP의 목적을 반대로 서술했는지 판정하기 위해서입니다.

    중간 결과 SOP는 기본 허용이 아니라 기본 격리이므로 문장은 거짓입니다.

예제 결론 SOP의 중심 질문은 다른 origin으로 패킷이 나가는가가 아니라 다른 origin의 데이터를 script에 공개하는가입니다.

실제 시험으로 옮기기 SOP가 임의의 다른 domain 데이터를 기본적으로 읽도록 허용한다는 주장은 정반대이므로 Falsch입니다.

개념 근거와 더 깊은 설명

시험 문구·배점은 실제 시험 PDF를 따르고, 위 개념 설명은 연결된 강의 자료의 해당 페이지를 기준으로 구성했습니다.

  • Vorlesung/10 Web Application Security.pdf p.11, p.12, p.15 · POST login form과 URL/parameter 처리 연결 개념 강의 열기
  • Vorlesung/02_Grundlagen_Krypto_RMU_v2.pdf p.9 · Alice·Bob·Eve 통신 장면과 기밀성의 기본 등장인물 연결 개념 강의 열기

이번 문제는 이 단계로 풀어야 했습니다

먼저 문제에서 직접 주어진 값과 최종적으로 구할 값을 분리합니다. 그다음 각 값·용어·경로를 왜 선택했는지 확인하며, 앞 단계의 중간 결과를 다음 단계의 입력으로 사용합니다.

START HERE

먼저 문제를 식과 조건으로 정리하기

계산을 시작하기 전에 주어진 것구할 것을 분리합니다. 그다음 아래 관계식을 위에서 아래로 사용하면, 숫자가 어디서 왔는지 놓치지 않을 수 있습니다.

강사가 문제의 요구사항을 쉬운 말로 바꾸면

시험 문장이 요구하는 것: SOP는 script가 기본적으로 임의의 다른 domain 데이터를 읽도록 허용한다.

이 문제의 풀이 전략: 이 소문제에서는 Origin 정의를 떠올린다 → SOP의 보호 대상을 찾는다 → 보내기와 읽기를 분리한다 → CORS 예외를 위치시킨다 → 판정을 마무리한다 순서로 진행합니다. 마지막에는 ‘요청 전송 여부와 응답 노출 여부를 두 줄로 따로 판정합니다.’라는 교정 기준으로 답을 다시 확인합니다.

문제에서 주어진 정보
  • 실제 시험이 준 상황·문장

    SOP는 script가 기본적으로 임의의 다른 domain 데이터를 읽도록 허용한다.

  • 이 문항의 첫 출발점

    Origin은 scheme, host, port 조합입니다.

    Domain 이름만 비교하지 말고 세 요소를 기억합니다.

최종적으로 구해야 하는 것
  • 마지막에 도달할 답안

    Falsch. SOP는 임의 domain 읽기를 허용하는 것이 아니라 기본적으로 제한합니다.

  • 정답을 지탱하는 이유

    정답은 Falsch입니다. SOP는 한 origin의 script가 다른 origin의 response 데이터를 기본적으로 읽지 못하도록 격리합니다. Cross-origin 요청 자체가 발생할 수 있다는 사실과 응답을 JavaScript가 읽을 수 있다는 것은 다릅니다. 명시적인 CORS 허용 같은 예외가 있어야 읽기가 가능할 수 있습니다.

사용할 공식·판정 관계
  • 이 소문제만의 풀이 사슬

    Origin 정의를 떠올린다 → SOP의 보호 대상을 찾는다 → 보내기와 읽기를 분리한다 → CORS 예외를 위치시킨다 → 판정을 마무리한다

    요청 화살표가 존재해도 응답 본문이 공격 script로 넘어가는 화살표는 SOP가 막을 수 있습니다.

  1. 01

    Origin 정의를 떠올린다

    구체적으로 Origin은 scheme, host, port 조합입니다.

    여기서 검산 Domain 이름만 비교하지 말고 세 요소를 기억합니다.

    다음 단계로 여기서 확인한 내용을 다음 ‘SOP의 보호 대상을 찾는다’ 단계의 출발점으로 사용합니다.

  2. 02

    SOP의 보호 대상을 찾는다

    구체적으로 다른 origin의 응답 데이터에 대한 script 접근을 기본적으로 제한합니다.

    여기서 검산 SOP를 서버 firewall이나 네트워크 차단 장치로 설명하지 않습니다.

    다음 단계로 여기서 확인한 내용을 다음 ‘보내기와 읽기를 분리한다’ 단계의 출발점으로 사용합니다.

  3. 03

    보내기와 읽기를 분리한다

    구체적으로 Cross-origin 요청이 발생하는 경우가 있어도 응답을 JavaScript가 읽는 권한은 별도입니다.

    여기서 검산 CSRF가 가능한 이유와 SOP 읽기 제한이 공존할 수 있음을 확인합니다.

    다음 단계로 여기서 확인한 내용을 다음 ‘CORS 예외를 위치시킨다’ 단계의 출발점으로 사용합니다.

  4. 04

    CORS 예외를 위치시킨다

    구체적으로 서버가 허용한 origin에는 CORS를 통해 읽기 권한을 줄 수 있습니다.

    여기서 검산 SOP가 어떤 예외도 없는 절대 봉쇄라고 쓰지 않습니다.

    다음 단계로 여기서 확인한 내용을 다음 ‘판정을 마무리한다’ 단계의 출발점으로 사용합니다.

  5. 05

    판정을 마무리한다

    구체적으로 Falsch. SOP는 임의 domain 읽기를 허용하는 것이 아니라 기본적으로 제한합니다.

    여기서 검산 문장의 방향을 뒤집어 정확한 정의를 썼는지 확인합니다.

    다음 단계로 앞 단계의 결과를 모아 채점 가능한 최종 답안으로 정리합니다.

정답과 해설

Falsch. SOP는 scheme, host, port로 정의되는 origin이 다르면 응답 데이터 읽기를 기본적으로 제한한다.

시험 답안 골격

  1. Falsch로 표시한다.
  2. SOP는 scheme, host, port로 정의되는 origin이 다르면 응답 데이터 읽기를 기본적으로 제한한다.

정답이 이렇게 되는 이유

정답은 Falsch입니다. SOP는 한 origin의 script가 다른 origin의 response 데이터를 기본적으로 읽지 못하도록 격리합니다. Cross-origin 요청 자체가 발생할 수 있다는 사실과 응답을 JavaScript가 읽을 수 있다는 것은 다릅니다. 명시적인 CORS 허용 같은 예외가 있어야 읽기가 가능할 수 있습니다.

초보자가 가장 자주 뒤집는 지점

잘못된 생각 SOP가 있으므로 공격 site는 은행 서버에 어떤 요청도 보낼 수 없다.

왜 틀렸나 SOP의 대표 보호는 response 읽기 제한이며 form·image 등으로 요청이 전송될 수 있는 경우가 있습니다.

고쳐 말하면 요청 전송 여부와 응답 노출 여부를 두 줄로 따로 판정합니다.

한 문제만 더: 개념이 정말 연결됐는지 확인

질문 https://app.examplehttp://app.example은 같은 origin입니까?

정답 아닙니다. host는 같아도 scheme이 HTTPS와 HTTP로 다르므로 다른 origin입니다.

이 문제의 오답 함정

  • 요청 전송 가능 여부와 응답 읽기 가능 여부를 혼동하지 않는다.
ACTIVE RECALL

이 소문제를 점수로 바꾸는 6개의 작은 훈련

해설을 닫은 상태에서 1번부터 수행하세요. 정답을 읽은 직후보다 직접 문제 지도를 만들고 답을 꺼낸 뒤 채점할 때 기억이 더 정확해집니다. 작성 내용과 복습 판정은 이 브라우저에 자동 저장됩니다.

  1. 01 · 30초 문제 지도

    해설을 보지 말고 주어진 정보 → 구할 것 → 사용할 공식·판정 관계를 한 줄씩 복원하세요.

    막힐 때만 첫 단서 열기

    SOP는 scheme, host, port로 정의되는 origin이 다르면 응답 데이터 읽기를 기본적으로 제한한다.

  2. 02 · 90초 닫힌책 답안

    SOP는 script가 기본적으로 임의의 다른 domain 데이터를 읽도록 허용한다.

    정답 문장만 말하지 말고 근거·중간값·메시지 흐름 중 이 문항에 필요한 것을 빈 종이에 남기세요.

  3. 03 · 부분점수 자가채점

    작성한 뒤에만 아래 기준을 열고, 실제로 쓴 항목만 체크하세요.

    답안 작성 후 채점 기준 열기

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

    0/2 slots

  4. 04 · 문항별 후속 질문·조건 전이
    • CORS는 SOP를 없애는가, 서버가 제한적으로 완화하는가?
    • 원문의 판정을 반대로 만들 수 있는 최소 조건 변경 하나를 제시하고, 바뀐 문장이 정의의 어느 조건을 만족하는지 설명하세요.

    조건 변형: 원문의 강한 표현(예: muss, immer, vollständig)을 조건부 표현으로 하나 고쳐 쓰고, 그 변경 뒤에는 판정이 왜 달라지거나 유지되는지 반례와 함께 설명하세요.

  5. 05 · 대표 오답 복구

    고칠 답안: 요청 전송 가능 여부와 응답 읽기 가능 여부를 혼동하지 않는다.

    복구 힌트: SOP는 scheme, host, port로 정의되는 origin이 다르면 응답 데이터 읽기를 기본적으로 제한한다.

    오답의 첫 잘못된 전제를 한 줄로 지우고, 올바른 조건과 결론을 두 줄로 다시 쓰세요.

  6. 06 · 확신도 보정·다음 복습 결정

    채점 전 예상과 실제 채점 결과가 달랐는지 확인한 뒤 상태를 남기세요. ‘숙달’은 근거와 중간 과정까지 무힌트로 재현했을 때만 선택합니다.

    현재 확신도
    아직 복습 판정을 남기지 않았습니다.
모든 훈련을 마친 뒤 핵심 정답 다시 확인

Falsch. SOP는 scheme, host, port로 정의되는 origin이 다르면 응답 데이터 읽기를 기본적으로 제한한다.

3.1 e) SSRF는 server가 내부 resource에 권한 없는 요청을 보내도록 만드는 공격이다. 기존 71문항 학습 번호 41 · 2점 Wahr/Falsch

3.1 e) · 실제 시험 원문

Bei SSRF wird ein Server dazu gebracht, unautorisierte Anfragen an interne Ressourcen zu stellen.

한국어로 요구사항만 풀어 읽기

SSRF는 server가 내부 resource에 권한 없는 요청을 보내도록 만드는 공격이다.

Browser, server, HTTP, HTML parser보안이란 무엇을 지키는 것인가

TERMS FOR 3.1 e)

이 소문제의 중요한 용어부터 이해하기

전문 용어를 알고 있다고 가정하지 않습니다. 아래 정의의 굵은 용어를 문제 문장 속 같은 단어와 바꾸어 읽은 뒤 풀이로 넘어가세요.

01SSRF

공격자가 server를 대신 이용해 내부망이나 제한된 주소로 요청을 보내게 만드는 공격입니다.

작은 예: 외부 사용자가 직접 접근할 수 없는 127.0.0.1 관리 API를 취약한 server가 대신 호출하게 합니다.

02HTTP request

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

03HTTP response

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

04Parser / Interpreter

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

05Context

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

06Asset

공격자로부터 지키려는 대상입니다. 파일, 비밀번호, 서비스 가용성, 사람의 개인정보가 모두 asset이 될 수 있습니다.

07Confidentiality

허가받지 않은 사람이 내용을 읽지 못하게 하는 기밀성입니다.

08Integrity

데이터나 시스템이 허가 없이 바뀌지 않았음을 보장하려는 무결성입니다.

ZERO-BASE MINI LESSON · 3.1 e)

이 소문제만을 위한 0부터 시작하는 미니 강의

아래 설명은 이 과목의 선행 지식을 가정하지 않습니다. 개념 → 비유의 대응 → 눈으로 읽는 구조 → 작은 예제 순서로 읽은 뒤 실제 시험 풀이로 넘어가세요.

1 · 먼저 알아야 할 개념

많은 서버는 사용자가 준 URL을 대신 가져오는 기능을 가집니다. 이미지 미리보기, webhook 검사, PDF 변환, URL preview가 예입니다. 정상 입력이 외부 공개 URL이면 서버가 그 주소로 HTTP 요청을 보냅니다.

SSRF(Server-Side Request Forgery)는 공격자가 이 목적지 URL을 조종해 서버가 원래 허용하지 않은 곳으로 요청하게 만드는 공격입니다. 요청의 실제 발신자는 피해자의 browser가 아니라 취약한 application server입니다.

서버는 외부 사용자보다 내부 network에 더 가까울 수 있습니다. 따라서 공격자는 127.0.0.1의 관리 API, 사설 IP의 내부 service, cloud metadata endpoint처럼 인터넷에서 직접 접근할 수 없는 자원에 서버의 네트워크 위치와 권한을 빌려 접근하려 합니다.

2 · 일상 장면으로 먼저 잡기

외부인은 들어갈 수 없는 회사 내부에서 비서에게 ‘이 문서를 대신 가져와 달라’고 URL 쪽지를 건네는 상황입니다.

  • 외부 방문자 SSRF 공격자
  • 회사 안에서 심부름하는 비서 취약한 웹서버의 URL fetch 기능
  • 직원만 갈 수 있는 내부 자료실 localhost·사설 API·metadata service
  • 목적지를 검사하지 않은 심부름 쪽지 검증되지 않은 사용자 제공 URL

비유의 경계 서버가 내부 자원에 실제로 접근할 수 있는지는 network route, firewall, 인증, 응답 반환 방식에 달려 있습니다. SSRF라는 이름만으로 반드시 데이터 탈취까지 성공하는 것은 아닙니다.

3 · 눈으로 관계 읽기 SSRF의 요청 경로
  1. 01 Attacker input

    url=http://127.0.0.1:8080/admin

  2. 02 Public web server

    사용자 URL을 검증 없이 fetch

  3. 03 Internal resource

    외부에서 닿지 않지만 서버에서는 접근 가능

  4. 04 Leaked response

    내용·상태·시간 차이가 공격자에게 전달

공격자는 내부 자원에 직접 연결하지 않고 공개 서버의 네트워크 위치를 경유합니다.

4 · TOY EXAMPLE

이미지 preview URL이 내부 관리 API로 바뀌는 과정

주어진 것과 목표 사이트는 /preview?url=...의 URL을 서버에서 다운로드해 결과를 사용자에게 보여 줍니다.

  1. 01
    정상 사용자가 url=https://images.example/cat.png를 보냅니다.

    왜? 기능의 원래 data flow를 확인하기 위해서입니다.

    중간 결과 웹서버가 외부 이미지 서버에 요청하고 그림을 반환합니다.

  2. 02
    공격자가 url=http://127.0.0.1:8080/admin으로 바꿉니다.

    왜? 사용자 입력이 fetch 목적지를 완전히 정하는지 시험하기 위해서입니다.

    중간 결과 취약한 서버는 자기 localhost의 관리 endpoint로 요청할 수 있습니다.

  3. 03
    서버가 받은 응답이나 상태 차이를 공격자에게 돌려줍니다.

    왜? 내부 자원 정보가 외부로 새는 경로를 확인하기 위해서입니다.

    중간 결과 공격자는 내부 API 내용 또는 port 존재 여부를 알아낼 수 있습니다.

  4. 04
    발신 주체를 확인합니다.

    왜? SSRF와 CSRF를 구분하기 위해서입니다.

    중간 결과 요청을 보낸 주체는 피해자 browser가 아니라 application server이므로 SSRF입니다.

예제 결론 SSRF는 서버를 내부 네트워크를 향한 요청 대리인으로 악용합니다.

실제 시험으로 옮기기 서버가 내부 resource에 권한 없는 요청을 하도록 만든다는 시험 설명은 SSRF의 핵심이므로 Wahr입니다.

개념 근거와 더 깊은 설명

시험 문구·배점은 실제 시험 PDF를 따르고, 위 개념 설명은 연결된 강의 자료의 해당 페이지를 기준으로 구성했습니다.

  • Vorlesung/10 Web Application Security.pdf p.11, p.12, p.15 · POST login form과 URL/parameter 처리 연결 개념 강의 열기
  • Vorlesung/02_Grundlagen_Krypto_RMU_v2.pdf p.9 · Alice·Bob·Eve 통신 장면과 기밀성의 기본 등장인물 연결 개념 강의 열기

이번 문제는 이 단계로 풀어야 했습니다

먼저 문제에서 직접 주어진 값과 최종적으로 구할 값을 분리합니다. 그다음 각 값·용어·경로를 왜 선택했는지 확인하며, 앞 단계의 중간 결과를 다음 단계의 입력으로 사용합니다.

START HERE

먼저 문제를 식과 조건으로 정리하기

계산을 시작하기 전에 주어진 것구할 것을 분리합니다. 그다음 아래 관계식을 위에서 아래로 사용하면, 숫자가 어디서 왔는지 놓치지 않을 수 있습니다.

강사가 문제의 요구사항을 쉬운 말로 바꾸면

시험 문장이 요구하는 것: SSRF는 server가 내부 resource에 권한 없는 요청을 보내도록 만드는 공격이다.

이 문제의 풀이 전략: 이 소문제에서는 약어의 주체를 확인한다 → 공격자가 통제하는 값을 찾는다 → 서버의 특별한 위치를 연결한다 → 권한 없는 영향을 적는다 → 판정을 쓴다 순서로 진행합니다. 마지막에는 ‘첫 화살표의 실행 주체를 표시합니다: SSRF는 server, CSRF는 victim browser입니다.’라는 교정 기준으로 답을 다시 확인합니다.

문제에서 주어진 정보
  • 실제 시험이 준 상황·문장

    SSRF는 server가 내부 resource에 권한 없는 요청을 보내도록 만드는 공격이다.

  • 이 문항의 첫 출발점

    Server-Side라는 말처럼 실제 요청을 보내는 주체는 서버입니다.

    피해자 browser가 자동 요청하는 CSRF와 섞지 않습니다.

최종적으로 구해야 하는 것
  • 마지막에 도달할 답안

    Wahr. 문장은 SSRF의 전형적인 서버 대리 요청을 정확히 설명합니다.

  • 정답을 지탱하는 이유

    정답은 Wahr입니다. SSRF에서는 공격자가 서버의 URL 요청 기능을 조종해 서버가 localhost, 내부 API, cloud metadata 같은 resource에 대신 요청하게 합니다. 서버의 network 위치나 credential을 빌리기 때문에 외부 공격자가 직접 닿지 못하는 자원도 표적이 될 수 있습니다.

사용할 공식·판정 관계
  • 이 소문제만의 풀이 사슬

    약어의 주체를 확인한다 → 공격자가 통제하는 값을 찾는다 → 서버의 특별한 위치를 연결한다 → 권한 없는 영향을 적는다 → 판정을 쓴다

    공격자는 내부 자원에 직접 연결하지 않고 공개 서버의 네트워크 위치를 경유합니다.

  1. 01

    약어의 주체를 확인한다

    구체적으로 Server-Side라는 말처럼 실제 요청을 보내는 주체는 서버입니다.

    여기서 검산 피해자 browser가 자동 요청하는 CSRF와 섞지 않습니다.

    다음 단계로 여기서 확인한 내용을 다음 ‘공격자가 통제하는 값을 찾는다’ 단계의 출발점으로 사용합니다.

  2. 02

    공격자가 통제하는 값을 찾는다

    구체적으로 URL, hostname, redirect 목적지 등 서버 fetch의 destination을 공격자가 조종합니다.

    여기서 검산 단순히 서버가 외부 API를 호출한다는 정상 동작만 적지 않습니다.

    다음 단계로 여기서 확인한 내용을 다음 ‘서버의 특별한 위치를 연결한다’ 단계의 출발점으로 사용합니다.

  3. 03

    서버의 특별한 위치를 연결한다

    구체적으로 서버는 localhost, private network, metadata endpoint에 접근할 수 있을 수 있습니다.

    여기서 검산 왜 공격자가 자기 컴퓨터로 직접 요청하지 않는지 이유를 설명합니다.

    다음 단계로 여기서 확인한 내용을 다음 ‘권한 없는 영향을 적는다’ 단계의 출발점으로 사용합니다.

  4. 04

    권한 없는 영향을 적는다

    구체적으로 내부 정보 읽기, port 탐색, 내부 API 동작 수행 등이 가능합니다.

    여기서 검산 성공 영향은 서버 권한과 응답 노출에 따라 달라짐을 압니다.

    다음 단계로 여기서 확인한 내용을 다음 ‘판정을 쓴다’ 단계의 출발점으로 사용합니다.

  5. 05

    판정을 쓴다

    구체적으로 Wahr. 문장은 SSRF의 전형적인 서버 대리 요청을 정확히 설명합니다.

    여기서 검산 Wahr와 요청 주체·목적지가 함께 연결됐는지 확인합니다.

    다음 단계로 앞 단계의 결과를 모아 채점 가능한 최종 답안으로 정리합니다.

정답과 해설

Wahr. 공격자가 서버의 URL fetch 기능을 조종해 외부에서 직접 닿지 않는 localhost, metadata service, 내부 API에 서버 대신 요청하게 한다.

시험 답안 골격

  1. Wahr로 표시한다.
  2. 공격자가 서버의 URL fetch 기능을 조종해 외부에서 직접 닿지 않는 localhost, metadata service, 내부 API에 서버 대신 요청하게 한다.

정답이 이렇게 되는 이유

정답은 Wahr입니다. SSRF에서는 공격자가 서버의 URL 요청 기능을 조종해 서버가 localhost, 내부 API, cloud metadata 같은 resource에 대신 요청하게 합니다. 서버의 network 위치나 credential을 빌리기 때문에 외부 공격자가 직접 닿지 못하는 자원도 표적이 될 수 있습니다.

초보자가 가장 자주 뒤집는 지점

잘못된 생각 SSRF와 CSRF는 둘 다 위조 요청이므로 피해자 browser가 요청을 보낸다.

왜 틀렸나 CSRF는 대개 로그인한 사용자의 browser를 이용하지만 SSRF는 취약한 server의 fetch 기능을 이용합니다.

고쳐 말하면 첫 화살표의 실행 주체를 표시합니다: SSRF는 server, CSRF는 victim browser입니다.

한 문제만 더: 개념이 정말 연결됐는지 확인

질문 서버가 사용자 URL을 가져와야 하는 기능에서 SSRF 위험을 줄이기 위한 핵심 원칙 하나는 무엇입니까?

정답 허용할 scheme·host·port를 allowlist로 제한하고 DNS 해석 및 redirect 뒤의 최종 IP까지 검사해 private·loopback·link-local 주소 접근을 차단하는 것입니다.

이 문제의 오답 함정

  • SSRF를 피해자 browser가 요청하는 CSRF와 섞지 않는다.
ACTIVE RECALL

이 소문제를 점수로 바꾸는 6개의 작은 훈련

해설을 닫은 상태에서 1번부터 수행하세요. 정답을 읽은 직후보다 직접 문제 지도를 만들고 답을 꺼낸 뒤 채점할 때 기억이 더 정확해집니다. 작성 내용과 복습 판정은 이 브라우저에 자동 저장됩니다.

  1. 01 · 30초 문제 지도

    해설을 보지 말고 주어진 정보 → 구할 것 → 사용할 공식·판정 관계를 한 줄씩 복원하세요.

    막힐 때만 첫 단서 열기

    공격자가 서버의 URL fetch 기능을 조종해 외부에서 직접 닿지 않는 localhost, metadata service, 내부 API에 서버 대신 요청하게 한다.

  2. 02 · 90초 닫힌책 답안

    SSRF는 server가 내부 resource에 권한 없는 요청을 보내도록 만드는 공격이다.

    정답 문장만 말하지 말고 근거·중간값·메시지 흐름 중 이 문항에 필요한 것을 빈 종이에 남기세요.

  3. 03 · 부분점수 자가채점

    작성한 뒤에만 아래 기준을 열고, 실제로 쓴 항목만 체크하세요.

    답안 작성 후 채점 기준 열기

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

    0/2 slots

  4. 04 · 문항별 후속 질문·조건 전이
    • SSRF에서 공격자가 서버의 네트워크 위치를 악용하는 이유는?
    • 원문의 판정을 반대로 만들 수 있는 최소 조건 변경 하나를 제시하고, 바뀐 문장이 정의의 어느 조건을 만족하는지 설명하세요.

    조건 변형: 원문의 강한 표현(예: muss, immer, vollständig)을 조건부 표현으로 하나 고쳐 쓰고, 그 변경 뒤에는 판정이 왜 달라지거나 유지되는지 반례와 함께 설명하세요.

  5. 05 · 대표 오답 복구

    고칠 답안: SSRF를 피해자 browser가 요청하는 CSRF와 섞지 않는다.

    복구 힌트: 공격자가 서버의 URL fetch 기능을 조종해 외부에서 직접 닿지 않는 localhost, metadata service, 내부 API에 서버 대신 요청하게 한다.

    오답의 첫 잘못된 전제를 한 줄로 지우고, 올바른 조건과 결론을 두 줄로 다시 쓰세요.

  6. 06 · 확신도 보정·다음 복습 결정

    채점 전 예상과 실제 채점 결과가 달랐는지 확인한 뒤 상태를 남기세요. ‘숙달’은 근거와 중간 과정까지 무힌트로 재현했을 때만 선택합니다.

    현재 확신도
    아직 복습 판정을 남기지 않았습니다.
모든 훈련을 마친 뒤 핵심 정답 다시 확인

Wahr. 공격자가 서버의 URL fetch 기능을 조종해 외부에서 직접 닿지 않는 localhost, metadata service, 내부 API에 서버 대신 요청하게 한다.

3.1 f) HSTS는 CSRF를 완전히 막는 장치다. 기존 71문항 학습 번호 42 · 2점 Wahr/Falsch

3.1 f) · 실제 시험 원문

HSTS ist ein Mechanismus, der Cross-Site Request Forgery (CSRF) Angriffe vollständig unterbindet.

한국어로 요구사항만 풀어 읽기

HSTS는 CSRF를 완전히 막는 장치다.

Browser, server, HTTP, HTML parser보안이란 무엇을 지키는 것인가

TERMS FOR 3.1 f)

이 소문제의 중요한 용어부터 이해하기

전문 용어를 알고 있다고 가정하지 않습니다. 아래 정의의 굵은 용어를 문제 문장 속 같은 단어와 바꾸어 읽은 뒤 풀이로 넘어가세요.

01HSTS

Browser가 특정 domain에는 HTTP 대신 HTTPS만 사용하도록 강제하는 정책입니다.

작은 예: HTTP downgrade 위험을 줄이지만 사용자를 대신해 전송되는 CSRF 요청을 판별하지는 않습니다.

02CSRF

로그인된 사용자의 Browser가 공격자 의도대로 대상 site에 요청을 보내게 만드는 공격입니다.

작은 예: 공격 page가 사용자의 bank cookie와 함께 송금 요청을 보내게 유도할 수 있습니다.

03HTTPS / TLS

Browser와 server 사이 전송 내용을 암호화하고 변조를 탐지하며 보통 server를 인증하는 통신 보호입니다.

작은 예: HTTPS는 네트워크 도청을 줄이지만 URL이 browser history나 server log에 남는 문제까지 없애지는 않습니다.

04HTTP request

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

05HTTP response

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

06Parser / Interpreter

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

07Context

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

08Asset

공격자로부터 지키려는 대상입니다. 파일, 비밀번호, 서비스 가용성, 사람의 개인정보가 모두 asset이 될 수 있습니다.

ZERO-BASE MINI LESSON · 3.1 f)

이 소문제만을 위한 0부터 시작하는 미니 강의

아래 설명은 이 과목의 선행 지식을 가정하지 않습니다. 개념 → 비유의 대응 → 눈으로 읽는 구조 → 작은 예제 순서로 읽은 뒤 실제 시험 풀이로 넘어가세요.

1 · 먼저 알아야 할 개념

HTTPS는 HTTP 데이터를 TLS로 암호화하고 상대 서버 인증 및 전송 무결성을 제공합니다. 그러나 사용자가 의도한 요청인지, 다른 사이트가 억지로 만든 요청인지까지 TLS가 판단하지는 않습니다.

HSTS(HTTP Strict Transport Security)는 사이트가 브라우저에게 일정 기간 이 host에는 HTTPS만 사용하라고 알리는 정책입니다. 브라우저는 이후 http:// 링크를 HTTPS로 올리고 잘못된 인증서 연결을 쉽게 우회하지 않도록 해 downgrade·SSL stripping 위험을 줄입니다.

CSRF(Cross-Site Request Forgery)는 로그인한 사용자의 browser가 인증 cookie를 자동으로 붙인다는 성질을 악용해 공격 사이트가 의도하지 않은 상태 변경 요청을 보내게 하는 공격입니다. 직접 방어에는 anti-CSRF token, SameSite cookie, Origin/Referer 검증, 안전한 method 설계 등이 필요합니다.

2 · 일상 장면으로 먼저 잡기

HSTS는 모든 우편을 장갑차로 운송하게 하는 규칙이고, CSRF 방어는 주문서에 본인만 아는 일회용 승인번호를 요구하는 규칙이라고 생각해 봅시다.

  • 장갑차 운송 HTTPS/TLS 전송 보호
  • 항상 장갑차만 쓰라는 주소 규칙 HSTS
  • 남이 작성해 보낸 위조 주문서 CSRF request
  • 일회용 승인번호 확인 anti-CSRF token

비유의 경계 실제 HSTS는 브라우저가 기억하는 host 정책이고 첫 방문·하위 domain 포함 여부·preload 설정 같은 세부 조건이 있습니다. 비유의 장갑차가 요청 내용의 정당성을 심사하는 것은 아닙니다.

3 · 눈으로 관계 읽기 HSTS와 CSRF 방어의 질문
  1. 01 HSTS 질문

    이 host에 HTTPS로 연결했는가?

  2. 02 HSTS 효과

    downgrade·SSL stripping 위험 감소

  3. 03 CSRF 질문

    이 상태 변경을 사용자가 의도했는가?

  4. 04 직접 방어

    token·SameSite·Origin 검사

두 장치는 서로 다른 질문에 답하므로 HSTS만으로 CSRF 판정을 대신할 수 없습니다.

4 · TOY EXAMPLE

HTTPS로 안전하게 전달되는 위조 송금 요청

주어진 것과 목표 사용자는 bank.example에 로그인했고 공격 사이트의 숨은 form이 https://bank.example/transfer로 POST를 보냅니다. 은행은 HSTS를 사용합니다.

  1. 01
    HSTS가 요청 URL에 미치는 효과를 봅니다.

    왜? HSTS의 실제 보호 목표를 먼저 고정하기 위해서입니다.

    중간 결과 브라우저는 은행 연결을 HTTPS로 유지해 전송 중 도청·downgrade 위험을 줄입니다.

  2. 02
    브라우저의 cookie 자동 첨부 여부를 확인합니다.

    왜? CSRF의 인증 근거가 어디서 오는지 보기 위해서입니다.

    중간 결과 cookie 속성 조건이 허용하면 브라우저는 공격자가 만든 요청에도 bank session을 붙일 수 있습니다.

  3. 03
    서버가 anti-CSRF token을 검사하는지 확인합니다.

    왜? 요청이 사용자의 실제 페이지에서 생성됐음을 구분할 장치가 필요하기 때문입니다.

    중간 결과 token 검사가 없다면 요청은 암호화된 채 정확히 서버에 도착하면서도 위조 요청일 수 있습니다.

  4. 04
    HSTS와 CSRF 방어의 목표를 비교합니다.

    왜? 전송 보안과 요청 의도 검증을 분리하기 위해서입니다.

    중간 결과 HSTS는 CSRF를 완전히 차단하지 않으며 별도의 방어가 필요합니다.

예제 결론 암호화된 안전한 통로는 그 통로로 들어온 명령이 사용자의 진짜 의도라는 것을 보장하지 않습니다.

실제 시험으로 옮기기 HSTS가 CSRF를 완전히 막는다는 시험 문장은 서로 다른 보호 목표를 혼동했으므로 Falsch입니다.

개념 근거와 더 깊은 설명

시험 문구·배점은 실제 시험 PDF를 따르고, 위 개념 설명은 연결된 강의 자료의 해당 페이지를 기준으로 구성했습니다.

  • Vorlesung/10 Web Application Security.pdf p.11, p.12, p.15 · POST login form과 URL/parameter 처리 연결 개념 강의 열기
  • Vorlesung/02_Grundlagen_Krypto_RMU_v2.pdf p.9 · Alice·Bob·Eve 통신 장면과 기밀성의 기본 등장인물 연결 개념 강의 열기

이번 문제는 이 단계로 풀어야 했습니다

먼저 문제에서 직접 주어진 값과 최종적으로 구할 값을 분리합니다. 그다음 각 값·용어·경로를 왜 선택했는지 확인하며, 앞 단계의 중간 결과를 다음 단계의 입력으로 사용합니다.

START HERE

먼저 문제를 식과 조건으로 정리하기

계산을 시작하기 전에 주어진 것구할 것을 분리합니다. 그다음 아래 관계식을 위에서 아래로 사용하면, 숫자가 어디서 왔는지 놓치지 않을 수 있습니다.

강사가 문제의 요구사항을 쉬운 말로 바꾸면

시험 문장이 요구하는 것: HSTS는 CSRF를 완전히 막는 장치다.

이 문제의 풀이 전략: 이 소문제에서는 HSTS의 약어와 목적을 적는다 → CSRF의 원인을 적는다 → HTTPS 반례를 만든다 → 직접 방어를 연결한다 → 판정을 쓴다 순서로 진행합니다. 마지막에는 ‘통로 보호와 요청 의도 검증을 각각 HSTS/TLS와 CSRF 방어로 나눕니다.’라는 교정 기준으로 답을 다시 확인합니다.

문제에서 주어진 정보
  • 실제 시험이 준 상황·문장

    HSTS는 CSRF를 완전히 막는 장치다.

  • 이 문항의 첫 출발점

    Strict Transport Security는 해당 host에 HTTPS 사용을 강제하는 browser 정책입니다.

    HSTS를 authentication 또는 request authorization 장치로 부르지 않습니다.

최종적으로 구해야 하는 것
  • 마지막에 도달할 답안

    Falsch. HSTS는 CSRF를 완전히 막지 않습니다.

  • 정답을 지탱하는 이유

    정답은 Falsch입니다. HSTS는 브라우저가 해당 host에 HTTPS만 사용하도록 하여 downgrade와 전송 중 공격 위험을 줄입니다. CSRF는 인증된 browser가 사용자의 의도 없이 유효한 요청을 보내도록 만드는 공격이므로, 위조 요청도 HTTPS를 통해 안전하게 전달될 수 있습니다. Token·SameSite·Origin 검증 같은 별도 방어가 필요합니다.

사용할 공식·판정 관계
  • 이 소문제만의 풀이 사슬

    HSTS의 약어와 목적을 적는다 → CSRF의 원인을 적는다 → HTTPS 반례를 만든다 → 직접 방어를 연결한다 → 판정을 쓴다

    두 장치는 서로 다른 질문에 답하므로 HSTS만으로 CSRF 판정을 대신할 수 없습니다.

  1. 01

    HSTS의 약어와 목적을 적는다

    구체적으로 Strict Transport Security는 해당 host에 HTTPS 사용을 강제하는 browser 정책입니다.

    여기서 검산 HSTS를 authentication 또는 request authorization 장치로 부르지 않습니다.

    다음 단계로 여기서 확인한 내용을 다음 ‘CSRF의 원인을 적는다’ 단계의 출발점으로 사용합니다.

  2. 02

    CSRF의 원인을 적는다

    구체적으로 공격자가 인증된 browser로 의도하지 않은 요청을 보내게 하고 cookie가 자동 첨부되는 점을 악용합니다.

    여기서 검산 전송 중 공격자와 공격 site가 요청을 유도하는 상황을 구분합니다.

    다음 단계로 여기서 확인한 내용을 다음 ‘HTTPS 반례를 만든다’ 단계의 출발점으로 사용합니다.

  3. 03

    HTTPS 반례를 만든다

    구체적으로 위조 요청도 HTTPS로 완전히 암호화되어 서버에 성공적으로 전달될 수 있습니다.

    여기서 검산 기밀성·무결성과 사용자의 의도를 같은 것으로 보지 않습니다.

    다음 단계로 여기서 확인한 내용을 다음 ‘직접 방어를 연결한다’ 단계의 출발점으로 사용합니다.

  4. 04

    직접 방어를 연결한다

    구체적으로 Anti-CSRF token, SameSite, Origin 검증 등이 요청 출처·의도를 확인합니다.

    여기서 검산 HSTS 대신 어떤 종류의 검사가 필요한지 제시합니다.

    다음 단계로 여기서 확인한 내용을 다음 ‘판정을 쓴다’ 단계의 출발점으로 사용합니다.

  5. 05

    판정을 쓴다

    구체적으로 Falsch. HSTS는 CSRF를 완전히 막지 않습니다.

    여기서 검산 vollständig라는 절대 표현까지 반박했는지 확인합니다.

    다음 단계로 앞 단계의 결과를 모아 채점 가능한 최종 답안으로 정리합니다.

정답과 해설

Falsch. HSTS는 browser가 해당 site에 HTTPS만 사용하도록 강제해 downgrade를 줄인다. 사용자의 인증 cookie를 악용한 위조 요청인 CSRF의 직접 방어는 아니다.

시험 답안 골격

  1. Falsch로 표시한다.
  2. HSTS는 browser가 해당 site에 HTTPS만 사용하도록 강제해 downgrade를 줄인다. 사용자의 인증 cookie를 악용한 위조 요청인 CSRF의 직접 방어는 아니다.

정답이 이렇게 되는 이유

정답은 Falsch입니다. HSTS는 브라우저가 해당 host에 HTTPS만 사용하도록 하여 downgrade와 전송 중 공격 위험을 줄입니다. CSRF는 인증된 browser가 사용자의 의도 없이 유효한 요청을 보내도록 만드는 공격이므로, 위조 요청도 HTTPS를 통해 안전하게 전달될 수 있습니다. Token·SameSite·Origin 검증 같은 별도 방어가 필요합니다.

초보자가 가장 자주 뒤집는 지점

잘못된 생각 HTTPS이면 요청이 변조되지 않았으므로 사용자가 직접 만든 정상 요청이다.

왜 틀렸나 TLS는 전송 중 바뀌지 않았음을 보장하지만 요청을 생성하게 한 웹페이지가 신뢰할 수 있는지는 증명하지 않습니다.

고쳐 말하면 통로 보호와 요청 의도 검증을 각각 HSTS/TLS와 CSRF 방어로 나눕니다.

한 문제만 더: 개념이 정말 연결됐는지 확인

질문 HSTS가 적용된 은행에 대한 CSRF POST가 여전히 성공할 수 있는 이유는 무엇입니까?

정답 HSTS는 POST를 HTTPS로 전달할 뿐, 공격 site가 요청을 만들었는지 검사하지 않으며 조건에 따라 session cookie도 자동 첨부될 수 있기 때문입니다.

이 문제의 오답 함정

  • 전송 보안과 요청의 의도·출처 검증을 같은 목표로 보지 않는다.
ACTIVE RECALL

이 소문제를 점수로 바꾸는 6개의 작은 훈련

해설을 닫은 상태에서 1번부터 수행하세요. 정답을 읽은 직후보다 직접 문제 지도를 만들고 답을 꺼낸 뒤 채점할 때 기억이 더 정확해집니다. 작성 내용과 복습 판정은 이 브라우저에 자동 저장됩니다.

  1. 01 · 30초 문제 지도

    해설을 보지 말고 주어진 정보 → 구할 것 → 사용할 공식·판정 관계를 한 줄씩 복원하세요.

    막힐 때만 첫 단서 열기

    HSTS는 browser가 해당 site에 HTTPS만 사용하도록 강제해 downgrade를 줄인다. 사용자의 인증 cookie를 악용한 위조 요청인 CSRF의 직접 방어는 아니다.

  2. 02 · 90초 닫힌책 답안

    HSTS는 CSRF를 완전히 막는 장치다.

    정답 문장만 말하지 말고 근거·중간값·메시지 흐름 중 이 문항에 필요한 것을 빈 종이에 남기세요.

  3. 03 · 부분점수 자가채점

    작성한 뒤에만 아래 기준을 열고, 실제로 쓴 항목만 체크하세요.

    답안 작성 후 채점 기준 열기

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

    0/2 slots

  4. 04 · 문항별 후속 질문·조건 전이
    • CSRF token과 SameSite는 어떤 문제를 겨냥하는가?
    • 원문의 판정을 반대로 만들 수 있는 최소 조건 변경 하나를 제시하고, 바뀐 문장이 정의의 어느 조건을 만족하는지 설명하세요.

    조건 변형: 원문의 강한 표현(예: muss, immer, vollständig)을 조건부 표현으로 하나 고쳐 쓰고, 그 변경 뒤에는 판정이 왜 달라지거나 유지되는지 반례와 함께 설명하세요.

  5. 05 · 대표 오답 복구

    고칠 답안: 전송 보안과 요청의 의도·출처 검증을 같은 목표로 보지 않는다.

    복구 힌트: HSTS는 browser가 해당 site에 HTTPS만 사용하도록 강제해 downgrade를 줄인다. 사용자의 인증 cookie를 악용한 위조 요청인 CSRF의 직접 방어는 아니다.

    오답의 첫 잘못된 전제를 한 줄로 지우고, 올바른 조건과 결론을 두 줄로 다시 쓰세요.

  6. 06 · 확신도 보정·다음 복습 결정

    채점 전 예상과 실제 채점 결과가 달랐는지 확인한 뒤 상태를 남기세요. ‘숙달’은 근거와 중간 과정까지 무힌트로 재현했을 때만 선택합니다.

    현재 확신도
    아직 복습 판정을 남기지 않았습니다.
모든 훈련을 마친 뒤 핵심 정답 다시 확인

Falsch. HSTS는 browser가 해당 site에 HTTPS만 사용하도록 강제해 downgrade를 줄인다. 사용자의 인증 cookie를 악용한 위조 요청인 CSRF의 직접 방어는 아니다.

3.1 g) SRI hash는 CDN에서 읽은 script의 integrity를 확인하는 데 사용된다. 기존 71문항 학습 번호 43 · 2점 Wahr/Falsch

3.1 g) · 실제 시험 원문

Ein SRI Hash wird verwendet, um die Integrität von Skripten zu validieren, die über ein CDN geladen werden.

한국어로 요구사항만 풀어 읽기

SRI hash는 CDN에서 읽은 script의 integrity를 확인하는 데 사용된다.

보안이란 무엇을 지키는 것인가

TERMS FOR 3.1 g)

이 소문제의 중요한 용어부터 이해하기

전문 용어를 알고 있다고 가정하지 않습니다. 아래 정의의 굵은 용어를 문제 문장 속 같은 단어와 바꾸어 읽은 뒤 풀이로 넘어가세요.

01SRI

외부에서 불러온 script나 stylesheet의 hash를 Browser가 비교해 예상한 파일인지 확인하는 기능입니다.

작은 예: CDN 파일이 변조되어 hash가 달라지면 Browser가 해당 resource 사용을 거부합니다.

02CDN

사용자 가까운 여러 server에서 정적 파일을 빠르게 제공하는 분산 전달망입니다.

작은 예: Site가 자신의 server 대신 CDN URL에서 JavaScript library를 불러올 수 있습니다.

03Cryptographic Hash

입력 데이터에서 고정 길이 digest를 계산하는 함수입니다. 수집 전후 hash가 같으면 그 사이 byte가 바뀌지 않았다는 강한 근거가 됩니다.

작은 예: 원본과 forensic image의 SHA-256을 기록하고 비교합니다.

04Asset

공격자로부터 지키려는 대상입니다. 파일, 비밀번호, 서비스 가용성, 사람의 개인정보가 모두 asset이 될 수 있습니다.

05Confidentiality

허가받지 않은 사람이 내용을 읽지 못하게 하는 기밀성입니다.

06Integrity

데이터나 시스템이 허가 없이 바뀌지 않았음을 보장하려는 무결성입니다.

07Availability

정당한 사용자가 필요할 때 서비스와 데이터에 접근할 수 있는 가용성입니다.

ZERO-BASE MINI LESSON · 3.1 g)

이 소문제만을 위한 0부터 시작하는 미니 강의

아래 설명은 이 과목의 선행 지식을 가정하지 않습니다. 개념 → 비유의 대응 → 눈으로 읽는 구조 → 작은 예제 순서로 읽은 뒤 실제 시험 풀이로 넘어가세요.

1 · 먼저 알아야 할 개념

웹페이지는 자기 서버뿐 아니라 CDN(Content Delivery Network)의 JavaScript·CSS를 불러올 수 있습니다. CDN은 빠르고 편리하지만 파일이 변조되거나 잘못 배포되면 방문자의 browser가 공격 code를 실행할 수 있습니다.

Hash function은 파일 내용을 고정 길이 digest로 바꿉니다. 파일 한 bit만 달라져도 보통 전혀 다른 digest가 나오므로, 게시자가 기대한 digest와 다운로드한 파일의 digest를 비교하면 내용 변경 여부를 탐지할 수 있습니다.

SRI(Subresource Integrity)는 HTML의 integrity 속성에 허용된 hash를 기록하는 browser 기능입니다. 브라우저는 resource를 다운로드한 뒤 hash를 계산해 기대값과 일치할 때만 사용합니다. Cross-origin resource에는 적절한 CORS 설정도 관련될 수 있습니다.

2 · 일상 장면으로 먼저 잡기

외부 창고에서 받은 상자의 내용물을 열기 전에 주문서에 적힌 봉인 지문과 비교하는 상황입니다.

  • 외부 창고 CDN
  • 받은 상자 다운로드한 script 파일
  • 주문서의 봉인 지문 HTML integrity 속성의 기대 hash
  • 지문 불일치 시 상자를 사용하지 않음 브라우저가 변조 resource 실행을 거부

비유의 경계 SRI hash와 HTML 페이지 자체가 함께 공격자에 의해 바뀌면 새 악성 파일의 hash로 교체될 수 있습니다. 따라서 HTML을 안전한 HTTPS origin에서 받는 것과 SRI를 함께 사용해야 합니다.

3 · 눈으로 관계 읽기 SRI 검증 파이프라인
  1. 01 HTML

    integrity=sha384-EXPECTED 선언

  2. 02 CDN bytes

    외부 script 다운로드

  3. 03 Browser hash

    받은 byte의 digest 계산·비교

  4. 04 Match

    일치하면 실행

  5. 05 Mismatch

    불일치하면 차단

URL이 같아도 내용 byte가 달라지면 hash 비교에서 걸러집니다.

4 · TOY EXAMPLE

CDN script 한 줄이 변조됐을 때

주어진 것과 목표 페이지에는 <script src="https://cdn.example/lib.js" integrity="sha384-EXPECTED" crossorigin="anonymous"></script>가 있습니다.

  1. 01
    브라우저가 CDN에서 lib.js를 다운로드합니다.

    왜? SRI 검증 대상은 URL 문자열이 아니라 실제 받은 byte이기 때문입니다.

    중간 결과 아직 script를 실행하지 않고 검증할 파일 byte를 확보합니다.

  2. 02
    받은 byte의 SHA-384 digest를 계산합니다.

    왜? HTML 작성자가 고정한 기대값과 같은 방식으로 fingerprint를 만들기 위해서입니다.

    중간 결과 정상 파일이면 EXPECTED와 같은 digest가 나옵니다.

  3. 03
    공격자가 파일에 stealCookies() 한 줄을 추가했다고 가정합니다.

    왜? 내용 변경이 검증 결과에 미치는 영향을 확인하기 위해서입니다.

    중간 결과 새 byte의 digest가 기대 hash와 달라집니다.

  4. 04
    브라우저의 최종 동작을 확인합니다.

    왜? Integrity 검사의 보안 효과를 연결하기 위해서입니다.

    중간 결과 Hash가 일치하지 않으면 브라우저는 해당 subresource 사용·실행을 거부하고 오류를 기록합니다.

예제 결론 SRI는 CDN을 신뢰한다는 말 대신 기대한 정확한 byte인지 browser가 확인하게 합니다.

실제 시험으로 옮기기 CDN script의 integrity 검증에 SRI hash를 사용한다는 문장은 정확하므로 Wahr입니다.

개념 근거와 더 깊은 설명

시험 문구·배점은 실제 시험 PDF를 따르고, 위 개념 설명은 연결된 강의 자료의 해당 페이지를 기준으로 구성했습니다.

  • Vorlesung/02_Grundlagen_Krypto_RMU_v2.pdf p.9 · Alice·Bob·Eve 통신 장면과 기밀성의 기본 등장인물 연결 개념 강의 열기

이번 문제는 이 단계로 풀어야 했습니다

먼저 문제에서 직접 주어진 값과 최종적으로 구할 값을 분리합니다. 그다음 각 값·용어·경로를 왜 선택했는지 확인하며, 앞 단계의 중간 결과를 다음 단계의 입력으로 사용합니다.

START HERE

먼저 문제를 식과 조건으로 정리하기

계산을 시작하기 전에 주어진 것구할 것을 분리합니다. 그다음 아래 관계식을 위에서 아래로 사용하면, 숫자가 어디서 왔는지 놓치지 않을 수 있습니다.

강사가 문제의 요구사항을 쉬운 말로 바꾸면

시험 문장이 요구하는 것: SRI hash는 CDN에서 읽은 script의 integrity를 확인하는 데 사용된다.

이 문제의 풀이 전략: 이 소문제에서는 SRI의 보호 대상을 찾는다 → 기대값의 위치를 확인한다 → 브라우저 동작을 연결한다 → 불일치 결과를 적는다 → 판정을 완성한다 순서로 진행합니다. 마지막에는 ‘HTTPS는 통로, SRI는 특정 resource byte의 기대값 검증이라는 서로 다른 층으로 봅니다.’라는 교정 기준으로 답을 다시 확인합니다.

문제에서 주어진 정보
  • 실제 시험이 준 상황·문장

    SRI hash는 CDN에서 읽은 script의 integrity를 확인하는 데 사용된다.

  • 이 문항의 첫 출발점

    외부에서 불러온 subresource의 내용 무결성을 확인합니다.

    비밀번호 hash나 파일 암호화와 혼동하지 않습니다.

최종적으로 구해야 하는 것
  • 마지막에 도달할 답안

    Wahr. 문장은 SRI의 대표 용도를 정확히 설명합니다.

  • 정답을 지탱하는 이유

    정답은 Wahr입니다. SRI를 사용하면 브라우저가 CDN에서 받은 script의 hash를 HTML `integrity` 속성에 고정된 기대 digest와 비교합니다. 내용이 변조되어 hash가 다르면 resource 실행을 거부할 수 있습니다. 이는 무결성 보호이며 파일을 숨기거나 CDN 장애를 막는 기능은 아닙니다.

사용할 공식·판정 관계
  • 이 소문제만의 풀이 사슬

    SRI의 보호 대상을 찾는다 → 기대값의 위치를 확인한다 → 브라우저 동작을 연결한다 → 불일치 결과를 적는다 → 판정을 완성한다

    URL이 같아도 내용 byte가 달라지면 hash 비교에서 걸러집니다.

  1. 01

    SRI의 보호 대상을 찾는다

    구체적으로 외부에서 불러온 subresource의 내용 무결성을 확인합니다.

    여기서 검산 비밀번호 hash나 파일 암호화와 혼동하지 않습니다.

    다음 단계로 여기서 확인한 내용을 다음 ‘기대값의 위치를 확인한다’ 단계의 출발점으로 사용합니다.

  2. 02

    기대값의 위치를 확인한다

    구체적으로 HTML integrity 속성에 허용된 알고리즘과 digest가 들어갑니다.

    여기서 검산 CDN이 자기 파일과 함께 보내는 값만 믿는 구조로 설명하지 않습니다.

    다음 단계로 여기서 확인한 내용을 다음 ‘브라우저 동작을 연결한다’ 단계의 출발점으로 사용합니다.

  3. 03

    브라우저 동작을 연결한다

    구체적으로 다운로드 byte의 hash를 계산해 기대값과 비교합니다.

    여기서 검산 검증 주체가 browser라는 점을 포함합니다.

    다음 단계로 여기서 확인한 내용을 다음 ‘불일치 결과를 적는다’ 단계의 출발점으로 사용합니다.

  4. 04

    불일치 결과를 적는다

    구체적으로 일치하지 않는 script는 실행하지 않습니다.

    여기서 검산 변조를 탐지한 뒤에도 실행한다고 잘못 쓰지 않습니다.

    다음 단계로 여기서 확인한 내용을 다음 ‘판정을 완성한다’ 단계의 출발점으로 사용합니다.

  5. 05

    판정을 완성한다

    구체적으로 Wahr. 문장은 SRI의 대표 용도를 정확히 설명합니다.

    여기서 검산 SRI가 confidentiality나 availability까지 보장한다고 확장하지 않습니다.

    다음 단계로 앞 단계의 결과를 모아 채점 가능한 최종 답안으로 정리합니다.

정답과 해설

Wahr. 브라우저는 다운로드한 외부 resource의 hash를 HTML integrity 속성의 기대값과 비교해 변조된 파일 실행을 거부할 수 있다.

시험 답안 골격

  1. Wahr로 표시한다.
  2. 브라우저는 다운로드한 외부 resource의 hash를 HTML integrity 속성의 기대값과 비교해 변조된 파일 실행을 거부할 수 있다.

정답이 이렇게 되는 이유

정답은 Wahr입니다. SRI를 사용하면 브라우저가 CDN에서 받은 script의 hash를 HTML integrity 속성에 고정된 기대 digest와 비교합니다. 내용이 변조되어 hash가 다르면 resource 실행을 거부할 수 있습니다. 이는 무결성 보호이며 파일을 숨기거나 CDN 장애를 막는 기능은 아닙니다.

초보자가 가장 자주 뒤집는 지점

잘못된 생각 HTTPS로 CDN에 연결하면 SRI는 필요 없고 CDN 내부의 잘못된 파일도 항상 막힌다.

왜 틀렸나 HTTPS는 전송 상대와 통로를 보호하지만 CDN이 악성·오배포한 byte가 원래 기대한 버전인지까지 비교하지 않습니다.

고쳐 말하면 HTTPS는 통로, SRI는 특정 resource byte의 기대값 검증이라는 서로 다른 층으로 봅니다.

한 문제만 더: 개념이 정말 연결됐는지 확인

질문 CDN script가 정상적으로 새 버전으로 바뀌었는데 HTML의 SRI hash를 갱신하지 않으면 어떻게 됩니까?

정답 새 파일의 hash가 기대값과 달라 브라우저가 실행을 차단합니다. 의도한 업데이트라면 HTML의 integrity 값도 검증 후 갱신해야 합니다.

이 문제의 오답 함정

  • SRI가 CDN을 비밀로 만들거나 availability를 보장한다고 쓰지 않는다.
ACTIVE RECALL

이 소문제를 점수로 바꾸는 6개의 작은 훈련

해설을 닫은 상태에서 1번부터 수행하세요. 정답을 읽은 직후보다 직접 문제 지도를 만들고 답을 꺼낸 뒤 채점할 때 기억이 더 정확해집니다. 작성 내용과 복습 판정은 이 브라우저에 자동 저장됩니다.

  1. 01 · 30초 문제 지도

    해설을 보지 말고 주어진 정보 → 구할 것 → 사용할 공식·판정 관계를 한 줄씩 복원하세요.

    막힐 때만 첫 단서 열기

    브라우저는 다운로드한 외부 resource의 hash를 HTML integrity 속성의 기대값과 비교해 변조된 파일 실행을 거부할 수 있다.

  2. 02 · 90초 닫힌책 답안

    SRI hash는 CDN에서 읽은 script의 integrity를 확인하는 데 사용된다.

    정답 문장만 말하지 말고 근거·중간값·메시지 흐름 중 이 문항에 필요한 것을 빈 종이에 남기세요.

  3. 03 · 부분점수 자가채점

    작성한 뒤에만 아래 기준을 열고, 실제로 쓴 항목만 체크하세요.

    답안 작성 후 채점 기준 열기

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

    0/2 slots

  4. 04 · 문항별 후속 질문·조건 전이
    • SRI의 기대 hash는 어디에 저장되는가?
    • 원문의 판정을 반대로 만들 수 있는 최소 조건 변경 하나를 제시하고, 바뀐 문장이 정의의 어느 조건을 만족하는지 설명하세요.

    조건 변형: 원문의 강한 표현(예: muss, immer, vollständig)을 조건부 표현으로 하나 고쳐 쓰고, 그 변경 뒤에는 판정이 왜 달라지거나 유지되는지 반례와 함께 설명하세요.

  5. 05 · 대표 오답 복구

    고칠 답안: SRI가 CDN을 비밀로 만들거나 availability를 보장한다고 쓰지 않는다.

    복구 힌트: 브라우저는 다운로드한 외부 resource의 hash를 HTML integrity 속성의 기대값과 비교해 변조된 파일 실행을 거부할 수 있다.

    오답의 첫 잘못된 전제를 한 줄로 지우고, 올바른 조건과 결론을 두 줄로 다시 쓰세요.

  6. 06 · 확신도 보정·다음 복습 결정

    채점 전 예상과 실제 채점 결과가 달랐는지 확인한 뒤 상태를 남기세요. ‘숙달’은 근거와 중간 과정까지 무힌트로 재현했을 때만 선택합니다.

    현재 확신도
    아직 복습 판정을 남기지 않았습니다.
모든 훈련을 마친 뒤 핵심 정답 다시 확인

Wahr. 브라우저는 다운로드한 외부 resource의 hash를 HTML integrity 속성의 기대값과 비교해 변조된 파일 실행을 거부할 수 있다.

3.1 h) CSP는 웹페이지가 신뢰할 script, style, data source를 정의한다. 기존 71문항 학습 번호 44 · 2점 Wahr/Falsch

3.1 h) · 실제 시험 원문

Die Content Security Policy (CSP) definiert, welche Skripte, Styles und Datenquellen eine Webseite als vertrauenswürdig eingestuft sind.

한국어로 요구사항만 풀어 읽기

CSP는 웹페이지가 신뢰할 script, style, data source를 정의한다.

XSS와 output encoding을 처음부터 이해하기Browser, server, HTTP, HTML parser

TERMS FOR 3.1 h)

이 소문제의 중요한 용어부터 이해하기

전문 용어를 알고 있다고 가정하지 않습니다. 아래 정의의 굵은 용어를 문제 문장 속 같은 단어와 바꾸어 읽은 뒤 풀이로 넘어가세요.

01Content Security Policy (CSP)

Page가 script, style, image 등을 어느 출처에서 불러오거나 실행할 수 있는지 Browser에 알리는 정책입니다.

작은 예: script-src 'self'는 기본적으로 같은 origin의 script만 허용하도록 제한합니다.

02XSS

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

03Source

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

04Sink

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

05Output encoding

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

06HTTP request

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

07HTTP response

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

08Parser / Interpreter

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

ZERO-BASE MINI LESSON · 3.1 h)

이 소문제만을 위한 0부터 시작하는 미니 강의

아래 설명은 이 과목의 선행 지식을 가정하지 않습니다. 개념 → 비유의 대응 → 눈으로 읽는 구조 → 작은 예제 순서로 읽은 뒤 실제 시험 풀이로 넘어가세요.

1 · 먼저 알아야 할 개념

웹페이지는 HTML뿐 아니라 script, style, image, font, frame, API 연결 등 여러 resource를 사용합니다. 공격자가 HTML에 <script>를 주입하거나 외부 악성 script 주소를 넣으면 browser가 이를 신뢰 사이트의 문맥에서 실행할 수 있습니다.

CSP(Content Security Policy)는 서버의 response header 또는 제한된 경우 HTML meta element로 browser에 resource 허용 정책을 전달합니다. script-src, style-src, img-src, connect-src 같은 directive가 각각 어느 source를 허용할지 정합니다. default-src는 모든 directive의 보편적 기본값이 아니라, 별도 설정이 없을 때 이를 fallback으로 정의한 fetch directive들에 적용됩니다.

예를 들어 script-src 'self' https://cdn.example은 같은 origin과 지정 CDN의 script를 허용할 수 있습니다. Nonce나 hash를 사용하면 허용된 inline script를 더 정밀하게 지정할 수 있습니다. CSP는 XSS 피해를 줄이는 defense-in-depth이며 안전한 context별 output encoding의 대체품은 아닙니다.

2 · 일상 장면으로 먼저 잡기

행사장 입구의 출입 명단에 공연자, 음식 업체, 영상 업체를 종류별로 따로 등록하는 상황입니다.

  • 공연자 허용 명단 script-src
  • 무대 장식 업체 허용 명단 style-src
  • 외부 통신 업체 허용 명단 connect-src
  • 초대장마다 다른 일회용 도장 CSP nonce

비유의 경계 CSP source가 신뢰된다고 해서 그 source의 모든 code가 논리적으로 안전하다는 뜻은 아닙니다. 정책이 너무 넓거나 unsafe-inline을 허용하면 효과가 크게 줄고, application 취약점 자체도 남을 수 있습니다.

3 · 눈으로 관계 읽기 CSP directive와 통제 대상
  1. 01 script-src

    JavaScript source·nonce·hash 허용

  2. 02 style-src

    Stylesheet와 style 실행 source 허용

  3. 03 connect-src

    fetch·XHR·WebSocket 연결 대상 제한

  4. 04 default-src

    별도 설정이 없는 지원 fetch directive의 fallback source

  5. 05 Blocked injection

    허용 조건 없는 resource·inline code 차단

CSP는 모든 콘텐츠를 한 목록으로 뭉치지 않고 resource 종류마다 허용 source를 정할 수 있습니다.

4 · TOY EXAMPLE

주입된 inline script와 지정 CDN script 비교하기

주어진 것과 목표 서버는 Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.good.example 'nonce-R4ND0M'을 보냅니다.

  1. 01
    페이지의 <script src="https://cdn.good.example/app.js">를 검사합니다.

    왜? script-src의 source allowlist와 일치하는지 보기 위해서입니다.

    중간 결과 지정된 CDN이므로 다른 조건도 맞으면 browser가 로드할 수 있습니다.

  2. 02
    공격자가 넣은 <script>alert(1)</script>를 검사합니다.

    왜? Inline script가 자동으로 신뢰되는지 확인하기 위해서입니다.

    중간 결과 허용 nonce가 없으므로 browser가 실행을 차단합니다.

  3. 03
    서버가 만든 <script nonce="R4ND0M">...</script>를 검사합니다.

    왜? Nonce 기반 세밀한 허용 방식을 이해하기 위해서입니다.

    중간 결과 Header의 nonce와 일치하므로 해당 inline script는 실행될 수 있습니다.

  4. 04
    주입된 HTML 자체가 사라졌는지 확인합니다.

    왜? CSP의 방어 범위를 과장하지 않기 위해서입니다.

    중간 결과 취약한 출력은 여전히 존재할 수 있으므로 output encoding을 함께 고쳐야 합니다.

예제 결론 CSP는 browser가 resource 종류별 신뢰 출처와 실행 조건을 검사하게 합니다.

실제 시험으로 옮기기 CSP가 신뢰할 script·style·data source를 정의한다는 시험 문장은 핵심 역할을 올바르게 설명하므로 Wahr입니다.

개념 근거와 더 깊은 설명

시험 문구·배점은 실제 시험 PDF를 따르고, 위 개념 설명은 연결된 강의 자료의 해당 페이지를 기준으로 구성했습니다.

이번 문제는 이 단계로 풀어야 했습니다

먼저 문제에서 직접 주어진 값과 최종적으로 구할 값을 분리합니다. 그다음 각 값·용어·경로를 왜 선택했는지 확인하며, 앞 단계의 중간 결과를 다음 단계의 입력으로 사용합니다.

START HERE

먼저 문제를 식과 조건으로 정리하기

계산을 시작하기 전에 주어진 것구할 것을 분리합니다. 그다음 아래 관계식을 위에서 아래로 사용하면, 숫자가 어디서 왔는지 놓치지 않을 수 있습니다.

강사가 문제의 요구사항을 쉬운 말로 바꾸면

시험 문장이 요구하는 것: CSP는 웹페이지가 신뢰할 script, style, data source를 정의한다.

이 문제의 풀이 전략: 이 소문제에서는 CSP의 실행 주체를 확인한다 → Directive 예를 연결한다 → 신뢰의 의미를 제한한다 → 보조 방어임을 확인한다 → 판정을 적는다 순서로 진행합니다. 마지막에는 ‘Output encoding으로 취약점을 고치고 CSP를 추가 피해 제한층으로 사용합니다.’라는 교정 기준으로 답을 다시 확인합니다.

문제에서 주어진 정보
  • 실제 시험이 준 상황·문장

    CSP는 웹페이지가 신뢰할 script, style, data source를 정의한다.

  • 이 문항의 첫 출발점

    서버가 정책을 전달하고 browser가 resource load·execution 때 적용합니다.

    CSP를 서버-side input sanitizer로 설명하지 않습니다.

최종적으로 구해야 하는 것
  • 마지막에 도달할 답안

    Wahr. 문장은 CSP의 source 제한 역할을 정확히 요약합니다.

  • 정답을 지탱하는 이유

    정답은 Wahr입니다. CSP는 browser가 어떤 source의 script, style, image, frame, network connection 등을 허용할지 directive로 제한합니다. `default-src`는 이를 fallback으로 정의한 fetch directive에만 기본 source를 제공하며 모든 CSP directive를 대신하지는 않습니다. Nonce·hash도 사용할 수 있어 주입된 code의 실행을 줄이는 방어층이 되지만, 취약한 출력을 직접 고치는 output encoding을 대신하지는 않습니다.

사용할 공식·판정 관계
  • 이 소문제만의 풀이 사슬

    CSP의 실행 주체를 확인한다 → Directive 예를 연결한다 → 신뢰의 의미를 제한한다 → 보조 방어임을 확인한다 → 판정을 적는다

    CSP는 모든 콘텐츠를 한 목록으로 뭉치지 않고 resource 종류마다 허용 source를 정할 수 있습니다.

  1. 01

    CSP의 실행 주체를 확인한다

    구체적으로 서버가 정책을 전달하고 browser가 resource load·execution 때 적용합니다.

    여기서 검산 CSP를 서버-side input sanitizer로 설명하지 않습니다.

    다음 단계로 여기서 확인한 내용을 다음 ‘Directive 예를 연결한다’ 단계의 출발점으로 사용합니다.

  2. 02

    Directive 예를 연결한다

    구체적으로 script-src, style-src, connect-src가 각각 script, style, data connection source를 제한합니다.

    여기서 검산 시험 문장의 세 resource 종류가 실제 directive와 대응하는지 봅니다.

    다음 단계로 여기서 확인한 내용을 다음 ‘신뢰의 의미를 제한한다’ 단계의 출발점으로 사용합니다.

  3. 03

    신뢰의 의미를 제한한다

    구체적으로 정책에 허용된 source 또는 nonce/hash 조건을 만족한 resource만 browser가 사용하도록 합니다.

    여기서 검산 허용 source의 code가 본질적으로 무결하다는 보장과 혼동하지 않습니다.

    다음 단계로 여기서 확인한 내용을 다음 ‘보조 방어임을 확인한다’ 단계의 출발점으로 사용합니다.

  4. 04

    보조 방어임을 확인한다

    구체적으로 CSP는 injection 피해를 줄이지만 context-aware output encoding과 안전한 DOM API를 여전히 사용해야 합니다.

    여기서 검산 CSP 하나로 XSS가 절대 불가능하다고 쓰지 않습니다.

    다음 단계로 여기서 확인한 내용을 다음 ‘판정을 적는다’ 단계의 출발점으로 사용합니다.

  5. 05

    판정을 적는다

    구체적으로 Wahr. 문장은 CSP의 source 제한 역할을 정확히 요약합니다.

    여기서 검산 Wahr의 근거로 최소 두 directive를 떠올릴 수 있는지 확인합니다.

    다음 단계로 앞 단계의 결과를 모아 채점 가능한 최종 답안으로 정리합니다.

정답과 해설

Wahr. CSP directive는 브라우저가 어떤 source의 script·style·연결을 허용할지 제한해 injection 피해를 줄이는 방어층이다.

시험 답안 골격

  1. Wahr로 표시한다.
  2. CSP directive는 브라우저가 어떤 source의 script·style·연결을 허용할지 제한해 injection 피해를 줄이는 방어층이다.

정답이 이렇게 되는 이유

정답은 Wahr입니다. CSP는 browser가 어떤 source의 script, style, image, frame, network connection 등을 허용할지 directive로 제한합니다. default-src는 이를 fallback으로 정의한 fetch directive에만 기본 source를 제공하며 모든 CSP directive를 대신하지는 않습니다. Nonce·hash도 사용할 수 있어 주입된 code의 실행을 줄이는 방어층이 되지만, 취약한 출력을 직접 고치는 output encoding을 대신하지는 않습니다.

초보자가 가장 자주 뒤집는 지점

잘못된 생각 CSP가 있으면 사용자 입력을 HTML에 그대로 출력해도 XSS가 완전히 사라진다.

왜 틀렸나 잘못 구성된 정책, 허용된 script gadget, HTML injection 등 우회와 잔여 영향이 있을 수 있고 취약한 data flow 자체는 남습니다.

고쳐 말하면 Output encoding으로 취약점을 고치고 CSP를 추가 피해 제한층으로 사용합니다.

한 문제만 더: 개념이 정말 연결됐는지 확인

질문 script-src 'self'는 어떤 script를 기본적으로 허용합니까?

정답 현재 페이지와 같은 origin에서 불러오는 script를 허용합니다. 이것만으로 inline script가 자동 허용되는 것은 아닙니다.

이 문제의 오답 함정

  • CSP를 안전한 output encoding의 대체품으로 쓰지 않는다.
ACTIVE RECALL

이 소문제를 점수로 바꾸는 6개의 작은 훈련

해설을 닫은 상태에서 1번부터 수행하세요. 정답을 읽은 직후보다 직접 문제 지도를 만들고 답을 꺼낸 뒤 채점할 때 기억이 더 정확해집니다. 작성 내용과 복습 판정은 이 브라우저에 자동 저장됩니다.

  1. 01 · 30초 문제 지도

    해설을 보지 말고 주어진 정보 → 구할 것 → 사용할 공식·판정 관계를 한 줄씩 복원하세요.

    막힐 때만 첫 단서 열기

    CSP directive는 브라우저가 어떤 source의 script·style·연결을 허용할지 제한해 injection 피해를 줄이는 방어층이다.

  2. 02 · 90초 닫힌책 답안

    CSP는 웹페이지가 신뢰할 script, style, data source를 정의한다.

    정답 문장만 말하지 말고 근거·중간값·메시지 흐름 중 이 문항에 필요한 것을 빈 종이에 남기세요.

  3. 03 · 부분점수 자가채점

    작성한 뒤에만 아래 기준을 열고, 실제로 쓴 항목만 체크하세요.

    답안 작성 후 채점 기준 열기

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

    0/2 slots

  4. 04 · 문항별 후속 질문·조건 전이
    • script-src와 default-src의 역할 차이는?
    • 원문의 판정을 반대로 만들 수 있는 최소 조건 변경 하나를 제시하고, 바뀐 문장이 정의의 어느 조건을 만족하는지 설명하세요.

    조건 변형: 원문의 강한 표현(예: muss, immer, vollständig)을 조건부 표현으로 하나 고쳐 쓰고, 그 변경 뒤에는 판정이 왜 달라지거나 유지되는지 반례와 함께 설명하세요.

  5. 05 · 대표 오답 복구

    고칠 답안: CSP를 안전한 output encoding의 대체품으로 쓰지 않는다.

    복구 힌트: CSP directive는 브라우저가 어떤 source의 script·style·연결을 허용할지 제한해 injection 피해를 줄이는 방어층이다.

    오답의 첫 잘못된 전제를 한 줄로 지우고, 올바른 조건과 결론을 두 줄로 다시 쓰세요.

  6. 06 · 확신도 보정·다음 복습 결정

    채점 전 예상과 실제 채점 결과가 달랐는지 확인한 뒤 상태를 남기세요. ‘숙달’은 근거와 중간 과정까지 무힌트로 재현했을 때만 선택합니다.

    현재 확신도
    아직 복습 판정을 남기지 않았습니다.
모든 훈련을 마친 뒤 핵심 정답 다시 확인

Wahr. CSP directive는 브라우저가 어떤 source의 script·style·연결을 허용할지 제한해 injection 피해를 줄이는 방어층이다.

ACTIVE RECALL

이 페이지를 닫기 전 확인

  1. HttpOnly가 막는 동작은?
  2. SOP가 기본적으로 제한하는 것은?
  3. SRI가 검증하는 것은?