[주요정보통신기반시설 웹 애플리케이션 취약점 분석·평가 21일 완성 코스] 3강 — [Day 3] 디렉터리 인덱싱 (Directory Indexing)

⚡ 정다은 · 2026-09-23 14:00 · 조회 30

[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 등) 노출!

⚠️ 왜 위험할까요? (영향도)

단순히 파일 이름만 보이는 것이 뭐가 위험할까 싶지만, 공격자에게 이 목록은 **'보물 지도'**와 같습니다.

  1. 중요 정보 파일 노출: 백업 파일(.bak, .zip), 환경 설정 파일(.env, config.php), 로그 파일(.log) 등이 노출되어 DB 접속 정보나 비밀키가 유출될 수 있습니다.
  2. 소스 코드 유출: 컴파일되지 않은 스크립트 파일이나 개발자가 실수로 올려둔 임시 파일이 노출될 수 있습니다.
  3. 공격 지점(Attack Surface) 확대: 숨겨진 관리자 페이지, 업로드 디렉터리 내의 파일명을 파악하여 2차 공격(예: 악성 파일 다운로드, WebShell 실행)의 발판으로 악용됩니다.

2. 진단 방법 및 실제 예시

🔍 진단 방법

진단원들은 주로 다음과 같은 방법으로 디렉터리 인덱싱을 진단합니다.

  1. 수동 진단 (URL 조작)
    • 웹 서비스의 이미지, 첨부파일, 스크립트 경로 등에서 파일명을 제외하고 디렉터리 경로만 입력해 봅니다.
    • 예: https://target.com/upload/board/
  2. 구글링 (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 설정 방법]

  1. IIS 관리자 실행
  2. 조치할 웹사이트 선택 -> 중앙의 메뉴 중 [디렉터리 검색 (Directory Browsing)] 더블 클릭
  3. 우측 작업 창에서 [작업] -> [비활성화 (Disable)] 클릭

[web.config 소스 설정 방법]

<configuration>
    <system.webServer>
        <!-- directoryBrowse enabled를 false로 설정 -->
        <directoryBrowse enabled="false" />
    </system.webServer>
</configuration>

🛡️ 보완적 대책 (Defense-in-Depth)

웹 서버 설정을 변경하는 것이 가장 근본적인 해결책이지만, 보완적인 차원에서 다음과 같은 조치를 병행하면 더욱 안전합니다.

  1. 빈 인덱스 파일 생성: 모든 주요 디렉터리 내에 내용이 없는 index.html 또는 index.php 파일을 생성해 둡니다. (인덱싱 설정이 켜져 있더라도 index 파일이 먼저 읽히므로 목록 노출 방지)
  2. 사용자 지정 에러 페이지(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

로그인하면 댓글을 작성할 수 있습니다.