Notice
Recent Posts
Recent Comments
Link
«   2025/05   »
1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31
Tags
more
Archives
Today
Total
관리 메뉴

사적인 블로그

[tomcat] 게시글 업로드 용량 늘리기 : maxPostSize 본문

Troble Shooting

[tomcat] 게시글 업로드 용량 늘리기 : maxPostSize

DevYeri 2025. 3. 7. 19:17

이슈 : 긴 게시글을 올릴 때 405 에러가 남. 용량을 늘려달라
원인 : tomcat에서 post 전송을 할 때 데이터 크기제한(디폴트 2MB)에 걸렸음.

결론 : 올리려는 게시물은 3.4MB정도. tomcat의 server.xml 설정에서 maxPostSize="4194304" 4MB하니까 된다!

 

진행상황

1 . Tomcat server 설정 변경

위치 : /usr/local/tomcat7/conf/server.xml

과거에는 maxPostSize에 대한 설정이 별도로 없었음
해당설정이 없으면 디폴트는 2MB

 

참고 ) 현재 grails 톰캣 버전 : tomcat:7.0.55
tomcat 공식문서 maxPostsize 설명 : https://tomcat.apache.org/tomcat-7.0-doc/security-howto.html

The **maxPostSize** attribute controls the maximum size of a POST request that will be parsed for parameters. 
The parameters are cached for the duration of the request so this is limited to 2MB by default to reduce exposure to a DOS attack.

 

 

QA에 일단 용량 무제한으로 설정함

    <Connector port="8080" protocol="HTTP/1.1"
               executor="tomcatThreadPool"
        connectionTimeout="20000"
               URIEncoding="UTF-8"
               redirectPort="8443"
               maxPostSize="-1" // 용량 무제한
         />

 

일단 급한 불은 끔.

하지만 Live까지도 -1로 갈순없기에 파일크기 실험 간드아

 

 

2. 업로드 요청 파일 크기 확인

405 뜨는 요청의 네트워크 > 요청헤더에서 보이는 content 크기 : 3MB!

content-length: 3420508

 

3. 허용파일 용량 최적화

단위는 byte 단위로 적어줘야한다.

Connector port="8080" protocol="HTTP/1.1"
               executor="tomcatThreadPool"
        connectionTimeout="20000"
               URIEncoding="UTF-8"
               redirectPort="8443"
               maxPostSize="4194304"
         />

 

4MB로 하니까 게시글 등록 성공!

 

 


 

4MB 증가 후, 보안의 위협요소가 있을지?

보안상 위협

maxPostSize를 4MB로 늘릴 경우, 기존 2MB보다 많은 데이터를 한 번에 받을 수 있게 되므로 보안적인 리스크가 증가할 수 있어.

  1. DDoS 및 서비스 거부(DoS) 공격 위험 증가
    • 대량의 데이터를 포함한 요청을 지속적으로 보내는 공격이 더 효과적으로 작용할 수 있음.
    • 2MB일 때보다 4MB일 때 공격자가 더 큰 요청을 보낼 수 있어 서버 리소스를 더 많이 소모할 가능성이 있음.
  2. 파일 업로드 취약점 증가
    • 만약 애플리케이션이 파일 업로드 기능을 포함하고 있다면, 악성 파일 업로드 가능성이 커질 수 있음.
    • 파일 MIME 타입 체크, 확장자 필터링 등의 보안 조치를 반드시 확인해야 함.
  3. 메모리 및 리소스 사용 증가
    • 큰 데이터를 한 번에 처리해야 하므로, 서버의 메모리 사용량 증가 가능성이 있음.
    • 요청이 많아질 경우 GC(가비지 컬렉션) 부담이 증가하고, OutOfMemoryError 발생 위험이 커질 수 있음.
  4. SQL Injection 및 XSS 공격 가능성 증가
    • 클라이언트가 보낼 수 있는 데이터가 커지므로, SQL Injection, XSS 등의 공격 페이로드를 담을 공간이 더 많아짐.
    • 입력 데이터 검증을 철저히 해야 함.

사이드 이펙트 (부작용)

  1. 응답 속도 저하
    • 요청 크기가 커지면 네트워크 전송 시간이 길어지고, 서버에서 이를 처리하는 시간도 증가함.
    • 특히, 여러 사용자가 동시에 요청을 보낼 경우 응답 속도가 느려질 가능성이 있음.
  2. 메모리 사용량 증가
    • 큰 POST 요청을 받으면 그만큼 메모리 사용량이 증가하여, 서버가 과부하 상태에 이를 수 있음.
    • 특히, 많은 동시 요청이 들어오면 메모리 부족으로 인해 성능 저하가 발생할 수 있음.
  3. 파일 업로드 관련 예외 발생 가능성
    • 애플리케이션이 multipart/form-data 처리를 할 때, 기존 설정보다 큰 파일이 들어오면서 MaxUploadSizeExceededException 같은 예외가 발생할 수 있음.
    • 이를 대비해, 적절한 예외 처리 로직을 추가해야 함.

대응 방안

  1. 서버 성능 고려
    • maxPostSize를 올리더라도, 서버 메모리와 CPU 사용량이 감당할 수 있는지 확인해야 함.
    • 필요한 경우 WAS(Tomcat) 튜닝 및 부하 테스트 진행.
  2. 입력 데이터 검증 강화
    • 요청 크기가 커지면 악의적인 데이터가 들어올 가능성이 커지므로, WAF(Web Application Firewall) 설정이나 데이터 필터링 로직 추가 필요.
  3. Rate Limiting 적용
    • 단일 클라이언트가 너무 많은 큰 요청을 보내지 못하도록 속도 제한(rate limiting) 적용 고려.
  4. 파일 업로드 보안 강화
    • 파일 업로드라면 MIME 타입 체크, 파일 크기 제한, 저장 경로 검증 등을 강화해야 함.

결론

4MB로 늘리는 것은 기능적으로는 문제없지만, 보안과 성능상의 리스크를 고려해야 함. 위의 대응 방안을 적용하면 부작용을 줄일 수 있을 거야.