개념 사전 · 개념
파일 업로드 보안
파일 업로드 취약점 · File upload security
은 외부 파일이 저장·분석·배포되는 과정에서 실행과 자원 접근의 경계를 지키는 설계다. 확장자 하나가 아니라 실제 형식·크기·저장 경로·제공 권한을 함께 다룬다.
밑줄 용어에 마우스를 올리거나, 키보드로 선택하거나, 터치하면 설명을 볼 수 있습니다.
01무엇이고, 어떤 일을 하나
- 검사 전 파일이 서비스 경로에 노출되는 것을 막는다.
- 사용자 파일명과 실제 저장 이름을 분리한다.
- 압축 크기와 디코딩 후 메모리 비용을 각각 제한한다.
02어떤 순서로 동작하나
- 요청 제한
인증·와 요청·파일 크기 한도를 검사하고 초과 시 임시 자원을 정리한다.
- 저장 이름 결정
서버가 만든 ID를 저장 키로 사용하고 원래 파일명은 별도 메타데이터로 취급한다.
파일을 검사 대기 상태로 저장한다. 웹 실행 경로와 일반 다운로드 경로에서 즉시 접근하도록 두지 않는다.
- 형식·내용 검사
허용 형식·시그니처·실제 파서 결과와 크기·확장 자원 한도를 평가한다. 시간 초과를 승인으로 처리하지 않는다.
- 상태 전이
검사 결과에 따라 approved 또는 rejected로 바꾸고 실패 자료·캐시를 정책에 맞게 처리한다.
- 후 제공
요청자의 소유권과 승인 상태를 다시 확인하고 적절한 Content-Type·으로 제공한다.
03먼저 알아둘 용어와 구성요소
- 한 요청에서 파일과 일반 필드를 부분별로 보내는 형식.
- 주장된 내용 형식이며 클라이언트 값만 신뢰할 수 없다.
- 검사 완료 전 파일을 실행·공개 경로와 분리해 보관하는 방식.
- 검사한 대상과 실제 사용할 대상이 중간 변경으로 달라지는 문제.
- 파일 형식을 식별하는 데 쓰는 내용의 특징 바이트.
- 작은 압축 입력이 해제 뒤 매우 큰 자원 사용을 만드는 문제.
- 응답 파일을 인라인 표시 또는 다운로드 등으로 처리하도록 안내하는 헤더.
LEARN THROUGH PRACTICE
업로드 성공과 서버 실행 가능성을 두 단계로 분리하기
파일이 저장되는 경계와 웹 서버가 그 파일을 실행하는 경계를 나누어 분석한다.
실습 구성과 전제
- 교육용 의 격리 스냅샷에서 화면을 읽는다.
- 직접 재현은 무해한 텍스트·이미지 파일로 한정하고 운영 서버나 실제 웹셸은 사용하지 않는다.
업로드 응답이 보장하는 범위를 읽는다
- 성공 메시지는 서버가 선택한 경로에 파일을 저장했다는 단서다. 안전 검사 통과나 비실행 저장소 분리까지 증명하지 않는다.
- 의 파일명·Content-Type은 클라이언트가 보낸 입력이다. 서버에서 확장자·형식·크기·저장 이름을 독립적으로 결정해야 한다.
원본 크기로 보기 ↗- File Upload 화면에 PHP 확장자의 파일이 업로드됐다는 메시지가 표시된다.
- 반환 경로가 웹 애플리케이션 아래 uploads 위치를 가리킨다. 제공 경로와 실행 정책을 이어서 확인해야 한다.
확인 기준업로드 성공과 파일 제공 정책을 별도 항목으로 적는다.
제공 경로가 실행 경로가 되는 조건을 찾는다
- 다른 화면은 업로드 파일에 요청을 보내 서버 측 작업 디렉터리가 응답된 교육 사례다. 실행 권한이 없는 파일 저장소라면 같은 방식으로 프로그램이 실행되지 않아야 한다.
- 웹 루트 밖 저장, 서버가 만든 식별자, 정적 다운로드 처리, 실행 엔진과의 분리가 서로 다른 통제다.
원본 크기로 보기 ↗- 주소 경로에 업로드된 PHP 파일이 있고 화면에 서버 디렉터리 결과가 나타난다.
- 업로드 메시지와 달리 이 화면은 저장 파일이 실행 경로에 놓였음을 보여 주는 별도 증거다.
확인 기준공격 입력을 반복하기보다 저장소·확장자 처리·서버 핸들러 설정을 조사한다.
무해한 파일로 수정 경계를 확인한다
- 허용 이미지, 잘못된 확장자, 제한 크기 초과를 각각 제출한다. 저장 후 이름이 서버에서 생성되는지와 다운로드 응답의 MIME·Disposition을 확인한다.
- 검사 중 파일은 제공하지 않고, 검사한 바이트와 제공하는 바이트가 같은지 확인한다.
확인 기준거부된 파일이 디스크나 공개 경로에 남지 않는지도 점검한다.
실습에서 확인한 동작 원리
- 업로드 성공은 안전 판정이 아니다.
- 저장 정책과 웹 실행 정책을 함께 분리해야 한다.
동작·명령 참고 문서
04예제로 따라가기
- 입력 조건: 압축 파일은 3MB지만 헤더가 가로 40,000·세로 40,000픽셀을 나타낸다고 가정한다.
- 픽셀 계산: 픽셀 수는 40,000×40,000=1,600,000,000개다. 3MB라는 전송 크기와는 다른 값이다.
- 메모리 추산: 한 픽셀을 RGBA 4바이트로 펼치면 기본 픽셀 버퍼만 6,400,000,000바이트가 필요하다. 디코더의 추가 메모리는 제외한 값이다.
- 처리 결과: 픽셀 수 또는 예상 메모리 한도를 초과하면 전체 디코딩 전에 거부한다. 헤더 검사도 파서 오류와 잘못된 수치에 대비해야 한다.
- 비교 표본: 작은 정상 이미지도 같은 승인 경로를 통과시켜 저장 ID·미리보기·다운로드가 일치하는지 본다. 거부 기능만 성공해서는 정상 기능을 검증하지 못한다.
05혼동하기 쉬운 점과 확인 기준
- 이름 재해석: 클라이언트 파일명을 서버 경로·명령 인수로 재사용하는지 본다. 표시용 이름과 실제 저장 키를 분리한다.
- 객체 교체: 동일 이름 덮어쓰기나 비동기 변환 때문에 승인된 해시와 제공된 해시가 달라졌는지 확인한다.
- 응답 문맥: 안전한 저장소라도 브라우저가 실행 가능한 Content-Type으로 제공하면 새로운 해석 경계가 생긴다. 다운로드 헤더와 Origin을 함께 설계한다.
06상세 노트 · 실습 자료
헤더 구조, 설정 예시, 수치 계산과 수업 캡처는 아래 노트에서 이어집니다.
공식 문서 · 표준
기초 개념과 동작 설명을 대조한 자료입니다. 제품 버전과 실제 설정에 따른 차이는 본문 및 원문에서 확인하세요.