[🥉 Bronze 2] 차단은 대소문자를 가리고 통과는 안 가린다 — DreamHack baby-Case 풀이

🧩 배경 — nginx location과 Express 라우팅의 대소문자

두 계층이 서로 다른 규칙으로 대소문자를 다룬다.

nginx의 location = /path 는 "정확히 이 경로"를 뜻하는 완전 일치 매칭이고, 경로 비교는 대소문자를 구분한다. 그래서 location = /shop은 /shop에만 걸리고 /Shop·/SHOP에는 걸리지 않는다.

Express 라우팅 은 기본값이 대소문자 무시다. case sensitive routing 옵션이 꺼져 있으면 app.post("/shop")이 /Shop, /SHOP 요청도 같은 핸들러로 받는다.

즉 nginx가 대문자 케이스를 "다른 경로"로 보고 통과시키면, Express는 그걸 "같은 경로"로 보고 처리한다. 이 어긋남이 첫 번째 우회다.

🔬 코드 정찰 — 두 겹의 차단

nginx는 /shop과 /shop/을 정확히 막고, 나머지는 앱으로 넘긴다.

앱은 leg가 정확히 'FLAG'면 403을 주고, 아니면 word.name === leg.toUpperCase()로 단어를 찾는다.

여기서 두 번째 어긋남이 보인다. 차단은 leg == 'FLAG'로 정확한 문자열을 비교하지만, 검색은 leg.toUpperCase()로 대문자화한 값을 비교한다. 그러니 소문자 flag는 차단을 통과하면서도('flag' != 'FLAG') 검색에는 걸린다('flag'.toUpperCase() === 'FLAG').

🐛 삽질 — 정직하게 보내면 두 군데서 막힌다

정리하면 경로의 케이스(/Shop)로 nginx를, 값의 케이스(flag)로 앱을 각각 통과시키면 된다.

💣 핵심 — 두 틈을 겹친다

세 계층의 대소문자 규칙을 겹쳐 보면 우회가 자연스럽게 나온다.

• 경로: /Shop(대문자 S) → nginx location = /shop(정확·대소문자 구분)에 안 걸림 → location /로 프록시 → Express(대소문자 무시)가 /shop 핸들러로 매칭.
• 값: leg=flag(소문자) → 'flag' == 'FLAG'는 거짓(차단 통과) → 'flag'.toUpperCase() === 'FLAG'는 참(FLAG 객체 매칭).

브라우저 콘솔에서 세 경우를 나란히 실행하면 차이가 분명하다. /shop은 nginx가, /Shop+leg=FLAG는 앱이 막지만, /Shop+leg=flag는 FLAG 객체를 그대로 돌려준다.

🎯 익스플로잇

curl로 세 단계를 확인하면 우회가 한눈에 들어온다.

POST /Shop에 leg=flag를 보내면 FLAG 객체의 description에 담긴 flag가 나온다.

🚀 Full Exploit

한 줄 요청이 전부다.

실행하면 flag가 바로 나온다.

📝 결론

계층마다 대소문자 규칙이 다르면 접근제어에 틈이 생긴다.

nginx는 경로를 대소문자 구분해 정확히 막았지만, 그 뒤의 Express는 대소문자를 무시해 같은 경로를 받아줬다. 앞단(프록시/WAF)과 뒷단(앱)의 매칭 규칙이 어긋나면, 앞단이 놓친 변형을 뒷단이 처리해 버린다. 접근제어는 요청을 실제로 처리하는 계층에서, 정규화된 값 기준으로 해야 한다. location = /shop처럼 정확 매칭으로 특정 경로만 막는 방식은 케이스·인코딩·슬래시 변형으로 쉽게 빠져나간다.

블랙리스트 비교와 실제 사용 값의 정규화가 어긋나면 안 된다.

앱은 leg == 'FLAG'(정확 비교)로 막고 leg.toUpperCase()(정규화)로 조회했다. 막을 때와 쓸 때 값을 다르게 다루면, 둘 사이 틈으로 우회가 들어온다. 차단도 조회와 똑같이 leg.toUpperCase() == 'FLAG'로 비교했다면 이 우회는 막혔다. 검증과 사용은 같은 형태의 값으로 해야 한다.