1. 동작 원리
- 사용자가 파일 업로드하면 업로드된 파일은 어딘가에 저장됨(개발자가 지정하므로 웹 애플리케이션마다 상이할 수 있음)
- 해당 취약점은 일반적으로 업로드 파일의 저장 위치가 웹 애플리케이션이 구동되는 서버와 동일한 서버인 경우 발생(파일 저장 위치는 웹 루트 디렉터리의 하위 디렉터리에 저장됨)
* 웹 루트 디렉터리란 웹 애플리케이션의 최상위 디렉터리로서 도메인 자체가 가리키는 디렉터리를 말함. Apache 웹 서버의 경우 웹 루트 디렉터리는 /var/www/html이며 업로드된 파일의 저장 위치는 /var/www/html/uploaded
- 업로드된 파일은 대부분 URL을 통해 접근할 수 있음. 즉 웹 애플리케이션에 접근 허용된 누구라도 웹 브라우저를 통해 파일에 접근할 수 있음.
- 공격자 입장에서는 업로드된 파일 위치를 파악하는 것이 제일 중요
> 소스코드의 <img>태그의 src 속성값, 파일 우클릭하여 속성 확인 등
2. 유형
- 로컬 파일 업로드 취약점: 웹 애플리케이션 자체에 사용자가 직접 악성 파일을 업로드할 수 있는 취약점. 공격자는 업로드된 파일을 실행하여 악의적인 행위 가능
- 원격 파일 업로드 취약점: 웹 애플리케이션 자체에 사용자가 직접 파일을 업로드할 수는 없으나, 인터넷에 존재하는 악성 파일 URL을 통해 원격 파일을 요청하게 하여 웹 애플리케이션 서버 내부에 저장할 수 있는 취약점
3. 대응방안
- 파일 확장자 검증: 안전한 파일 확장자만 업로드 허용하는 화이트리스트 방식의 필터 적용
- 파일 유형 검증: HTTP를 통해 업로드되는 파일은 Content-Type 헤더와 함께 전송되므로, 이를 검증. 허용할 Type을 정하고 Content-Type 헤더값이 허용된 Type 목록에 포함되는지 검사
- 파일 Magic Number 검증: 파일 형식을 식별하기 위한 매직 넘버를 검증
- 파일명 길이 및 파일 용량 제한
- 파일명 변경 또는 난독화: 공격자가 업로드된 파일 위치를 알 수 없도록 업로드 처리 시 파일명 변경하거나 난독화 수행
- 웹 루트 상위에 .htaccess 파일 저장: .htaccess 파일 대체할 수 없도록 웹 루트 상위 디렉터리에 저장
- 악성 파일 여부 검사
- 업로드 파일 저장 위치 분리: 업로드된 파일과 웹 애플리케이션 코드를 별도 공간에 저장
4. 취약점 테스트 방법
1) 파일 업로드 기능 식별
2) 정상 파일 업로드 및 URL 확인
3) 웹쉘 업로드
4) 업로드 실패 시 필터 분석 및 우회
5) 웹쉘 동작 확인
Ex) 워게임 내 파일 업로드 실습
