파일 업로드와 경로 처리의 보안

01개념과 구성 요소

• 처리 경계파일 업로드는 바이트 수신, 경로 선택, 저장, 검사, 후속 파싱·실행으로 나뉜다.
• 신뢰하지 않는 값filename·Content-Type·파일 내용은 모두 검증 대상이며 하나만으로 안전한 형식을 증명하지 못한다.
• 분리할 권한저장 위치·다운로드 소유권·실행 권한·변환기 권한을 각각 제한한다.

02업로드 파일을 검사 후 제공하는 순서

1. 요청 제한인증·인가와 요청·파일 크기 한도를 검사하고 초과 시 임시 자원을 정리한다.
2. 저장 이름 결정서버가 만든 ID를 저장 키로 사용하고 원래 파일명은 별도 메타데이터로 취급한다.
3. 격리 저장파일을 검사 대기 상태로 저장한다. 웹 실행 경로와 일반 다운로드 경로에서 즉시 접근하도록 두지 않는다.
4. 형식·내용 검사허용 형식·시그니처·실제 파서 결과와 크기·확장 자원 한도를 평가한다. 시간 초과를 승인으로 처리하지 않는다.
5. 상태 전이검사 결과에 따라 approved 또는 rejected로 바꾸고 실패 자료·캐시를 정책에 맞게 처리한다.
6. 인가 후 제공요청자의 소유권과 승인 상태를 다시 확인하고 적절한 Content-Type·Content-Disposition으로 제공한다.

03파일 업로드가 실행 취약점으로 이어지는 경계

• 저장과 해석파일을 받는 기능은 바이트를 저장하는 단계와 나중에 해석하는 단계로 나뉜다. 업로드한 파일이 웹 루트에 저장되고 서버가 그 확장자를 PHP 같은 실행 핸들러에 연결하면, 단순 자료 업로드가 서버 코드 실행으로 바뀐다.
• 처리기 권한반대로 웹 루트 밖에 저장한 파일도 이미지 변환기·문서 미리보기 파서의 취약점을 통과하면 위험해진다. 파일 저장만 성공했는지와 파일이 어떤 권한으로 어떤 처리기에 전달되는지는 별개이다.
• 업로드·포함 결합파일 업로드와 파일 포함이 연결되면 저장된 바이트가 나중에 실행 입력이 될 수 있다. 업로드 경로를 웹에서 실행하지 않더라도 별도의 include 기능이 같은 파일을 코드로 읽으면 실행 경계가 다시 열린다.
• 통제 분리저장소 분리, 실행 금지, 포함 대상 제한을 서로 다른 통제로 이해해야 한다.

04multipart 요청에서 신뢰할 수 없는 세 가지 값

• Multipart 필드브라우저가 만드는 multipart/form-data에는 boundary로 구분된 각 부분의 이름, filename, Content-Type과 실제 파일 바이트가 담긴다. filename은 저장 경로가 아니라 클라이언트가 제공한 표시 정보이며, Content-Type 역시 클라이언트 주장이다.
• 형식 주장의 한계이미지라는 헤더와 .jpg라는 이름이 있어도 본문이 이미지라는 증거가 되지 않는다.
• 서버 저장 이름서버가 임의 식별자로 저장 이름을 만들고 원래 이름은 메타데이터로 관리하면 충돌·경로 조작을 줄일 수 있다. 허용 확장자와 파일 시그니처, 실제 디코더의 해석 결과를 함께 사용할 때도 다중 형식 파일과 복잡한 파서의 위험은 남는다.
• 검사와 실행 권한따라서 검사 통과가 곧 실행 권한 부여를 뜻해서는 안 된다.

POST /training/avatar HTTP/1.1
Content-Type: multipart/form-data; boundary=lesson

--lesson
Content-Disposition: form-data; name="avatar"; filename="portrait.png"
Content-Type: image/png

[PNG 바이트]
--lesson--

원리를 설명하는 가상 학습 예시입니다.

05저장 이름·경로·권한을 분리하는 설계

• 저장 키·메타데이터업로드 서비스는 사용자의 파일명으로 경로를 직접 연결하지 않고 서버가 만든 ID를 사용한다. 데이터베이스에는 소유자, 저장 키, 크기, 판별된 형식, 검사 상태를 저장한다.
• 다운로드 인가다운로드 요청의 ID는 이 레코드를 조회한 뒤 소유권 검사와 실제 저장 키 선택으로 이어진다. 경로를 URL에서 직접 받는 설계보다 저장 위치와 접근 권한을 명확히 분리한다.
• 실행 경로 분리저장소를 웹 루트 밖 또는 별도 객체 저장소에 두면 웹 서버의 스크립트 핸들러에 우연히 연결되는 위험이 줄어든다. 제공할 때도 적절한 Content-Type과 Content-Disposition을 결정한다.
• 능동 콘텐츠HTML·SVG처럼 능동 콘텐츠가 가능한 형식은 표시 기능의 요구와 격리 출처를 따로 설계해야 하며, 이미지 재인코딩은 지원 형식의 불필요한 부가 데이터를 줄이는 방법이지 모든 형식의 만능 검사기는 아니다.

06크기 제한과 비동기 검사 상태

• 자원 제한HTTP 요청 크기, 업로드 파일 크기, 사용자 저장 할당량, 디코딩된 이미지의 픽셀 수는 서로 다른 자원 제한이다. 압축 파일은 작은 입력이 큰 결과로 풀릴 수 있어 압축 전 크기만 제한해도 충분하지 않다.
• 임시 파일 정리한도 초과 때 임시 파일을 정리하지 않으면 실패한 요청이 디스크를 차지한다.
• 검사 상태비동기 검사에서는 received → quarantined → approved 또는 rejected 같은 상태를 둔다. 검사가 완료되기 전에 일반 다운로드 경로가 파일을 제공하면 검사 대기 시간 동안 우회가 생긴다.
• 실패·재검사 정책검사 실패·시간 초과를 승인으로 처리하는 fail-open도 같은 문제다. 승인된 콘텐츠에 대해 이후 재검사 결과가 바뀌었을 때 제공 상태와 캐시를 함께 갱신해야 한다.

10Path Traversal은 기준 디렉터리를 벗어나는 문제

• 경로 선택경로 순회는 사용자 입력이 파일 경로에 연결되고 상위 디렉터리 이동·절대 경로·인코딩 변환 등으로 허용 루트 밖의 파일을 가리킬 때 발생한다. 파일 포함과 달리 단순 읽기 API에서도 발생한다.
• 문자 제거의 한계문자열에서 ../만 지우는 방식은 운영체제의 경로 규칙, 중복 디코딩, 심볼릭 링크 해석을 충분히 반영하지 못한다.
• ID 매핑가장 단순한 대책은 외부 ID를 서버가 정한 파일에 매핑하여 사용자가 경로를 표현할 필요를 없애는 것이다. 경로 입력이 꼭 필요하다면 최종 정규화 경로가 허용 루트 안에 있는지 경로 구성요소 단위로 검사한다.
• 정규화·경쟁 조건/data/files와 /data/files-old가 같은 문자열 접두사를 공유하므로 단순 startsWith 비교만으로 경계를 정하면 안 된다. 검사 후 링크가 바뀌는 경쟁 조건과 파일 접근 권한도 별도로 남는다.

11LFI·RFI와 다운로드의 차이

• Include와 읽기LFI는 로컬 파일을 include/require/템플릿 로더와 같은 해석 경로에 포함하는 문제이고, RFI는 지원·허용된 환경에서 원격 자원을 포함하는 문제이다. readfile처럼 데이터를 응답하는 동작과 include처럼 언어 처리기에 전달하는 동작을 구분한다.
• 실행 조건취약점 영향은 포함 API, 파일 내용, 런타임 설정과 서비스 계정 권한에 의해 결정된다.
• LFI 영향 범위LFI로 특정 파일을 읽을 수 있다는 사실만으로 임의 코드 실행이 증명되지는 않는다. 공격자가 제어한 바이트가 파일에 기록되고, 그 파일이 코드로 해석되는 추가 조건이 있어야 실행으로 연결되는 경우가 있다.
• chroot 한계chroot는 파일 시스템 이름 공간을 제한한다. 애플리케이션의 파일 선택 검증·실행 권한을 대신하는 완전한 격리 장치는 아니다.

12정상 파일과 경계 입력의 처리 결과 읽기

• 정상 파일 흐름학습용 정상 PNG를 올려 저장 ID가 반환되는지, 승인 전 다운로드가 거부되는지, 승인 뒤 정확한 형식으로 제공되는지를 연속해서 본다. 허용되지 않은 형식·너무 큰 파일·중복 이름·소유자가 다른 ID는 각각 다른 방어 층을 시험한다.
• 경계 입력반환 코드뿐 아니라 임시 파일 정리, 저장 위치, 처리기 선택, 승인 상태 변화가 동작의 근거다.
• 세 가지 경계업로드·파일 포함·경로 순회는 서로 다른 처리 경계이므로 확장자 필터 하나로 해결되지 않는다. 업로드는 바이트를 들이는 경계, 경로 순회는 파일을 선택하는 경계, 포함은 바이트를 코드로 해석하는 경계이며, 한 기능이 다른 기능에 값을 넘길 때도 이 구분을 유지한다.