3. Websicherheit / Web Security · 실제 시험 Abschnitt 3.4
3.4. Phishing
Phishing의 목표, post-quantum 암호의 한계, subdomain 관리자의 cookie 조건을 시험지 1–3번 순서로 풉니다.
이 페이지는 비슷한 주제를 임의로 다시 묶지 않고 실제 시험지의 Chapter → subsection → 소문제 순서를 그대로 따릅니다.
ACTUAL EXAM · VERBATIM TRANSCRIPT
시험지 원문 1:1 전사
아래 내용은 해설자가 바꿔 쓴 요약이 아닙니다. 실제 시험 전사본의 문장·순서·수치·배점·코드·표를 그대로 두고, Markdown 기호만 읽기 쉬운 제목·표·코드 모양으로 표시했습니다.
3.4. Phishing (8 Punkte)
1. Was ist das Ziel eines Phishingangriffs? (2 Punkte)
2. Kann Phishing mit Post-Quantum-Verschlüsselung von Daten verhindert werden? (2 Punkte)
3. Ein Angreifer ist Mitarbeiter von Mega Corp. und Administrator von weihnachtsfeier2023.mega-corp.com. Unter welchen Umständen kann er / sie die Session-Cookies von Blogbesuchern lesen und was kann er / sie damit machen? (4 Punkte)
# 4. Security Engineering (36 Punkte)
근거: CSS_Altklausur_WiSe_2526.pdf 및 computersystemsicherheit_wise25-26_questions_only.md · Abschnitt 3.4
VISUAL MAP
사람을 속이는 흐름 왼쪽에서 오른쪽으로 읽은 뒤 아래 실제 소문제에서 같은 순서를 반복합니다.- 01 가짜 신뢰 신호
- 02 사용자 행동
- 03 credential·MFA
- 04 session cookie 조건
- 05 account action
FIXED SOLVING METHOD
이 묶음의 고정 풀이 순서
- 공격자가 속이는 사람과 원하는 행동을 구체화합니다.
- 목표 자산이 password, MFA approval, session 중 무엇인지 적습니다.
- 암호화가 보호하는 전송 데이터와 사람의 판단을 분리합니다.
- Cookie의 Domain, Path, Secure, HttpOnly와 origin 조건을 확인합니다.
- 가능한 행위와 여전히 남는 제한을 조건부로 답합니다.
ZERO-BASE CONCEPT LESSONS
이 묶음을 풀기 전에 필요한 개념
카드를 열고 닫는 방식 대신 한 방향으로 이어지는 글로 구성했습니다. 비유 → 용어의 쉬운 뜻 → 실제 작동 → 시험에서의 경계 순서로 천천히 읽으세요.
기초 개념 01
보안이란 무엇을 지키는 것인가
먼저 장면으로 이해해 봅시다. 봉투에 넣어 내용을 가리는 것은 기밀성, 봉인 스티커로 개봉 여부를 확인하는 것은 무결성, 발신인의 도장을 확인하는 것은 진위성, 우체국이 문을 열어 편지를 계속 전달하는 것은 가용성에 가깝다.
이제 전문 용어를 붙이면 다음과 같습니다. Asset은(는) 공격자로부터 지키려는 대상입니다. 파일, 비밀번호, 서비스 가용성, 사람의 개인정보가 모두 asset이 될 수 있습니다. Confidentiality은(는) 허가받지 않은 사람이 내용을 읽지 못하게 하는 기밀성입니다. Integrity은(는) 데이터나 시스템이 허가 없이 바뀌지 않았음을 보장하려는 무결성입니다. Availability은(는) 정당한 사용자가 필요할 때 서비스와 데이터에 접근할 수 있는 가용성입니다.
실제 시스템에서는 이렇게 작동합니다. 컴퓨터 보안은 막연히 ‘안전하게 만들기’가 아니라 지켜야 할 성질을 구분하는 일에서 시작한다. 기밀성(Vertraulichkeit, confidentiality)은 허가받지 않은 사람이 내용을 읽지 못하게 하는 것, 무결성(Integrität, integrity)은 내용이 몰래 바뀌지 않았음을 확인하는 것, 진위성(Authentizität, authenticity)은 상대나 데이터의 출처가 주장과 맞는지 확인하는 것이다. 서비스가 필요할 때 계속 동작하는 성질은 가용성(Verfügbarkeit, availability)이라고 한다.
- 문제에서 숨김, 변조 탐지, 신원 확인, 서비스 중단 중 무엇을 묻는지 찾는다.
- 한 기술이 네 목표를 모두 자동으로 제공한다고 가정하지 않는다.
- 공격자가 무엇을 할 수 있는지와 지켜야 할 목표를 한 문장씩 분리한다.
여기서 넘지 말아야 할 경계: TLS, 암호화, 서명, hash처럼 익숙한 단어가 나오더라도 그 기술이 제공하지 않는 목표까지 확대해서 쓰면 안 된다.
01. 평문·암호문·키 독립 강의 →기초 개념 02
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에 들어가는지가 보안에 매우 중요하다.
- 사용자 입력이 들어오는 source를 찾는다.
- 입력이 출력·DB·명령으로 들어가는 sink를 찾는다.
- 그 sink를 어떤 parser가 어떤 context로 읽는지 확인한다.
- 공격 영향과 context에 맞는 방어를 연결한다.
여기서 넘지 말아야 할 경계: 입력 문자열 자체만 보고 취약점을 이름 붙이지 말고 source에서 sink까지 실제 흐름을 추적한다.
15. HTTP request·GET·POST·TLS 독립 강의 →기초 개념 03
TLS certificate가 확인하는 것과 확인하지 않는 것
먼저 장면으로 이해해 봅시다. 건물 등기와 열쇠가 맞는지는 확인하지만 그 건물 안 가게가 좋은 물건을 파는지까지 보증하는 것은 아닌 것과 같다.
이제 전문 용어를 붙이면 다음과 같습니다. Certificate은(는) domain 이름 같은 identity와 public key를 CA의 signature로 연결한 전자 문서입니다. CA은(는) Certificate Authority로, 정해진 검증 뒤 certificate에 서명하는 신뢰 기관입니다. Certificate chain은(는) server certificate에서 browser가 신뢰하는 root CA까지 이어지는 서명 관계입니다. Hostname verification은(는) 접속한 domain 이름이 certificate에 허용된 이름과 일치하는지 확인하는 절차입니다.
실제 시스템에서는 이렇게 작동합니다. Certificate는 특정 domain name과 public key를 연결하고 Certificate Authority(CA)가 그 연결을 확인했다는 서명된 문서다. Browser는 접속한 domain이 certificate의 이름과 맞는지, 신뢰하는 CA가 서명했는지, 유효 기간과 서명 체인이 맞는지 검사한다. 이것은 현재 연결 상대가 그 domain의 private key를 가졌다는 근거를 주지만 사업자의 정직성이나 상품 품질을 보증하지 않는다.
- URL의 hostname과 certificate의 SAN 이름을 비교한다.
- CA signature와 trust chain을 확인한다.
- Server가 certificate public key에 대응하는 private key를 가졌음을 handshake에서 증명한다.
- Domain control과 사람·회사에 대한 도덕적 신뢰를 구분한다.
여기서 넘지 말아야 할 경계: 사기 사이트도 자신이 통제하는 domain에 대해서는 valid certificate를 받을 수 있다.
13. TLS certificate·Domain validation·CA 독립 강의 →ACTIVE RECALL
이 페이지를 닫기 전 확인
- Phishing의 핵심 공격 대상은 무엇인가요?
- HttpOnly가 있으면 무엇을 직접 할 수 없나요?
- Domain cookie와 host-only cookie의 차이는?
QUESTION-BY-QUESTION COMMENTARY
실제 시험 소문제별 해설
시험지의 번호와 순서를 그대로 유지했습니다. 각 항목을 열어 원문 → 쉬운 개념 설명 → 이번 문제의 단계별 풀이 → 답안 → 함정 순서로 읽으세요.
ACTUAL EXAM SUBSECTION 3.4
3.4. Phishing
3개 학습 항목 · 8점
3.4.1 phishing 공격의 목표는? 기존 71문항 학습 번호 54 · 2점 단답형
3.4.1 · 실제 시험 원문
한국어로 요구사항만 풀어 읽기
phishing 공격의 목표는?
TERMS FOR 3.4.1
이 소문제의 중요한 용어부터 이해하기
전문 용어를 알고 있다고 가정하지 않습니다. 아래 정의의 굵은 용어를 문제 문장 속 같은 단어와 바꾸어 읽은 뒤 풀이로 넘어가세요.
신뢰할 만한 사람이나 service처럼 가장해 사용자의 판단과 행동을 속이는 공격입니다.
작은 예: 가짜 로그인 화면에서 credential을 입력하거나 MFA 승인을 누르게 유도합니다.
공격자로부터 지키려는 대상입니다. 파일, 비밀번호, 서비스 가용성, 사람의 개인정보가 모두 asset이 될 수 있습니다.
허가받지 않은 사람이 내용을 읽지 못하게 하는 기밀성입니다.
데이터나 시스템이 허가 없이 바뀌지 않았음을 보장하려는 무결성입니다.
정당한 사용자가 필요할 때 서비스와 데이터에 접근할 수 있는 가용성입니다.
이 소문제만을 위한 0부터 시작하는 미니 강의
아래 설명은 이 과목의 선행 지식을 가정하지 않습니다. 개념 → 비유의 대응 → 눈으로 읽는 구조 → 작은 예제 순서로 읽은 뒤 실제 시험 풀이로 넘어가세요.
1 · 먼저 알아야 할 개념
Phishing은 암호 알고리즘을 계산으로 깨는 공격이 아니라 사람의 신뢰와 판단을 조작하는 social engineering입니다. 공격자는 은행, 회사 관리자, 배송 업체, 동료처럼 피해자가 믿을 주체의 이름·화면·말투를 흉내 냅니다.
목표는 password, 금융정보, MFA code, recovery code 같은 secret을 피해자가 직접 제출하게 하거나, 송금 승인·악성 attachment 실행·OAuth 권한 부여 같은 공격자에게 유리한 행동을 하게 하는 것입니다.
Phishing은 전달 방식에 따라 email, SMS(smishing), 전화(vishing), QR code, fake website 등으로 나타날 수 있습니다. Malware가 붙을 수도 있지만 phishing과 malware는 같은 뜻이 아닙니다. Malware 없이 가짜 login page만으로도 credential을 훔칠 수 있습니다.
공격 흐름을 이해할 때는
사칭 메시지/화면 → 피해자의 신뢰 → secret 입력 또는 행동 → 공격자 수신·악용의 네 단계로 봅니다. 단순히 spam을 많이 보내는 것이 목표가 아니라 신뢰를 이용해 보호된 자산이나 행동을 얻는 것이 목표입니다.2 · 일상 장면으로 먼저 잡기
금고를 부수는 대신 은행 직원처럼 옷을 입은 사기꾼이 주인에게 ‘점검을 위해 열쇠와 일회용 번호를 주세요’라고 말하는 상황입니다.
비유의 경계 모든 phishing이 즉시 secret 입력을 요구하는 것은 아닙니다. 신뢰 관계 구축, callback 유도, 악성 OAuth consent처럼 여러 단계를 거칠 수 있습니다.
은행·IT팀·동료를 사칭
긴급성·권위·불안을 이용한 link 또는 요청
가짜 sender·page를 진짜로 판단
Password·MFA 입력, 송금, attachment 실행
Credential·권한·금전·malware 실행 획득
공격자는 수학적 암호를 먼저 깨지 않고 사용자의 신뢰 판단을 우회합니다.
가짜 회사 SSO 알림의 목표 추적하기
주어진 것과 목표 직원은 ‘비밀번호가 오늘 만료됩니다’라는 email과
mega-c0rp-login.example링크를 받습니다. Page는 실제 회사 SSO 화면과 매우 비슷합니다.Email의 사칭 대상과 긴급 문구를 찾습니다.
왜? 공격자가 어떤 신뢰와 감정을 이용하는지 확인하기 위해서입니다.
중간 결과 회사 IT팀을 사칭하고 계정 중단에 대한 공포로 빠른 행동을 유도합니다.
표시 이름이 아니라 실제 destination domain을 봅니다.
왜? 눈에 익은 로고와 sender name은 쉽게 복제되지만 domain은 다른 자산이기 때문입니다.
중간 결과
mega-c0rp-login.example은 회사의 실제 domain이 아닌 공격자 endpoint입니다.피해자가 username과 password를 입력한다고 가정합니다.
왜? Phishing의 중간 목표가 secret 제출임을 연결하기 위해서입니다.
중간 결과 HTTPS가 있더라도 입력은 공격자 server에서 plaintext로 처리됩니다.
가짜 page가 MFA code도 요청합니다.
왜? Password 외의 인증 요소도 social engineering 표적이 될 수 있음을 보기 위해서입니다.
중간 결과 공격자는 실시간으로 진짜 site에 code를 전달해 account takeover를 시도할 수 있습니다.
최종 공격 목적을 문장으로 압축합니다.
왜? 시험 답안에서 수단과 목표를 구분하기 위해서입니다.
중간 결과 신뢰 주체를 사칭해 피해자가 credential·MFA를 넘기게 하고 계정 권한을 탈취하는 것입니다.
예제 결론 Phishing의 핵심은 기술적 통로보다 피해자가 공격자를 신뢰하도록 만들어 보호된 정보나 행동을 스스로 제공하게 하는 것입니다.
실제 시험으로 옮기기 2점 답안에는 사칭·기만과 정보 탈취 또는 악성 행동 유도라는 두 요소를 모두 넣습니다.
이번 문제는 이 단계로 풀어야 했습니다
먼저 문제에서 직접 주어진 값과 최종적으로 구할 값을 분리합니다. 그다음 각 값·용어·경로를 왜 선택했는지 확인하며, 앞 단계의 중간 결과를 다음 단계의 입력으로 사용합니다.
먼저 문제를 식과 조건으로 정리하기
계산을 시작하기 전에 주어진 것과 구할 것을 분리합니다. 그다음 아래 관계식을 위에서 아래로 사용하면, 숫자가 어디서 왔는지 놓치지 않을 수 있습니다.
강사가 문제의 요구사항을 쉬운 말로 바꾸면
시험 문장이 요구하는 것: phishing 공격의 목표는?
이 문제의 풀이 전략: 이 소문제에서는 공격 대상을 사람으로 잡는다 → 사칭·기만을 적는다 → 유도할 행동을 적는다 → 공격자의 최종 이익을 연결한다 → 한 문장 답으로 압축한다 순서로 진행합니다. 마지막에는 ‘Phishing의 정의 기준을 매체가 아니라 사칭과 신뢰 기만으로 둡니다.’라는 교정 기준으로 답을 다시 확인합니다.
문제에서 주어진 정보
phishing 공격의 목표는?
Phishing은 social engineering으로 사람의 신뢰와 결정을 공격합니다.
암호문 brute force나 server exploit로 정의하지 않습니다.
최종적으로 구해야 하는 것
신뢰 주체를 사칭해 피해자를 속이고 민감정보 제출 또는 악성 행동을 유도하는 공격이라고 씁니다.
Phishing의 목표는 신뢰할 만한 사람·조직을 사칭해 피해자를 사회공학적으로 속이고 password, 금융정보, MFA code 같은 secret을 넘기거나 송금·악성 file 실행·권한 부여 같은 행동을 하게 만드는 것입니다. 그 결과 공격자는 계정, 데이터, 금전 또는 조직 접근 권한을 얻습니다.
사용할 공식·판정 관계
공격 대상을 사람으로 잡는다 → 사칭·기만을 적는다 → 유도할 행동을 적는다 → 공격자의 최종 이익을 연결한다 → 한 문장 답으로 압축한다
공격자는 수학적 암호를 먼저 깨지 않고 사용자의 신뢰 판단을 우회합니다.
공격 대상을 사람으로 잡는다
구체적으로 Phishing은 social engineering으로 사람의 신뢰와 결정을 공격합니다.
여기서 검산 암호문 brute force나 server exploit로 정의하지 않습니다.
다음 단계로 여기서 확인한 내용을 다음 ‘사칭·기만을 적는다’ 단계의 출발점으로 사용합니다.
사칭·기만을 적는다
구체적으로 신뢰할 조직이나 사람의 identity와 communication을 흉내 냅니다.
여기서 검산 단순 광고 spam과 구분되는 신뢰 악용이 들어갔는지 봅니다.
다음 단계로 여기서 확인한 내용을 다음 ‘유도할 행동을 적는다’ 단계의 출발점으로 사용합니다.
유도할 행동을 적는다
구체적으로 Secret 입력, 악성 link·attachment 실행, 송금·권한 승인 등을 하게 만듭니다.
여기서 검산 정보 읽기만이 아니라 행동 유도도 가능함을 압니다.
다음 단계로 여기서 확인한 내용을 다음 ‘공격자의 최종 이익을 연결한다’ 단계의 출발점으로 사용합니다.
공격자의 최종 이익을 연결한다
구체적으로 Account takeover, 금융 사기, malware 설치, 조직 침투가 가능합니다.
여기서 검산 수단과 최종 목표의 인과 관계가 있는지 봅니다.
다음 단계로 여기서 확인한 내용을 다음 ‘한 문장 답으로 압축한다’ 단계의 출발점으로 사용합니다.
한 문장 답으로 압축한다
구체적으로 신뢰 주체를 사칭해 피해자를 속이고 민감정보 제출 또는 악성 행동을 유도하는 공격이라고 씁니다.
여기서 검산 사칭과 획득 목표 둘 다 남아 있는지 확인합니다.
다음 단계로 앞 단계의 결과를 모아 채점 가능한 최종 답안으로 정리합니다.
정답과 해설
신뢰할 만한 조직·사람을 사칭해 피해자가 password, 금융정보, MFA code를 넘기거나 악성 행동을 하도록 사회공학적으로 속이는 것이다.
시험 답안 골격
정답이 이렇게 되는 이유
Phishing의 목표는 신뢰할 만한 사람·조직을 사칭해 피해자를 사회공학적으로 속이고 password, 금융정보, MFA code 같은 secret을 넘기거나 송금·악성 file 실행·권한 부여 같은 행동을 하게 만드는 것입니다. 그 결과 공격자는 계정, 데이터, 금전 또는 조직 접근 권한을 얻습니다.
초보자가 가장 자주 뒤집는 지점
잘못된 생각 Phishing은 email attachment에 malware가 있을 때만 성립한다.
왜 틀렸나 가짜 login page나 전화만으로도 피해자가 secret을 직접 제공할 수 있으며 malware는 선택적 수단입니다.
고쳐 말하면 Phishing의 정의 기준을 매체가 아니라 사칭과 신뢰 기만으로 둡니다.
한 문제만 더: 개념이 정말 연결됐는지 확인
질문 공격자가 전화로 은행 직원을 사칭해 MFA code를 받아 내면 email이 없어도 phishing 계열입니까?
정답 예. Voice phishing(vishing)으로, 신뢰 주체를 사칭해 secret을 얻는 같은 social-engineering 원리입니다.
이 문제의 오답 함정
이 소문제를 점수로 바꾸는 6개의 작은 훈련
해설을 닫은 상태에서 1번부터 수행하세요. 정답을 읽은 직후보다 직접 문제 지도를 만들고 답을 꺼낸 뒤 채점할 때 기억이 더 정확해집니다. 작성 내용과 복습 판정은 이 브라우저에 자동 저장됩니다.
해설을 보지 말고 주어진 정보 → 구할 것 → 사용할 공식·판정 관계를 한 줄씩 복원하세요.
막힐 때만 첫 단서 열기
암호를 수학으로 깨는 대신 열쇠 주인에게 가짜 안내문을 보여 스스로 열쇠를 건네게 만든다.
phishing 공격의 목표는?
정답 문장만 말하지 말고 근거·중간값·메시지 흐름 중 이 문항에 필요한 것을 빈 종이에 남기세요.
작성한 뒤에만 아래 기준을 열고, 실제로 쓴 항목만 체크하세요.
답안 작성 후 채점 기준 열기
답안 슬롯 자가 점검 — 실제로 말하거나 쓴 항목만 체크하세요.
0/2 slots
조건 변형: 원문의 핵심 조건 하나를 반대로 바꾸고, 기존 정답에서 어느 문장과 근거를 수정해야 하는지 두 문장으로 설명하세요.
고칠 답안: phishing을 malware와 동일어로 정의하지 않는다.
복구 힌트: 암호를 수학으로 깨는 대신 열쇠 주인에게 가짜 안내문을 보여 스스로 열쇠를 건네게 만든다.
오답의 첫 잘못된 전제를 한 줄로 지우고, 올바른 조건과 결론을 두 줄로 다시 쓰세요.
채점 전 예상과 실제 채점 결과가 달랐는지 확인한 뒤 상태를 남기세요. ‘숙달’은 근거와 중간 과정까지 무힌트로 재현했을 때만 선택합니다.
모든 훈련을 마친 뒤 핵심 정답 다시 확인
신뢰할 만한 조직·사람을 사칭해 피해자가 password, 금융정보, MFA code를 넘기거나 악성 행동을 하도록 사회공학적으로 속이는 것이다.
3.4.2 post-quantum encryption으로 phishing을 막을 수 있는가? 기존 71문항 학습 번호 55 · 2점 단답형
3.4.2 · 실제 시험 원문
한국어로 요구사항만 풀어 읽기
post-quantum encryption으로 phishing을 막을 수 있는가?
TERMS FOR 3.4.2
이 소문제의 중요한 용어부터 이해하기
전문 용어를 알고 있다고 가정하지 않습니다. 아래 정의의 굵은 용어를 문제 문장 속 같은 단어와 바꾸어 읽은 뒤 풀이로 넘어가세요.
신뢰할 만한 사람이나 service처럼 가장해 사용자의 판단과 행동을 속이는 공격입니다.
작은 예: 가짜 로그인 화면에서 credential을 입력하거나 MFA 승인을 누르게 유도합니다.
양자 computer 공격에도 견디도록 설계된 암호 알고리즘 분야입니다.
작은 예: 전송 암호를 강화할 수 있지만 사용자가 가짜 화면을 믿는 사회공학 문제를 자동 해결하지는 않습니다.
공격자로부터 지키려는 대상입니다. 파일, 비밀번호, 서비스 가용성, 사람의 개인정보가 모두 asset이 될 수 있습니다.
허가받지 않은 사람이 내용을 읽지 못하게 하는 기밀성입니다.
데이터나 시스템이 허가 없이 바뀌지 않았음을 보장하려는 무결성입니다.
정당한 사용자가 필요할 때 서비스와 데이터에 접근할 수 있는 가용성입니다.
이 소문제만을 위한 0부터 시작하는 미니 강의
아래 설명은 이 과목의 선행 지식을 가정하지 않습니다. 개념 → 비유의 대응 → 눈으로 읽는 구조 → 작은 예제 순서로 읽은 뒤 실제 시험 풀이로 넘어가세요.
1 · 먼저 알아야 할 개념
Post-Quantum Cryptography(PQC)는 충분히 강한 양자 computer가 기존 공개키 암호의 수학 문제를 빠르게 푸는 위험에 대비합니다. Key establishment, public-key encryption, digital signature를 양자 공격에도 견디는 알고리즘으로 바꾸는 것이 중심입니다.
Encryption은 전송 중 제3자가 내용을 읽지 못하게 할 수 있지만, 연결 상대인 endpoint는 서비스를 제공하려면 입력의 plaintext를 처리합니다. 피해자가 공격자 소유 fake site에 password를 입력하면 그 site와의 연결이 강한 PQC로 암호화되어도 공격자 server는 정상 endpoint로서 password를 받습니다.
Phishing의 약점은 알고리즘 강도보다 사용자가 어느 identity와 domain을 신뢰하는지에 있습니다. 더 강한 암호가 가짜 로고, 비슷한 domain, 긴급한 요청을 자동으로 진짜와 구별해 주지는 않습니다.
PQC 기반 서명·인증 기술이 전체 보안 체계의 한 요소로 도움을 줄 수는 있지만 ‘data를 post-quantum 방식으로 암호화한다’는 사실만으로 phishing을 방지하지 못합니다. Domain-bound WebAuthn/passkey 같은 phishing-resistant MFA, 사용자·메일 보호, 정확한 origin 확인이 별도로 필요합니다.
2 · 일상 장면으로 먼저 잡기
세상에서 가장 튼튼한 장갑차가 편지를 운송하지만, 사용자가 수신자 주소를 사기꾼의 집으로 정확히 적어 보내는 상황입니다.
비유의 경계 실제 인증된 암호 프로토콜과 digital signature는 identity 확인에 기여할 수 있습니다. 하지만 사용자가 어떤 domain을 의도했는지와 UI 기만까지 PQC라는 알고리즘 범주 하나가 해결하는 것은 아닙니다.
가짜 회사 page를 진짜로 믿음
Traffic을 quantum-capable eavesdropper에게서 보호
연결 상대이므로 입력 plaintext를 수신
탈취 credential을 공격자가 재사용
사용자가 의도한 identity·origin인지 확인
암호는 중간자를 막을 수 있지만 사용자가 공격자를 endpoint로 선택하면 공격자는 복호화 권한을 가진 수신자입니다.
PQC로 안전하게 연결된 가짜 login page
주어진 것과 목표 공격자는
secure-mega-corp.example에 valid certificate와 post-quantum key exchange를 갖춘 HTTPS site를 운영하고 진짜 회사 SSO 화면을 복제합니다.피해자의 browser가 공격자 site와 PQC session key를 설정합니다.
왜? 암호학적으로 강한 통로가 실제로 성립한 상태에서도 phishing이 가능한지 시험하기 위해서입니다.
중간 결과 Network 중간자는 browser와 공격자 사이 traffic을 읽기 어렵습니다.
Certificate가 증명하는 이름을 확인합니다.
왜? TLS/PQC가 ‘누구’에 대해 인증하는지 정확히 보기 위해서입니다.
중간 결과 Certificate는 공격자 domain
secure-mega-corp.example에 대한 통제만 증명하며 그것이 진짜 회사라는 뜻은 아닙니다.피해자가 화면을 믿고 password를 입력합니다.
왜? Phishing의 인간 대상 기만 단계가 암호 통로 바깥에 있음을 보여 주기 위해서입니다.
중간 결과 Password는 암호화되어 공격자 server에 도착한 뒤 endpoint에서 plaintext로 처리됩니다.
공격자가 진짜 회사 site에 credential을 재사용합니다.
왜? 강한 전송 보호와 account takeover가 동시에 성립할 수 있음을 연결하기 위해서입니다.
중간 결과 PQC를 깨지 않고도 phishing 목표가 달성됩니다.
Origin-bound passkey를 대입합니다.
왜? 실제 phishing-resistant 방어가 무엇을 추가로 검증하는지 비교하기 위해서입니다.
중간 결과 Credential이 진짜 origin에 묶이면 가짜 domain에서 유효한 인증 응답을 만들기 어려워집니다.
예제 결론 PQC는 공격자까지의 통로를 아주 안전하게 만들 수 있지만 그 공격자가 신뢰할 상대인지 대신 판단하지 않습니다.
실제 시험으로 옮기기 2점 답안은 Nein을 먼저 쓰고 PQC의 암호학적 보호 목표와 phishing의 인간·identity 기만을 대비합니다.
이번 문제는 이 단계로 풀어야 했습니다
먼저 문제에서 직접 주어진 값과 최종적으로 구할 값을 분리합니다. 그다음 각 값·용어·경로를 왜 선택했는지 확인하며, 앞 단계의 중간 결과를 다음 단계의 입력으로 사용합니다.
먼저 문제를 식과 조건으로 정리하기
계산을 시작하기 전에 주어진 것과 구할 것을 분리합니다. 그다음 아래 관계식을 위에서 아래로 사용하면, 숫자가 어디서 왔는지 놓치지 않을 수 있습니다.
강사가 문제의 요구사항을 쉬운 말로 바꾸면
시험 문장이 요구하는 것: post-quantum encryption으로 phishing을 막을 수 있는가?
이 문제의 풀이 전략: 이 소문제에서는 명시적으로 Nein을 쓴다 → PQC의 위협 모델을 적는다 → Phishing의 공격 대상을 적는다 → 가짜 endpoint 반례를 든다 → 적절한 별도 방어를 제시한다 순서로 진행합니다. 마지막에는 ‘누가 ciphertext를 훔치는가뿐 아니라 누구를 수신 endpoint로 선택했는지를 확인합니다.’라는 교정 기준으로 답을 다시 확인합니다.
문제에서 주어진 정보
post-quantum encryption으로 phishing을 막을 수 있는가?
Post-quantum encryption만으로 phishing을 방지할 수 없습니다.
조건 없는 긍정으로 시작하지 않습니다.
최종적으로 구해야 하는 것
Origin-bound passkey/WebAuthn, phishing-resistant MFA, domain 확인, filtering·training 등이 필요합니다.
아니요. PQC는 양자 computer가 암호학적 key exchange, encryption, signature를 깨는 위험에 대응합니다. Phishing은 사용자가 가짜 identity나 domain을 믿고 secret을 공격자 endpoint에 직접 입력하게 만드는 문제입니다. 연결이 PQC로 완벽히 암호화돼도 공격자 server는 수신자로서 plaintext를 얻습니다. Origin-bound passkey 같은 별도 phishing-resistant 인증이 필요합니다.
사용할 공식·판정 관계
명시적으로 Nein을 쓴다 → PQC의 위협 모델을 적는다 → Phishing의 공격 대상을 적는다 → 가짜 endpoint 반례를 든다 → 적절한 별도 방어를 제시한다
암호는 중간자를 막을 수 있지만 사용자가 공격자를 endpoint로 선택하면 공격자는 복호화 권한을 가진 수신자입니다.
명시적으로 Nein을 쓴다
구체적으로 Post-quantum encryption만으로 phishing을 방지할 수 없습니다.
여기서 검산 조건 없는 긍정으로 시작하지 않습니다.
다음 단계로 여기서 확인한 내용을 다음 ‘PQC의 위협 모델을 적는다’ 단계의 출발점으로 사용합니다.
PQC의 위협 모델을 적는다
구체적으로 Quantum 공격에도 key exchange·encryption·signature의 수학적 안전성을 유지하려 합니다.
여기서 검산 PQC를 사용자 교육이나 spam filter로 설명하지 않습니다.
다음 단계로 여기서 확인한 내용을 다음 ‘Phishing의 공격 대상을 적는다’ 단계의 출발점으로 사용합니다.
Phishing의 공격 대상을 적는다
구체적으로 가짜 identity·domain·UI로 사람의 신뢰 판단을 속입니다.
여기서 검산 암호문을 계산해 깨는 공격과 구분합니다.
다음 단계로 여기서 확인한 내용을 다음 ‘가짜 endpoint 반례를 든다’ 단계의 출발점으로 사용합니다.
가짜 endpoint 반례를 든다
구체적으로 피해자가 공격자 site에 secret을 입력하면 PQC 통로를 통해 공격자에게 안전하게 전달됩니다.
여기서 검산 Endpoint가 plaintext를 받는다는 점을 포함합니다.
다음 단계로 여기서 확인한 내용을 다음 ‘적절한 별도 방어를 제시한다’ 단계의 출발점으로 사용합니다.
적절한 별도 방어를 제시한다
구체적으로 Origin-bound passkey/WebAuthn, phishing-resistant MFA, domain 확인, filtering·training 등이 필요합니다.
여기서 검산 PQC가 아무 보안 가치도 없다고 반대로 과장하지 않습니다.
다음 단계로 앞 단계의 결과를 모아 채점 가능한 최종 답안으로 정리합니다.
정답과 해설
아니다. post-quantum cryptography는 양자 공격에도 암호학적 기밀성·서명 안전성을 유지하려는 기술이다. 사람이 가짜 사이트를 믿고 secret을 입력하는 사회공학 문제를 자동으로 막지 못한다.
시험 답안 골격
정답이 이렇게 되는 이유
아니요. PQC는 양자 computer가 암호학적 key exchange, encryption, signature를 깨는 위험에 대응합니다. Phishing은 사용자가 가짜 identity나 domain을 믿고 secret을 공격자 endpoint에 직접 입력하게 만드는 문제입니다. 연결이 PQC로 완벽히 암호화돼도 공격자 server는 수신자로서 plaintext를 얻습니다. Origin-bound passkey 같은 별도 phishing-resistant 인증이 필요합니다.
초보자가 가장 자주 뒤집는 지점
잘못된 생각 암호화가 강하면 password는 누구에게도 plaintext로 보이지 않으므로 fake site 운영자도 읽지 못한다.
왜 틀렸나 암호화는 전송 중 제3자를 막지만 정당한 연결 endpoint는 서비스를 위해 데이터를 복호화합니다. Fake site에서는 그 endpoint가 공격자입니다.
고쳐 말하면 누가 ciphertext를 훔치는가뿐 아니라 누구를 수신 endpoint로 선택했는지를 확인합니다.
한 문제만 더: 개념이 정말 연결됐는지 확인
질문 가짜 domain도 자기 domain에 대한 valid TLS certificate를 받을 수 있습니까?
정답 예. Certificate는 그 domain 통제를 증명할 뿐 이름이 진짜 은행·회사인지 보증하지 않습니다. 사용자가 실제 의도한 domain과 비교해야 합니다.
이 문제의 오답 함정
이 소문제를 점수로 바꾸는 6개의 작은 훈련
해설을 닫은 상태에서 1번부터 수행하세요. 정답을 읽은 직후보다 직접 문제 지도를 만들고 답을 꺼낸 뒤 채점할 때 기억이 더 정확해집니다. 작성 내용과 복습 판정은 이 브라우저에 자동 저장됩니다.
해설을 보지 말고 주어진 정보 → 구할 것 → 사용할 공식·판정 관계를 한 줄씩 복원하세요.
막힐 때만 첫 단서 열기
더 강한 금고를 만들어도 사용자가 사기꾼에게 비밀번호와 열쇠를 직접 건네면 해결되지 않는다.
post-quantum encryption으로 phishing을 막을 수 있는가?
정답 문장만 말하지 말고 근거·중간값·메시지 흐름 중 이 문항에 필요한 것을 빈 종이에 남기세요.
작성한 뒤에만 아래 기준을 열고, 실제로 쓴 항목만 체크하세요.
답안 작성 후 채점 기준 열기
답안 슬롯 자가 점검 — 실제로 말하거나 쓴 항목만 체크하세요.
0/2 slots
조건 변형: 원문의 핵심 조건 하나를 반대로 바꾸고, 기존 정답에서 어느 문장과 근거를 수정해야 하는지 두 문장으로 설명하세요.
고칠 답안: 암호 강도와 사용자 인증·신뢰 판단을 섞지 않는다.
복구 힌트: 더 강한 금고를 만들어도 사용자가 사기꾼에게 비밀번호와 열쇠를 직접 건네면 해결되지 않는다.
오답의 첫 잘못된 전제를 한 줄로 지우고, 올바른 조건과 결론을 두 줄로 다시 쓰세요.
채점 전 예상과 실제 채점 결과가 달랐는지 확인한 뒤 상태를 남기세요. ‘숙달’은 근거와 중간 과정까지 무힌트로 재현했을 때만 선택합니다.
모든 훈련을 마친 뒤 핵심 정답 다시 확인
아니다. post-quantum cryptography는 양자 공격에도 암호학적 기밀성·서명 안전성을 유지하려는 기술이다. 사람이 가짜 사이트를 믿고 secret을 입력하는 사회공학 문제를 자동으로 막지 못한다.
3.4.3 하위 domain 관리자가 언제 blog 방문자의 session cookie를 읽을 수 있고 무엇을 할 수 있는가? 기존 71문항 학습 번호 56 · 4점 Web 감사
3.4.3 · 실제 시험 원문
한국어로 요구사항만 풀어 읽기
하위 domain 관리자가 언제 blog 방문자의 session cookie를 읽을 수 있고 무엇을 할 수 있는가?
TERMS FOR 3.4.3
이 소문제의 중요한 용어부터 이해하기
전문 용어를 알고 있다고 가정하지 않습니다. 아래 정의의 굵은 용어를 문제 문장 속 같은 단어와 바꾸어 읽은 뒤 풀이로 넘어가세요.
로그인된 사용자의 session을 식별하도록 Browser가 server에 보내는 cookie입니다.
작은 예: 유효한 session cookie를 탈취하면 password 없이도 사용자의 session으로 요청할 수 있습니다.
상위 domain 아래에 있는 하위 이름입니다.
작은 예: blog.mega-corp.com과 shop.mega-corp.com은 mega-corp.com 아래의 서로 다른 subdomain입니다.
공격자 입력이 victim browser에서 data가 아니라 HTML 또는 JavaScript code로 실행되는 취약점입니다.
공격자 입력이 들어오는 URL, form, database record 같은 시작점입니다.
입력이 HTML이나 script로 해석될 수 있는 위험한 사용 지점입니다.
출력 context에서 특수문자가 code 문법이 아니라 data로 표현되도록 변환하는 방어입니다.
Browser나 client가 server에 method, path, headers, body를 담아 보내는 message입니다.
Server가 status, headers, body를 담아 client에 돌려주는 message입니다.
이 소문제만을 위한 0부터 시작하는 미니 강의
아래 설명은 이 과목의 선행 지식을 가정하지 않습니다. 개념 → 비유의 대응 → 눈으로 읽는 구조 → 작은 예제 순서로 읽은 뒤 실제 시험 풀이로 넘어가세요.
1 · 먼저 알아야 할 개념
Cookie에는 어느 host로 보낼지를 정하는 scope가 있습니다. Server가
Domain속성 없이 cookie를 설정하면 host-only cookie가 되어 그 cookie를 설정한 정확한 host에만 전송됩니다. 반대로Domain=mega-corp.com을 지정하면blog.mega-corp.com뿐 아니라weihnachtsfeier2023.mega-corp.com처럼 domain-match하는 하위 host에도 전송될 수 있습니다.시험의 공격자는
weihnachtsfeier2023.mega-corp.comserver를 관리합니다. Blog 방문자가 이 공격자 host의 page를 열고 blog session cookie가 상위mega-corp.com범위이며 request path가 cookie Path와 일치하면 browser는 cookie를 공격자 server 요청 header에 붙일 수 있습니다. Cookie가Secure이면 공격자 page도 HTTPS여야 전송됩니다.HttpOnly는 JavaScript의document.cookie읽기를 막지만 cookie가 scope에 맞는 host로 HTTP(S) 전송되는 것을 막지 않습니다. 따라서 공격자가 subdomain의 server administrator라면 Domain·Path·Secure 조건이 맞아 자기 server가 받은Cookieheader에서 값을 볼 수 있고, 이 server-side 수신 경로에서는 HttpOnly여도 안전하지 않습니다. 오직 client-side JavaScript로 직접 읽는 경로에는 ‘HttpOnly가 아님’이 추가 조건입니다.SameSite는 이 sibling-subdomain 문제의 직접 해결책이 아닙니다. 같은 scheme의 두 subdomain은 보통 같은 site로 취급되고, Domain cookie scope와 JavaScript 접근 여부는 별도 규칙입니다. 가장 중요한 수정은 blog session을Domain없는 host-only cookie로 만들고 가능하면__Host-prefix,Secure,HttpOnly,Path=/를 사용하는 것입니다.탈취한 session ID는 password를 몰라도 인증 상태를 나타내는 bearer token처럼 재전송될 수 있습니다. 공격자는 자기 HTTP client에서 blog에
Cookie: session=...를 보내 피해자 session을 hijack하고 계정 data를 읽거나 권한 내 행동을 할 수 있습니다. 만료·rotation·재인증·server-side 이상 탐지가 영향을 제한할 수 있습니다.2 · 일상 장면으로 먼저 잡기
본사 전체의 모든 지점에서 통하는 방문증을 발급했는데, 믿을 수 없는 임시 행사장 관리자도 자기 출입구에서 그 방문증 번호를 확인할 수 있는 상황입니다.
Domain=mega-corp.comsession cookieweihnachtsfeier2023.mega-corp.comCookieheader에 값을 첨부__Host-cookie비유의 경계 Cookie Path는 host와 독립된 강한 보안 경계가 아니며 subdomain 관리자는 자기 host의 임의 path를 제공할 수 있습니다. 실제 hijacking 성공 범위는 session 만료, IP/device binding, step-up authentication에 따라 달라집니다.
session=SID42; Domain=mega-corp.com; Path=/https://weihnachtsfeier2023.mega-corp.com/invite방문상위 Domain·Path·Secure 조건이 일치
Cookie: session=SID42header 수신·읽기Blog에 SID42를 보내 Opfer session hijack
__Host-session; Secure; HttpOnly; Path=/HttpOnly는
document.cookie화살표만 막습니다. Domain cookie가 attacker host로 보내지는 network 화살표는 host-only scope로 막아야 합니다.상위 Domain cookie가 행사 subdomain server로 새는 정확한 조건
주어진 것과 목표 Blog가
Set-Cookie: session=SID42; Domain=mega-corp.com; Path=/; Secure; HttpOnly를 보냈고 피해자가https://weihnachtsfeier2023.mega-corp.com/invite를 엽니다.현재 host가 cookie Domain에 domain-match하는지 검사합니다.
왜? Cookie가 어느 server 요청에 포함될지를 결정하는 첫 조건이기 때문입니다.
중간 결과
weihnachtsfeier2023.mega-corp.com은mega-corp.com의 하위 domain이므로 조건을 만족합니다.현재 path와 scheme을 검사합니다.
왜?
Path=/와Secure도 network 전송 조건에 포함되기 때문입니다.중간 결과
/invite는/에 path-match하고 URL은 HTTPS이므로 Secure 조건도 만족합니다.Browser가 만드는 attacker-host request header를 적습니다.
왜? 공격자가 JavaScript 없이도 값을 얻는 server-side 경로를 확인하기 위해서입니다.
중간 결과 Request에
Cookie: session=SID42가 포함되고 subdomain 관리자는 자기 server log·code에서 이를 읽을 수 있습니다.같은 page의
document.cookie결과를 확인합니다.왜? HttpOnly의 정확한 보호 범위를 server-side 수신과 분리하기 위해서입니다.
중간 결과 이 예시는 HttpOnly이므로 JavaScript에서는 session 값이 숨겨지지만 attacker server에는 이미 전송됐습니다.
공격자가
SID42를 blog 요청에 replay합니다.왜? Opaque session ID도 값 자체를 복호화하지 않고 인증 수단으로 악용할 수 있기 때문입니다.
중간 결과 Session이 유효하고 추가 binding·재인증이 없다면 피해자로 impersonate해 account data와 기능에 접근할 수 있습니다.
Blog cookie를
Set-Cookie: __Host-session=SID42; Path=/; Secure; HttpOnly로 바꿉니다.왜?
__Host-규칙은 Domain 속성을 금지해 cookie를 정확한 blog host에 묶기 때문입니다.중간 결과 Sibling 행사 subdomain 요청에는 blog의 host-only session cookie가 붙지 않습니다.
예제 결론 상위 Domain scope가 핵심 노출 원인이고, HttpOnly는 hostile sibling server로의 cookie 전송을 막지 않으며 JavaScript 직접 읽기만 제한합니다.
실제 시험으로 옮기기 4점 답안에는 상위 Domain·host-only 조건, Path/Secure 전송 조건, JavaScript 경로의 HttpOnly 조건, session hijacking 영향과 host-only 수정까지 씁니다.
이번 문제는 이 단계로 풀어야 했습니다
먼저 문제에서 직접 주어진 값과 최종적으로 구할 값을 분리합니다. 그다음 각 값·용어·경로를 왜 선택했는지 확인하며, 앞 단계의 중간 결과를 다음 단계의 입력으로 사용합니다.
먼저 문제를 식과 조건으로 정리하기
계산을 시작하기 전에 주어진 것과 구할 것을 분리합니다. 그다음 아래 관계식을 위에서 아래로 사용하면, 숫자가 어디서 왔는지 놓치지 않을 수 있습니다.
강사가 문제의 요구사항을 쉬운 말로 바꾸면
시험 문장이 요구하는 것: 하위 domain 관리자가 언제 blog 방문자의 session cookie를 읽을 수 있고 무엇을 할 수 있는가?
이 문제의 풀이 전략: 이 소문제에서는 Blog cookie의 Domain scope를 확인한다 → 방문과 전송 조건을 확인한다 → 두 읽기 경로를 분리한다 → Secure와 SameSite의 역할을 제한한다 → 탈취 뒤 영향을 적는다 → Scope를 근본적으로 좁힌다 순서로 진행합니다. 마지막에는 ‘JavaScript 읽기 방어는 HttpOnly, sibling server로의 전송 방어는 host-only Domain scope로 나눕니다.’라는 교정 기준으로 답을 다시 확인합니다.
문제에서 주어진 정보
하위 domain 관리자가 언제 blog 방문자의 session cookie를 읽을 수 있고 무엇을 할 수 있는가?
`Domain=mega-corp.com`이면 행사 subdomain도 domain-match하지만, Domain이 없는 blog host-only cookie면 sibling host에 전송되지 않습니다.
SOP만 말하고 Cookie Domain 규칙을 놓치지 않습니다.
최종적으로 구해야 하는 것
Blog session을 Domain 없는 host-only cookie로 만들고 가능하면 `__Host-`, Secure, HttpOnly를 사용하며 session을 rotate·expire합니다.
Blog session cookie가 host-only가 아니라 `Domain=mega-corp.com`처럼 상위 domain에 scope되고 피해자가 `weihnachtsfeier2023.mega-corp.com`을 방문하면, Path가 맞고 Secure cookie의 경우 HTTPS일 때 browser가 그 cookie를 attacker subdomain 요청에도 보낼 수 있습니다. Subdomain 관리자는 server-side `Cookie` header에서 값을 읽을 수 있으며 이 경로는 HttpOnly여도 가능합니다. JavaScript의 `document.cookie`로 직접 읽으려면 non-HttpOnly여야 합니다. 탈취 token을 blog에 replay하면 session hijacking과 account impersonation이 가능하므로 host-only 또는 `__Host-` session cookie를 사용해야 합니다.
사용할 공식·판정 관계
Blog cookie의 Domain scope를 확인한다 → 방문과 전송 조건을 확인한다 → 두 읽기 경로를 분리한다 → Secure와 SameSite의 역할을 제한한다 → 탈취 뒤 영향을 적는다 → Scope를 근본적으로 좁힌다
HttpOnly는 `document.cookie` 화살표만 막습니다. Domain cookie가 attacker host로 보내지는 network 화살표는 host-only scope로 막아야 합니다.
Blog cookie의 Domain scope를 확인한다
구체적으로
Domain=mega-corp.com이면 행사 subdomain도 domain-match하지만, Domain이 없는 blog host-only cookie면 sibling host에 전송되지 않습니다.여기서 검산 SOP만 말하고 Cookie Domain 규칙을 놓치지 않습니다.
다음 단계로 여기서 확인한 내용을 다음 ‘방문과 전송 조건을 확인한다’ 단계의 출발점으로 사용합니다.
방문과 전송 조건을 확인한다
구체적으로 피해자가 attacker subdomain을 요청해야 하며 Path가 맞고 Secure cookie라면 HTTPS여야 합니다.
여기서 검산 Cookie가 이유 없이 원격 공격자에게 자동 방송된다고 쓰지 않습니다.
다음 단계로 여기서 확인한 내용을 다음 ‘두 읽기 경로를 분리한다’ 단계의 출발점으로 사용합니다.
두 읽기 경로를 분리한다
구체적으로 Attacker server는 받은
Cookieheader를 읽을 수 있고, JavaScriptdocument.cookie로 읽으려면 추가로 cookie가 non-HttpOnly여야 합니다.여기서 검산 HttpOnly가 server-side header 수신까지 막는다고 잘못 쓰지 않습니다.
다음 단계로 여기서 확인한 내용을 다음 ‘Secure와 SameSite의 역할을 제한한다’ 단계의 출발점으로 사용합니다.
Secure와 SameSite의 역할을 제한한다
구체적으로 Secure는 HTTPS 전송만 요구하고 SameSite는 sibling subdomain의 broad Domain scope를 제거하지 않습니다.
여기서 검산 Secure를 JavaScript 읽기 차단인 HttpOnly와 바꾸지 않습니다.
다음 단계로 여기서 확인한 내용을 다음 ‘탈취 뒤 영향을 적는다’ 단계의 출발점으로 사용합니다.
탈취 뒤 영향을 적는다
구체적으로 유효한 session token을 blog에 replay해 Opfer로 impersonate하고 account data·기능을 사용할 수 있습니다.
여기서 검산 Cookie 내용을 해독해야만 hijacking 가능하다고 쓰지 않습니다.
다음 단계로 여기서 확인한 내용을 다음 ‘Scope를 근본적으로 좁힌다’ 단계의 출발점으로 사용합니다.
Scope를 근본적으로 좁힌다
구체적으로 Blog session을 Domain 없는 host-only cookie로 만들고 가능하면
__Host-, Secure, HttpOnly를 사용하며 session을 rotate·expire합니다.여기서 검산 Path만 좁히는 것을 sibling-domain 격리의 주된 방어로 제시하지 않습니다.
다음 단계로 앞 단계의 결과를 모아 채점 가능한 최종 답안으로 정리합니다.
정답과 해설
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이 가능하다.
시험 답안 골격
정답이 이렇게 되는 이유
Blog session cookie가 host-only가 아니라
Domain=mega-corp.com처럼 상위 domain에 scope되고 피해자가weihnachtsfeier2023.mega-corp.com을 방문하면, Path가 맞고 Secure cookie의 경우 HTTPS일 때 browser가 그 cookie를 attacker subdomain 요청에도 보낼 수 있습니다. Subdomain 관리자는 server-sideCookieheader에서 값을 읽을 수 있으며 이 경로는 HttpOnly여도 가능합니다. JavaScript의document.cookie로 직접 읽으려면 non-HttpOnly여야 합니다. 탈취 token을 blog에 replay하면 session hijacking과 account impersonation이 가능하므로 host-only 또는__Host-session cookie를 사용해야 합니다.초보자가 가장 자주 뒤집는 지점
잘못된 생각 HttpOnly이면 상위 Domain cookie도 악성 subdomain 관리자에게 절대 보이지 않는다.
왜 틀렸나 HttpOnly는 JavaScript API만 제한합니다. Cookie scope가 attacker host와 맞으면 browser가 HTTP(S) request header로 값을 그 server에 전송하고 관리자는 server-side에서 볼 수 있습니다.
고쳐 말하면 JavaScript 읽기 방어는 HttpOnly, sibling server로의 전송 방어는 host-only Domain scope로 나눕니다.
한 문제만 더: 개념이 정말 연결됐는지 확인
질문
Secure; HttpOnly; SameSite=Strict; Domain=mega-corp.comcookie는 HTTPS인 악성 sibling subdomain server에 절대 전송되지 않습니까?정답 아닙니다. 같은-site HTTPS sibling host가 Domain과 Path에 match하면 server request에 전송될 수 있습니다. Host-only 또는
__Host-scope가 핵심 방어입니다.이 문제의 오답 함정
이 소문제를 점수로 바꾸는 6개의 작은 훈련
해설을 닫은 상태에서 1번부터 수행하세요. 정답을 읽은 직후보다 직접 문제 지도를 만들고 답을 꺼낸 뒤 채점할 때 기억이 더 정확해집니다. 작성 내용과 복습 판정은 이 브라우저에 자동 저장됩니다.
해설을 보지 말고 주어진 정보 → 구할 것 → 사용할 공식·판정 관계를 한 줄씩 복원하세요.
막힐 때만 첫 단서 열기
cookie의 Domain은 열쇠가 통하는 건물 범위다. 상위 domain 전체용 열쇠를 만들면 신뢰하지 않는 하위 domain 방에도 같은 열쇠가 들어간다.
하위 domain 관리자가 언제 blog 방문자의 session cookie를 읽을 수 있고 무엇을 할 수 있는가?
정답 문장만 말하지 말고 근거·중간값·메시지 흐름 중 이 문항에 필요한 것을 빈 종이에 남기세요.
작성한 뒤에만 아래 기준을 열고, 실제로 쓴 항목만 체크하세요.
답안 작성 후 채점 기준 열기
답안 슬롯 자가 점검 — 실제로 말하거나 쓴 항목만 체크하세요.
0/5 slots
조건 변형: 제시한 수정책 하나만 적용했다고 가정하세요. 그 수정이 정확히 막는 입력 경로와 여전히 남는 별도 취약점을 각각 한 문장으로 쓰세요.
고칠 답안: Same-Origin Policy만 말하고 cookie Domain 규칙을 놓치지 않는다.
복구 힌트: cookie의 Domain은 열쇠가 통하는 건물 범위다. 상위 domain 전체용 열쇠를 만들면 신뢰하지 않는 하위 domain 방에도 같은 열쇠가 들어간다.
오답의 첫 잘못된 전제를 한 줄로 지우고, 올바른 조건과 결론을 두 줄로 다시 쓰세요.
채점 전 예상과 실제 채점 결과가 달랐는지 확인한 뒤 상태를 남기세요. ‘숙달’은 근거와 중간 과정까지 무힌트로 재현했을 때만 선택합니다.
모든 훈련을 마친 뒤 핵심 정답 다시 확인
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이 가능하다.