파일 다운로드시 스프링의 Resource 하위 클래스인 urlResource를 이용하여 특정 파일에 접근 가능한 URL 생성하여 리턴할 수 있다. 토큰을 통한 인증을 추가 한다면 이 방법도 간단하고 좋은 방법이지만 URL 노출시 직접 접근이 가능하므로 위험성이 있다. 물론 로그인 사용지만 URL에 접근 가능하도록 /openImg/*에 대한 any권한 제거를 하면 보안이 좀더 강화 되지만 그래도 URL별로 액세스 제어 목록(ACL) 관리가 힘들다면 파일 자체를 바이너리 형태로 리턴하는게 보안상 더 안전하다.
다운로드를 위한 키값 전달
해당 키값에 해당하는 파일 읽어서 바이너리 형태로 리턴
이렇게하면 #164 에서 파일 관련 ../는 자동으로 해결 되지 않을까? 아니네. 그래도 WEB-INF까지 디렉토리 올라간 다음 중요 파일들 탈취 가능하겠네... 결국 ..은 막는걸로 하자.
만약 파일이 바로 보여주는게 아니라 다운로드 되도록 하려면 아래와 같이 응답헤더에 Content-Type과 Content-Disposition 설정하면 된다.
@GetMapping("/downloadFile")
public ResponseEntity<byte[]> downloadFile() throws IOException {
// 파일을 바이트 배열로 변환하는 예제
File file = new File("경로/파일명");
byte[] fileContent = Files.readAllBytes(file.toPath());
HttpHeaders headers = new HttpHeaders();
headers.setContentType(MediaType.APPLICATION_OCTET_STREAM);
headers.setContentDispositionFormData("attachment", file.getName());
headers.setContentLength(fileContent.length);
return new ResponseEntity<>(fileContent, headers, HttpStatus.OK);
}
133
146
154
157
파일 다운로드시 스프링의 Resource 하위 클래스인 urlResource를 이용하여 특정 파일에 접근 가능한 URL 생성하여 리턴할 수 있다. 토큰을 통한 인증을 추가 한다면 이 방법도 간단하고 좋은 방법이지만 URL 노출시 직접 접근이 가능하므로 위험성이 있다. 물론 로그인 사용지만 URL에 접근 가능하도록 /openImg/*에 대한 any권한 제거를 하면 보안이 좀더 강화 되지만 그래도 URL별로 액세스 제어 목록(ACL) 관리가 힘들다면 파일 자체를 바이너리 형태로 리턴하는게 보안상 더 안전하다.
이렇게하면 #164 에서 파일 관련 ../는 자동으로 해결 되지 않을까? 아니네. 그래도 WEB-INF까지 디렉토리 올라간 다음 중요 파일들 탈취 가능하겠네... 결국 ..은 막는걸로 하자.
만약 파일이 바로 보여주는게 아니라 다운로드 되도록 하려면 아래와 같이 응답헤더에 Content-Type과 Content-Disposition 설정하면 된다.