Yoo HeehyeonYoo Heehyeon

1. 개요

파일 업로드 기능은 웹 애플리케이션에서 자주 필요한 기능이지만, 검증이 느슨하면 큰 위험으로 이어질 수 있다. 특히 서버가 업로드된 파일을 잘못 처리하면 원격 코드 실행(RCE) 같은 심각한 문제로 연결되기도 한다.

2. 보안 검증 우회 기법

개발자는 보통 검증 로직을 넣어 악성 파일을 막으려 한다. 다만 검증이 단편적이면 우회 가능성이 생긴다.

2.1 파일 확장자 변조(Extension Bypass)

가장 먼저 보는 건 확장자 검사가 얼마나 단순한지다.

• Blacklist 우회: .php만 막는 식이면 .php5, .phtml, .PhP처럼 변형 확장자에 취약할 수 있다.
• 이중 확장자: shell.php.png 같은 형식도 서버 설정에 따라 통과 여부가 갈린다.

2.2 콘텐츠 타입 변조(MIME Type Bypass)

브라우저가 보내는 Content-Type 헤더만 믿는 경우에도 문제가 생긴다.

• 원리: 서버가 실제 파일 내용보다 헤더 값을 우선 신뢰할 때 발생한다.
• 진단 방법: Burp Suite로 요청을 가로채 헤더 값이 그대로 받아들여지는지 확인한다.
  • AS-IS: Content-Type: application/x-php
  • TO-BE: Content-Type: image/jpeg

2.3 매직 바이트 변조(Magic Byte Bypass)

파일의 실제 헤더(Magic Byte)만 보고 판단하는 경우도 허점이 될 수 있다.

• 원리: 서버가 파일 구조 전체를 보지 않고 헤더 몇 바이트만 확인할 때 생긴다.
• 진단 방법: 정상 파일 헤더와 다른 내용을 섞은 형태가 통과하는지 확인한다.
  • 예: PNG 헤더(89 50 4E 47 ...) + PHP 코드(<?php system($_GET['cmd']); ?>)
  • 이런 형태를 Polyglot File이라고 부르기도 한다.

3. LFI와 연계(Chaining)

업로드 기능이 어느 정도 막혀 있어도, 다른 취약점과 결합되면 위험도가 다시 커질 수 있다.

대표적으로는 LFI와 함께 보는 시나리오가 자주 언급된다.

1. 서버가 일반 이미지 업로드는 허용한다.
2. 업로드된 파일 자체는 곧바로 실행되지 않는다.
3. 별도로 LFI 취약점이 존재한다.
4. 이 두 조건이 맞물리면 업로드된 파일이 다른 방식으로 해석될 가능성이 생긴다.

예시 경로는 vuln.php?page=../../uploads/cat.png처럼 설명되곤 한다.

4. 자동화 및 실무 고려사항

4.1 자동화 도구

Fuxploider는 파일 업로드 취약점 점검에 자주 언급되는 도구다.

• 확장자, MIME 타입 등을 여러 조합으로 바꿔 보며 퍼징(Fuzzing)한다.

4.2 실무에서는?

파일 업로드 테스트는 흔적이 남기 쉽다는 점을 항상 같이 봐야 한다.

1. 자동화 도구를 과하게 돌리면 수많은 테스트 파일이 쌓여 스토리지 고갈(DoS)처럼 보이는 문제를 만들 수 있다.
2. 테스트 전에 업로드 허용 범위와 정리 방식은 반드시 합의해야 한다. 생성된 파일 목록도 같이 남겨 두는 편이 안전하다.
3. 테스트 파일은 식별 가능한 이름(test_vuln_check_01.php 등)으로 관리해야 나중에 정리하기 쉽다.