[🥉 Bronze 4] CSP를 뚫지 않고, 출력을 넘쳐 무너뜨리다 — DreamHack Broken Buffalo Wings 풀이

🧩 배경 — CSP, output_buffering, 그리고 header() 타이밍

PHP에서 header()는 본문(출력)이 나가기 전에 호출해야 한다. 첫 바이트가 클라이언트로 나가는 순간 응답 헤더가 확정되기 때문이다. 그래서 이미 echo로 뭔가 출력한 뒤 header()를 부르면 "headers already sent" 경고와 함께 그 헤더는 무시된다.

여기에 output_buffering이 끼어든다. PHP는 출력을 바로 내보내지 않고 버퍼(기본 수 KB)에 모은다. 버퍼가 차기 전에는 아직 헤더를 바꿀 수 있다. 하지만 출력이 버퍼 용량을 넘으면 버퍼가 flush되고, 그 순간 헤더가 확정된다 — 그 뒤의 header()는 실패한다.

이 문제의 CSP는 default-src 'self'; script-src *.bootstrapcdn.com 'nonce-…' 인데, 이걸 거는 header()가 댓글을 echo한 뒤에 있다. 그러니 출력을 버퍼보다 크게 만들면 CSP가 아예 안 걸린다.

🔬 코드 정찰 — index.php의 두 분기

댓글 처리 로직은 이렇다.

세 가지가 보인다. (A) 'lol'이 들어 있으면 댓글을 그대로 출력한다 — 여기가 XSS 삽입 지점이다. (B) 'script'가 들어 있으면 while 루프가 str_replace로 'script'를 지우며 반복마다 출력한다. (C) CSP는 이 모든 echo 뒤에 걸린다.

'lol' 댓글이 실제로 raw로 반영되는지 확인해 보면 그대로 뿌려진다.

🐛 삽질 — CSP를 정면으로는 못 뚫는다

정리하면 CSP를 우회하는 게 아니라, 애초에 CSP가 설정되지 못하게 만드는 것이다. 열쇠는 while 루프다.

💣 핵심 — 출력을 넘쳐 CSP를 무너뜨린다

while 루프를 오래 돌리려면 'script'가 지워도 다시 생기게 만든다. scr + script + ipt는 가운데 'script'를 지우면 scr+ipt = script가 되어 또 남는다. 이걸 K번 중첩하면 루프가 K번 돌고, 매번 남은 문자열을 통째로 출력하니 출력이 눈덩이처럼 커진다.

중첩 깊이를 늘려가며 CSP 헤더가 언제 사라지는지 재보면 경계가 뚜렷하다. 출력이 작을 땐 CSP가 붙지만, 커지면 헤더가 먼저 나가버려 CSP가 사라진다.

CSP가 사라진 페이지에서 'lol'로 삽입한 <script>는 그냥 실행된다. 개발자도구 콘솔에서, 주입한 스크립트가 document.cookie를 읽어 찍는 걸 확인할 수 있다.

🎯 익스플로잇 — navigation으로 쿠키를 흘린다

이제 쿠키를 우리 쪽으로 빼낸다. CSP가 없어졌지만, 여전히 주의할 게 있다 — fetch나 <img>로 외부에 보내려 하면 공격자 서버(여기선 zino.kr) 앞단의 WAF/CORP에 막힐 수 있다. 반면 top-level navigation(location = url)은 그런 제약을 받지 않고 그대로 요청이 나간다. 그래서 쿠키를 붙인 URL로 봇을 이동시키고, 공격자 nginx 접근 로그에서 회수한다.

페이로드는 이렇다.

'lol'은 raw echo 분기를 태워 <script>를 그대로 심고, 중첩 script는 while 루프를 돌려 출력을 버퍼 밖으로 넘긴다. 이 경로를 report.php에 제출하면 봇이 flag 쿠키를 달고 방문하고, location=으로 공격자 서버에 쿠키가 실려 나간다.

🚀 Full Exploit

페이로드 조립 → report.php 제출 → 공격자 로그 폴링을 한 스크립트로 묶었다.

실행하면 봇이 유출한 flag가 로그에서 회수된다.

📝 결론

보안 헤더는 출력보다 먼저 보내야 한다.

CSP·HSTS 같은 헤더는 어떤 출력보다도 앞에서 설정해야 한다. 이 문제는 CSP를 촘촘히 짜 놓고도 header()를 본문 echo 뒤에 두는 바람에, 출력만 부풀리면 헤더 자체가 무산됐다. output_buffering에 기대는 것도 위험하다 — 출력이 버퍼를 넘는 순간 무너진다. 헤더는 코드 최상단(혹은 출력 이전)에서 확정하는 게 원칙이다.

입력을 반영할 땐 이스케이프가 먼저다.

'lol' 분기가 사용자 입력을 아무 처리 없이 그대로 뿌린 게 XSS의 출발점이었다. htmlspecialchars 같은 이스케이프가 있었다면 <script> 자체가 심어지지 못했다. 블랙리스트(str_replace('script',''))는 근본 해결이 아니다 — 재귀로 재조립되거나(여기선 오히려 출력 증폭에 악용됨), 다른 벡터로 우회된다.

차단해도 새어 나가는 경로가 있다.

fetch·img를 막아도 top-level navigation은 남아 있었다. 유출을 막으려면 CSP의 navigate-to나 쿠키의 httpOnly처럼, "읽지 못하게"와 "내보내지 못하게"를 겹겹이 세워야 한다. 하나만 뚫려도 flag는 나간다.