3.2. Schwachstellenanalyse einer Webanwendung

1 · 먼저 알아야 할 개념

시험의 form 1행은 <form action="http://api.example.com/login.php" method="GET">입니다. 여기서 가장 먼저 볼 부분은 method보다 URL의 scheme인 http://입니다. HTTP는 application data를 네트워크에 암호화하지 않은 채 보냅니다.

HTTPS는 HTTP를 TLS 안에 넣어 전송합니다. TLS는 정상적으로 검증된 서버와 연결했을 때 전송 내용의 기밀성(confidentiality)과 무결성(integrity)을 제공하고, 인증서로 상대 서버의 이름을 확인합니다. 반대로 평문 HTTP에서는 같은 Wi-Fi의 공격자, 악성 공유기, 중간 network 장비가 credential을 관찰하거나 응답을 바꿀 수 있습니다.

Password 입력칸의 type="password"는 화면에서 글자를 점으로 가릴 뿐 network 암호화가 아닙니다. 또한 GET을 POST로 바꾸는 것도 URL 노출을 줄일 뿐 TLS를 만들지 않습니다. 이 소문항은 1행의 HTTP 전송 위험을, 다음 소문항은 GET의 기록 노출을 각각 묻습니다.

1 · 먼저 알아야 할 개념

HTTP GET은 resource를 조회할 때 쓰며 parameter를 보통 URL의 query string에 둡니다. 시험 form에 method="GET"이므로 입력값은 /login.php?user=...&pw=...처럼 주소 뒤에 붙습니다. 브라우저의 password 입력칸도 이 규칙을 바꾸지 않습니다.

URL은 화면 주소창뿐 아니라 browser history, bookmark, server access log, reverse proxy·monitoring log, 복사한 링크에 남기 쉽습니다. 다른 resource나 navigation에 전달되는 Referer에도 정책과 상황에 따라 URL 정보가 노출될 수 있습니다. 민감한 credential을 URL에 넣지 않는 이유입니다.

POST는 form 값을 request body로 옮겨 이런 URL 기반 노출을 줄입니다. 그러나 POST body도 HTTP 위에서는 암호화되지 않으므로 시험 form에는 POST와 HTTPS가 함께 필요합니다. 또한 login처럼 상태와 secret을 다루는 동작은 GET의 안전하고 반복 가능한 조회 의미와도 맞지 않습니다.

1 · 먼저 알아야 할 개념

PHP 2·3행은 $_GET['user']와 $_GET['pw']를 각각 $user, $pass에 넣습니다. 4행은 이 값을 SQL 문자열 안의 작은따옴표 사이에 직접 삽입합니다: SELECT * FROM users WHERE login = '$user' AND password = '$pass'. 사용자 입력이 SQL code와 한 문자열에 섞이는 순간이 취약점입니다.

SQL에서 작은따옴표는 문자열 literal의 경계이고 -- 는 여러 DBMS에서 그 줄의 나머지를 comment로 만듭니다. 공격자는 사용자 이름 데이터 구역을 작은따옴표로 닫은 뒤 comment를 시작해 뒤의 password 조건을 DB parser가 무시하게 할 수 있습니다.

표에서 목표 row의 login은 정확히 admin입니다. 단순한 ' OR 1=1 -- 는 조건을 모든 row에 참으로 만들어 첫 번째 row가 admin일 가능성은 있어도 의미상 특정 admin을 확실히 지정하는 답보다 약합니다. admin' -- 는 먼저 admin 조건을 만든 뒤 password 부분만 제거합니다.

5행의 DB 결과 뒤 6행은 $result->num_rows > 0만 검사하므로 admin row가 하나라도 반환되면 성공 분기로 갑니다. 제시된 code에는 session 생성 과정이 생략되어 있지만, 시험이 보여 준 login 검증 논리에서는 admin row 선택이 password 없는 성공을 뜻합니다.

1 · 먼저 알아야 할 개념

XSS(Cross-Site Scripting)는 공격자가 제공한 데이터가 피해자 browser에서 HTML 또는 JavaScript code로 해석되는 취약점입니다. Server가 PHP를 실행하는 것과 browser가 response의 HTML을 해석하는 것은 서로 다른 단계입니다.

시험 code에서 공격자 입력의 source는 2행 $_GET['user']이고 $user에 저장됩니다. 실패 분기의 9행 echo "<div>Fehlgeschlagener Login für Nutzer: " . $user . "</div>";는 그 값을 response HTML 안에 그대로 붙이는 sink입니다. Browser는 $user 부분도 단순 글자라고 자동 가정하지 않습니다.

이 경우 payload가 DB에 저장되지 않고 같은 request의 query parameter가 바로 실패 response에 되돌아오므로 reflected XSS입니다. HTML text context에서는 <, >, &, 따옴표 등을 문자 그대로 보이게 context-aware output encoding해야 합니다. PHP에서는 htmlspecialchars를 올바른 flag와 UTF-8로 사용할 수 있습니다.

SQL injection과 XSS는 같은 $user에서 시작해도 다른 parser를 공격합니다. 4행은 SQL parser가 읽는 query의 취약점이고, 이 문항이 묻는 data output 취약점은 9행을 browser의 HTML parser가 읽을 때 발생합니다.

1 · 먼저 알아야 할 개념

시험의 users 표에는 king2026, wonderland2002, 123456 같은 사람이 입력한 password가 그대로 보입니다. 이는 server가 login 검증용 verifier가 아니라 원문 plaintext를 DB에 저장했다는 뜻입니다. DB를 읽은 사람은 별도의 복호화나 cracking 없이 즉시 모든 password를 알 수 있습니다.

Password는 일반적으로 복호화 가능한 encryption보다 단방향 password hashing/KDF로 저장합니다. Login 때 입력 password와 저장된 salt를 같은 함수에 넣어 결과가 일치하는지만 확인합니다. Server는 원래 password를 되찾을 필요가 없습니다.

Argon2id, scrypt, bcrypt 같은 password 전용 함수는 의도적으로 느리고 비용을 조절할 수 있어 유출된 DB에 대한 offline guessing을 비싸게 만듭니다. PHP에서는 보통 password_hash에 PASSWORD_ARGON2ID 또는 PASSWORD_BCRYPT를 사용하고 그 결과를 password_verify로 검사합니다. scrypt를 택한다면 PHP의 이 API 조합이 아니라 검증된 별도 library/API와 그에 맞는 verify 절차가 필요합니다. 각 사용자마다 unique random salt를 쓰면 같은 password도 서로 다른 저장값이 됩니다.

Password reuse는 피해를 다른 service로 확장합니다. 이 표 안에서도 admin과 bob이 king2026을 공유합니다. 사용자가 Gmail·회사 VPN 등에서도 같은 값을 썼다면 공격자는 유출된 credential 조합을 자동 대입하는 credential stuffing을 시도할 수 있습니다.

1 · 먼저 알아야 할 개념

시험 login.php에는 독립된 두 code/data 경계가 있습니다. 4행의 문자열은 DB의 SQL parser가 읽고, 9행의 response 문자열은 피해자 browser의 HTML parser가 읽습니다. 두 취약점은 같은 $user에서 시작하지만 서로 다른 언어와 sink를 가집니다.

SQL injection 수정은 4행에서 query 문자열 결합을 없애고 prepared statement의 placeholder와 bound parameter를 사용하는 것입니다. 앞 문항처럼 password를 verifier로 저장한다면 username만 parameterized query로 조회한 뒤 PHP password_verify($pass, $storedHash)로 검증해야 합니다. 그러면 작은따옴표와 --는 SQL 문법이 아니라 username 값에 머물고 plaintext password 비교도 사라집니다.

Reflected XSS 수정은 9행에서 $user를 최종 HTML text context에 맞게 encode하는 것입니다. htmlspecialchars($user, ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8')는 < 등을 entity로 바꿔 browser가 tag로 만들지 않게 합니다. 가능하면 실패 message에 사용자가 입력한 이름을 다시 표시하지 않는 generic message도 노출을 줄입니다.

‘입력을 sanitize한다’는 한 문장으로는 충분하지 않습니다. SQL과 HTML은 특수문자와 문맥이 다르므로 parameterization과 output encoding을 각각 적용해야 합니다. Client-side validation은 공격자가 request를 직접 만들 수 있어 server-side 방어를 대신하지 못합니다.

1 · 먼저 알아야 할 개념

Password 강도는 눈에 보이는 특수문자 개수 하나로 정하지 않습니다. 공격자가 먼저 시도할 common password인지, 사전 단어·이름·연도 같은 규칙으로 생성됐는지, 충분히 긴지, 다른 account와 재사용됐는지를 함께 봅니다.

시험 표에는 admin king2026, alice wonderland2002, bob king2026, charlie 123456, eve 34@s5wa-rPg5.5가 있습니다. 123456은 매우 흔하고, king2026과 wonderland2002는 단어+숫자 패턴으로 추측하기 쉽습니다. 더구나 admin과 bob은 같은 king2026을 공유합니다.

Eve의 14자 값은 대소문자·숫자·기호가 섞여 있어 표의 다른 값보다 상대적으로 예측하기 어려워 보입니다. 그러나 생성 방식과 다른 site에서의 reuse를 모르므로 절대적으로 안전하다고 증명할 수는 없습니다.

권장 방식은 password manager가 계정마다 생성한 길고 random한 고유 password 또는 충분히 긴 고유 passphrase입니다. Server 쪽에서는 breached-password 차단, rate limiting, salted slow hash, MFA를 함께 사용하지만 이런 조치는 사용자가 같은 password를 재사용하는 문제를 완전히 대신하지 않습니다.