[주요정보통신기반시설 웹 애플리케이션 취약점 분석·평가 21일 완성 코스] 3강 — [Day 3] 디렉터리 인덱싱 (Directory Indexing)
[Day 3] 디렉터리 인덱싱 (Directory Indexing)
안녕하세요, 여러분! Hackerstory 공부방의 IT/보안 튜터 정다은입니다. 👋
지난 Day 1과 Day 2에서는 개발자의 소스 코드 검증 부재로 발생하는 공격인 코드 인젝션과 SQL 인젝션을 다뤘습니다. 코드 단에서의 공격 원리를 이해하시느라 고생 많으셨어요!
오늘 다룰 Day 3 주제는 개발 코드보다는 **'웹 서버 설정 오류'**에서 주로 발생하는 취약점입니다. 바로 디렉터리 인덱싱(Directory Indexing), 또는 **디렉터리 리스팅(Directory Listing)**이라 불리는 항목입니다.
기반시설 진단 실무에서도 가장 빈번하게 발견되는 항목 중 하나인데요. 원리부터 웹 서버별 설정 해제 방법까지 다은 쌤과 함께 차근차근 알아봅시다!
1. 디렉터리 인덱싱(Directory Indexing)이란?
💡 개념 이해하기
웹 브라우저에 https://example.com/images/ 처럼 특정 디렉터리 경로까지만 입력했을 때, 웹 서버는 기본적으로 해당 디렉터리 안에 있는 **기본 인덱스 파일(index.html, index.php, default.asp 등)**을 찾아 사용자에게 보여줍니다.
하지만 디렉터리 내에 기본 인덱스 파일이 존재하지 않고, 웹 서버 설정에서 디렉터리 인덱싱 기능이 활성화되어 있다면 어떻게 될까요?
웹 서버는 마치 컴퓨터의 '파일 탐색기'처럼 해당 디렉터리 내의 모든 파일과 하위 디렉터리 목록을 브라우저에 그대로 출력하게 됩니다. 이 현상을 디렉터리 인덱싱 취약점이라고 합니다.
[정상적인 동작]
요청: https://example.com/notice/
응답: notice 디렉터리 안의 index.html 실행 화면 출력
[디렉터리 인덱싱 발생 시]
요청: https://example.com/notice/ (index.html 파일이 없음)
응답: "Index of /notice" 브라우저 화면에 파일 리스트(notice_list.php, temp.bak, db_conf.old 등) 노출!
⚠️ 왜 위험할까요? (영향도)
단순히 파일 이름만 보이는 것이 뭐가 위험할까 싶지만, 공격자에게 이 목록은 **'보물 지도'**와 같습니다.
- 중요 정보 파일 노출: 백업 파일(
.bak,.zip), 환경 설정 파일(.env,config.php), 로그 파일(.log) 등이 노출되어 DB 접속 정보나 비밀키가 유출될 수 있습니다. - 소스 코드 유출: 컴파일되지 않은 스크립트 파일이나 개발자가 실수로 올려둔 임시 파일이 노출될 수 있습니다.
- 공격 지점(Attack Surface) 확대: 숨겨진 관리자 페이지, 업로드 디렉터리 내의 파일명을 파악하여 2차 공격(예: 악성 파일 다운로드, WebShell 실행)의 발판으로 악용됩니다.
2. 진단 방법 및 실제 예시
🔍 진단 방법
진단원들은 주로 다음과 같은 방법으로 디렉터리 인덱싱을 진단합니다.
- 수동 진단 (URL 조작)
- 웹 서비스의 이미지, 첨부파일, 스크립트 경로 등에서 파일명을 제외하고 디렉터리 경로만 입력해 봅니다.
- 예:
https://target.com/upload/board/
- 구글링 (Google Hacking / Dorks)
- 검색 엔진을 이용해 인덱싱이 열린 페이지를 탐색합니다.
- 예:
site:target.com intitle:"Index of"또는site:target.com "Parent Directory"
🖥️ 화면 예시
공격자나 진단원이 디렉터리에 접근했을 때 아래와 같은 화면이 나온다면 취약한 상태입니다.
Index of /uploads/backup
Icon Name Last modified Size Description
--------------------------------------------------------------------
[DIR] Parent Directory - -
[ ] db_connect.php.bak 2023-10-01 14:20 2.3K
[ ] users_data.zip 2023-10-02 09:15 15.4M
[ ] test_script.py 2023-10-03 11:00 1.1K
--------------------------------------------------------------------
백업 파일과 DB 연결 설정 백업 파일이 그대로 노출되어 매우 위험한 상황입니다!
3. 웹 서버별 보안 대책 (조치 방법)
주요정보통신기반시설 가이드라인에 따른 이 취약점의 양호 기준은 **"웹 서버 설정에서 디렉터리 리스팅/인덱싱 기능이 비활성화(Off)되어 있는 경우"**입니다.
가장 대표적인 웹 서버 3종(Apache, Nginx, IIS)에서의 조치 방법을 알아봅시다.
① Apache HTTP Server
Apache에서는 httpd.conf 설정 파일 또는 해당 디렉터리의 .htaccess 파일에서 Indexes 옵션을 제거하거나 -Indexes로 변경합니다.
- 설정 파일 위치:
/etc/httpd/conf/httpd.conf또는/etc/apache2/apache2.conf
[취약한 설정]
<Directory "/var/www/html">
Options Indexes FollowSymLinks
AllowOverride None
Require all granted
</Directory>
[안전한 설정 (조치)]
Indexes 앞에 -(마이너스)를 붙이거나 Indexes 단어 자체를 삭제합니다.
<Directory "/var/www/html">
Options -Indexes FollowSymLinks <-- -Indexes 로 변경!
AllowOverride None
Require all granted
</Directory>
Tip: 설정 수정 후 반드시 Apache 서비스를 재시작(
systemctl restart httpd또는apache2)해야 적용됩니다.
② Nginx
Nginx는 기본적으로 디렉터리 인덱싱(autoindex) 기능이 꺼져(off) 있습니다. 하지만 명시적으로 on 설정이 되어 있다면 off로 변경해야 합니다.
- 설정 파일 위치:
/etc/nginx/nginx.conf또는/etc/nginx/conf.d/default.conf
[취약한 설정]
server {
listen 80;
server_name example.com;
root /var/www/html;
location / {
autoindex on; <-- 취약!
}
}
[안전한 설정 (조치)]
autoindex를 off로 변경하거나 해당 라인을 삭제합니다.
server {
listen 80;
server_name example.com;
root /var/www/html;
location / {
autoindex off; <-- 안전하게 변경!
}
}
Tip: 수정 후
nginx -t로 구문 검사 후systemctl reload nginx를 실행하세요.
③ Microsoft IIS (Internet Information Services)
IIS는 관리자 GUI 화면 또는 web.config 파일을 통해 설정할 수 있습니다.
[GUI 설정 방법]
IIS 관리자실행- 조치할 웹사이트 선택 -> 중앙의 메뉴 중 [디렉터리 검색 (Directory Browsing)] 더블 클릭
- 우측 작업 창에서 [작업] -> [비활성화 (Disable)] 클릭
[web.config 소스 설정 방법]
<configuration>
<system.webServer>
<!-- directoryBrowse enabled를 false로 설정 -->
<directoryBrowse enabled="false" />
</system.webServer>
</configuration>
🛡️ 보완적 대책 (Defense-in-Depth)
웹 서버 설정을 변경하는 것이 가장 근본적인 해결책이지만, 보완적인 차원에서 다음과 같은 조치를 병행하면 더욱 안전합니다.
- 빈 인덱스 파일 생성: 모든 주요 디렉터리 내에 내용이 없는
index.html또는index.php파일을 생성해 둡니다. (인덱싱 설정이 켜져 있더라도 index 파일이 먼저 읽히므로 목록 노출 방지) - 사용자 지정 에러 페이지(403 Forbidden) 적용: 디렉터리 접근 시 서버 내부 정보가 담긴 기본 오류 메시지 대신, 정제된 에러 페이지를 보여줍니다.
4. 오늘 배운 내용 정리 📝
| 항목 | 내용 |
|---|---|
| 취약점명 | 디렉터리 인덱싱 (Directory Indexing) |
| 원인 | 인덱스 파일 부재 시 웹 서버의 디렉터리 목록 출력 기능 활성화 |
| 위험성 | 소스코드, 백업 파일, 환경설정 파일 등 중요 내부 자원 노출 |
| Apache 조치 | httpd.conf 내 Options -Indexes 설정 |
| Nginx 조치 | nginx.conf 내 autoindex off; 설정 |
| IIS 조치 | IIS 관리자에서 디렉터리 검색 비활성화 또는 web.config의 <directoryBrowse enabled="false" /> |
Next Step 🚀
오늘은 웹 서버 설정 오류의 대표적인 사례인 디렉터리 인덱싱에 대해 알아보았습니다. 설정 하나만 변경해도 내부 소스 및 백업 파일 유출 위험을 획기적으로 줄일 수 있다는 점, 꼭 기억해 주세요!
다음 시간에는 [Day 4] 에러 페이지 적용 미흡에 대해 공부합니다. 웹 애플리케이션에서 예외 상황 발생 시 노출되는 디버깅 메시지나 DB 에러 메시지가 공격자에게 어떤 힌트를 주는지, 그리고 이를 시스템 전체에서 어떻게 안전하게 공통 에러 페이지로 처리해야 하는지 자세히 알아볼게요!
수고 많으셨습니다. 다음 챕터에서 만나요! 😊
댓글 0
로그인하면 댓글을 작성할 수 있습니다.