CSS Tutor Study Hub 메인으로

Computersystemsicherheit 2025/26

실제 시험 문제 46

단답형 · Web Sicherheit / 3.2 Schwachstellenanalyse einer Webanwendung

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

단답형

문제

근거 신뢰도 높음실제 시험지 대조 완료단답형2점

독일어 원문

Warum ist GET bei einem Login-Formular eine schlechte Wahl?

한국어 해석

login form에서 GET이 나쁜 선택인 이유는?

실제 시험에 제시된 Login 코드·사용자 표

index.html

1 <form action="http://api.example.com/login.php" method="GET">
2   Username: <input type="text" id="user" name="user">
3   Password: <input type="password" id="pw" name="pw">
4   <input type="submit" value="Login">
5 </form>

users

loginpasswordroleemail
adminking2026administratorbob.king@example.com
alicewonderland2002useralice303@gmail.com
bobking2026userbob.king@gmail.com
charlie123456guestch.ar.lie.xxx@gmail.com
eve34@s5wa-rPg5.5readonlyeve.online.1997@gmail.com

login.php

2  $user = $_GET['user'];
3  $pass = $_GET['pw'];
4  $sql = "SELECT * FROM users WHERE login = '$user' AND password = '$pass'";
5  $result = $conn->query($sql);
6  if ($result->num_rows > 0) {
7      echo "<div>Erfolgreich angemeldet!</div>";
8  } else {
9      echo "<div>Fehlgeschlagener Login für Nutzer: " . $user . "</div>";
10 }

출처: 실제 시험지 p13–14. 각 소문제에서 같은 code/data flow를 다시 추적합니다.

Login secret-flow · password storage

Browser formPOST + TLS →ServerKDF verify →salt + password hash

비밀이 노출되는 위치와 concrete fix를 연결하세요.

단계별 힌트

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

0/6
채점 기준으로 내 답안 점검하기
  • URL query string 노출을 쓴다.
  • history/log/Referer 중 두 경로를 든다.
  • POST+HTTPS를 구분한다.

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

0/3 slots

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

GET은 credentials를 URL query string에 넣어 browser history, server/proxy log, bookmark, Referer 등에 남기기 쉽다. POST와 HTTPS를 함께 사용한다.

exam_answer_frame
  • URL query string 노출을 쓴다.
  • history/log/Referer 중 두 경로를 든다.
  • POST+HTTPS를 구분한다.
개념부터 다시 보는 상세 풀이

BEGINNER LESSON

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

ZERO-BASE START

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

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

기초 개념 01

Browser, server, HTTP, HTML parser

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

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

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

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

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

TERMS FROM ZERO

전문 용어를 한 단어씩 풀기

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

HTTP request

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

HTTP response

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

Parser / Interpreter

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

Context

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

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

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

왜 여기서 많이 틀릴까요?

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

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

기초 개념 02

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

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

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

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

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

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

TERMS FROM ZERO

전문 용어를 한 단어씩 풀기

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

GET

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

POST

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

URL query

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

TLS

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

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

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

왜 여기서 많이 틀릴까요?

POST만 쓰면 네트워크에서 비밀번호가 암호화된다고 생각하면 안 된다.

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

핵심부터 말하면 GET은 비밀번호를 주소표에 적는 것과 같다. 본문에 넣는 POST가 기록 노출을 줄이지만 암호화는 HTTPS가 담당한다.

이 글에서 익힐 것

  • login form에서 GET이 나쁜 선택인 이유는?

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

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

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

이 문제가 어려운 이유

문제 문장은 짧지만 초보자가 이미 안다고 가정하는 용어와 중간 단계가 숨어 있습니다. 이 페이지에서는 ‘login form에서 GET이 나쁜 선택인 이유는?’를 바로 외우지 않고, 아래 연결 개념을 일상 장면에서 시작해 실제 시스템 순서로 바꿉니다.

문제가 묻는 것

login form에서 GET이 나쁜 선택인 이유는?

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

먼저 알아야 할 개념

  • Browser, server, HTTP, HTML parser

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

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

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

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

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

예제로 확인하기

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

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

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

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

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

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

    위 순서를 문제 문장 ‘login form에서 GET이 나쁜 선택인 이유는?’에 적용하면, 이 문항의 핵심 결론은 GET은 credentials를 URL query string에 넣어 browser history, server/proxy log, bookmark, Referer 등에 남기기 쉽다. POST와 HTTPS를 함께 사용한다.입니다.

  • GET과 POST, 그리고 TLS는 각각 무엇을 바꾸는가을 이 문제에 대입하기

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

    1. Login credential을 URL에 넣지 않는다.

    2. POST body로 전송한다.

    3. 전체 연결에 HTTPS를 사용한다.

    4. Server log와 error message에도 credential을 기록하지 않는다.

    위 순서를 문제 문장 ‘login form에서 GET이 나쁜 선택인 이유는?’에 적용하면, 이 문항의 핵심 결론은 GET은 credentials를 URL query string에 넣어 browser history, server/proxy log, bookmark, Referer 등에 남기기 쉽다. POST와 HTTPS를 함께 사용한다.입니다.

정답까지 사고 과정

  1. URL query string 노출을 쓴다.

  2. history/log/Referer 중 두 경로를 든다.

  3. POST+HTTPS를 구분한다.

시험장에서는 이렇게 쓰기

핵심 해설

GET은 credentials를 URL query string에 넣어 browser history, server/proxy log, bookmark, Referer 등에 남기기 쉽다. POST와 HTTPS를 함께 사용한다.

시험 답안으로 정리하기

  • URL query string 노출을 쓴다.

  • history/log/Referer 중 두 경로를 든다.

  • POST+HTTPS를 구분한다.

자주 틀리는 지점

  • POST만 쓰면 안전하다고 단정하지 않는다.

채점 포인트

  • URL query string 노출을 쓴다.

  • history/log/Referer 중 두 경로를 든다.

  • POST+HTTPS를 구분한다.

한 줄로 기억하기

GET은 비밀번호를 주소표에 적는 것과 같다. 본문에 넣는 POST가 기록 노출을 줄이지만 암호화는 HTTPS가 담당한다.

스스로 확인하기

  • GET URL이 제3자 요청의 Referer로 새는 예를 설명하라.

AI 구두시험용 프롬프트

한 문항만 풀어라. 먼저 정답을 열지 말고 90초 안에 답안을 말한 뒤, css-ws2025-26-web-php-002의 채점 프레임으로 스스로 채점하라. 문제: login form에서 GET이 나쁜 선택인 이유는?

학습 기록

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