보안

[웹 해킹과 보안 설정 가이드] 2장: 잘못된 보안 설정

kiritoni 2024. 9. 18. 10:58
반응형

잘못된 보안 설정

➡️ 디렉터리 인덱싱, 정보 누출, 관리자 페이지 노출, 위치 공개, 웹 서비스 메소드 설정 공격

➡️ 환경 설정 파일에 있는 보안 관련 항목의 값을 수정, 불필요하게 존재하는 파일의 삭제, 접근 가능한 IP만 허용하게 하는 접근 제어 등을 통해 조치

 


1) 디렉터리 인덱싱 취약점

✅ 디렉터리 내의 파일 정보들이 노출된다.

  • 웹 루트 디렉터리에 기본적으로 호출할 파일(Default.html, index.thml 등)이 없을 경우, 디렉터리 내의 파일 리스트를 웹 브라우저에 표시한다.
  • 🔍 디렉터리 인덱싱 취약점을 확인하는 방법
    • 웹 페이지 요청 시 도메인명 하위의 파일명과 변수명, 변수값을 확인하고 디렉터리 이름만 입력(끝에 '/'까지 입력)하거나 URL뒤에 %3f.jsp, %23.jsp를 입력한다.
    • ex. http://도메인명/board/, http://도메인명/icon, http://도메인명/%3f.jsp, http://도메인명/%23.jsp

🔐 대응 방안

톰캣: [톰캣 설치 디렉터리]/conf/web.xml에서 deafault servlet<param-value>값을 false로 설정한다.

💡 인코딩 값

🔻 %3f: 물음표(?) 문자의 URL 인코딩 값이다.
물음표는 URL에서 쿼리 문자열을 시작할 때 사용된다. 디렉터리나 파일의 인덱싱을 방해하거나 서버의 응답을 유도할 때 사용될 수 있다.
예를 들어, 서버가 물음표 뒤의 정보를 변수로 인식하려는 경우가 있어 특정 파일이 존재하지 않더라도 의도하지 않은 응답을 유도할 수 있다.

🔻 %23: 해시(#) 문자의 URL 인코딩 값이다.
해시는 URL에서 북마크(anchor)로 사용된다. URL에 포함된 해시는 보통 서버로 전달되지 않고 클라이언트 측에서만 사용되기 때문에, 디렉터리 인덱싱을 방해하거나 서버가 잘못된 응답을 하게 만드는 데 사용될 수 있다.

 

 


 

 

2) 정보 누출

➡️ 불필요한 정보가 누출되는 모든 것

🔐 정보 누출 취약점 확인과 대응 방안

  • 존재하지 않는 파일을 호출한다
  • URI에 전송되는 변수 값, 검색 창, 로그인 창 등 애플리케이션에서 사용되는 다른 데이터형의 숫자 또는 특수문자를 입력하여 오류 메시지가 노출되는지 여부를 확인한다.
  • 오류 메시지가 설정되어있지 않거나, 디폴트 오류 페이지를 사용할 경우 오류 메시지에 톰캣 등의 버전 정보가 노출된다.
  • 웹 프락시 툴을 이용해 응답 패킷 확인으로 서버 정보를 볼 수 있다.
  • 로그인 시 아이디/패스워드 중 어느 것이 틀렸는지 확실히 알려주면, 해커는 해당 아이디가 존재함을 알 수 있다.
    • '로그인에 실패했습니다.'나 '입력하신 정보가 일치하지 않습니다'등의 통합 메시지를 출력하고, '특수문자 입력 불가' 메시지를 출력하거나 오류 메시지를 별도로 설정해야 한다.
  • 개발할 때 오류를 확인하기 위해 설정했던 경로 정보와 디버그 정보 등은 개발이 완료된 이후에 반드시 수정해야 한다.
  • 오류 페이지를 따로 설정해야 한다.
    • ex. 톰캣: [톰캣 설치 디렉터리]/conf/web/xml에서 마지막 부분에 오류 처리 부분을 추가해 지정된 오류 페이지를 보여주도록 한다. 기본적으로 400, 401, 403, 404, 500에 대해 모두 설정해야 한다.

 

 

 


 

 

 

3) 관리자 페이지 노출

➡️ 관리자가 아닌 일반 사용자가 관리자 페이지에 접근할 수 있는 것이다.

🔐 관리자 페이지 노출 취약점 확인과 대응 방안

  • 관리자 페이지는 특정 사용자의 IP에서만 접근 가능하게 하고, 80포트가 아닌 별도의 포트를 생성해 사용하는 것이 안전하다.
  • 일반적으로 많이 사용하는 관리자 페이지 URL (/admin, /manager, /webmaster, /master, /administrator, /system 등)으로 접근 가능한지 확인한다.
  • 인증 없이 관리자 권한으로 접근 가능한 페이지에 직접 접근이 가능한지 확인한다.

 


 

 

4) 위치 공개

➡️ 불필요하게 존재하는 파일들에 의해 발생하는 위치 공개가 되는 것이다.

🔐 위치 공개 취약점 확인과 대응 방안

  • 정상 파일의 백업 파일이나 디폴트 파일들이 존재하는지 여부를 확인한다.
  • 톰캣 서버의 디폴트 페이지인 http://도메인명:8080/index.jsp, http://도메인명/tomcat-docs, 디폴트 관리자 페이지인 http://도메인명:8080/admin 등의 존재 여부도 확인해야 한다.
  • 따라서 초기 서비스를 설치할 때 디폴트로 설치되는 콘텐츠나 서비스들을 삭제하거나 비활성화 시켜야 한다.
  • 홈페이지를 리뉴얼하는 경우 기존 소스코드가 동일한 서버에 존재하지 않게 해야한다.
  • 숨겨진 디렉터리나 파일이 존재하지 않게 한다.
    • ex. 톰캣의 메뉴얼 디렉터리인 /[톰캣 설치 디렉터리]/manual, /[톰캣 설치 디렉터리]/conf/httpd.conf 파일의메뉴얼 부분을 삭제하거나 주석처리한다.

 


5) 웹 서비스 메소드 설정 공격

➡️ 불필요한 메소드 활성화로 인한 취약점이다.

🔐 웹 서비스 메소드 설정 공격 대응 방안

  • 서비스를 위해 꼭 필요한 메소드(GET, POST, OPTIONS)를 제외하고 모두 비활성화시키는 편이 안전하다.
  • PUT: 홈 디렉터리에 쓰기 권한이 설정되어있는 등의취약점이 존재할 경우, 실제 파일을 업로드함으로써 홈페이지 변조를 일으킬 수 있다.
  • 톰캣에서 불필요한 메소드를 제거하려면 [톰캣 설치 디렉터리]/conf/web.xml 파일에서 제거할 메소드를 추가해 설정한다.

💡 PUT, DELETE가 꼭 필요하다고 생각될 때는 어떻게 설정해야 할까?

  1. 인증 및 권한 관리: 해당 메소드 사용 시 Authentication과 Authorization을 철저히 해야한다.
  2. HTTPS 사용: 데이터가 전송 중에 도청되거나 변조되는 것을 방지한다.
  3. CSRF(Cross-Site Request Forgery) 방어: 해당 메소드 사용 시 CSRF 토큰을 함께 검증하도록 한다.
  4. 입력 검증 및 데이터 검증: 요청의 입력 데이터는 반드시 서버측에서 검증
  5. 불필요한 메소드 차단 및 제한: 서버에서 기본적으로 사용하지 않는 HTTP 메소드 (TRACE, OPTIONS)등은 가능한 모두 비활성화한다. TRACE의 경우 클라이언트의 요청을 그대로 반사하여 반환하기 때문에 보안상 매우 위험하다.
  6. 로그 및 모니터링: PUT, DELETE 요청을 포함한 중요한 요청에 대해 로그를 남기고, 비정상적인 패턴이 감지되면 경고를 발송하도록 설정한다.
반응형