화려한 0-day가 회사를 무너뜨리는 일은 드뭅니다. 대부분의 침해는 "설마 이것이?" 싶을 만큼 사소하고 흔한 것에서 시작됩니다.
들어가며: 스캐너가 놓치는 것, 사람이 보는 것
10장에서 우리는 자동화된 스캔으로 자신을 점검하는 법을 배웠습니다. 스캔은 강력하고 필수적이지만, 한계가 있습니다. 자동화된 도구는 알려진 패턴을 빠르고 광범위하게 점검하는 데 뛰어나지만, 맥락을 이해하거나, 여러 단서를 엮거나, "이것과 저것을 조합하면 어떻게 될까"를 상상하지 못합니다. 그 영역이 사람의 통찰, 즉 침투 테스트(펜테스트)의 영역입니다.
침투 테스트는 허가를 받은 보안 전문가가 공격자의 입장에서 실제로 시스템에 침투를 시도하여, 자동 스캔이 놓치는 약점과 그것들의 조합을 찾아내는 작업입니다. 이 장의 목적은 당신을 펜테스터로 만드는 것이 아닙니다. 펜테스트는 깊은 전문성과 엄격한 허가가 필요한 작업입니다. 이 장의 목적은, 펜테스트 현장에서 반복적으로 발견되는 것들을 보여 줌으로써, 방어자가 무엇을 미리 막아야 하는지 알게 하는 것입니다.
그리고 그 발견들의 가장 놀라운 점은, 대부분이 화려하지 않다는 것입니다. 정교한 0-day나 천재적인 기법이 아니라, 사소하고 흔하고 기본적인 실수들입니다. 노출된 채 잊힌 파일, 켜진 채 방치된 디버그 모드, 바꾸지 않은 기본 비밀번호, 잘못 설정된 권한. 펜테스터들이 입을 모아 말하는 진실이 있습니다. 회사를 무너뜨리는 것은 대개 가장 정교한 것이 아니라 가장 기본적인 것이다. 서문에서 말한 "10년 지난 기술을 쓰는 사이트"의 위험이 바로 이 누적된 기본의 부재입니다.
이 장에서는 펜테스트의 단계를 개관하고, 현장에서 가장 흔히 발견되는 약점들을 살펴봅니다. 이것을 "공격 방법"으로 읽지 마십시오. 이것은 "방어자가 자기 사이트에서 가장 먼저 점검하고 막아야 할 목록"입니다.
합법성에 대한 거듭된 강조: 침투 테스트는 반드시 대상 시스템 소유자의 명시적이고 서면화된 허가 하에서만 수행되어야 합니다. 허가 없는 침투 시도는 그 의도와 무관하게 한국의 정보통신망법을 비롯한 여러 법률의 명백한 위반이며, 중대한 처벌 대상입니다. 이 장의 내용은 방어자가 자신의 시스템을 점검하고 강화하기 위한 지식으로만 사용되어야 합니다.
11.1 펜테스트의 단계: 공격은 어떻게 전개되는가
실제 침투가 어떻게 전개되는지를 단계별로 이해하면, 각 단계에서 방어자가 무엇을 차단할 수 있는지가 보입니다. 펜테스트(그리고 실제 공격)는 대략 다음 단계를 거칩니다. 이것은 2장에서 본 APT의 작전 방식을 더 구체적으로 본 것이기도 합니다.
정찰 (Reconnaissance)
모든 것의 시작입니다. 1장 1.1에서 다룬 그대로, 표적에 대한 정보를 수집합니다. 도메인과 서브도메인을 열거하고, 노출된 자산을 찾고, 사용 기술과 버전을 파악하고, 공개된 정보(OSINT)를 모읍니다. 3장에서 보았듯 이 단계는 AI로 점점 자동화되고 있습니다.
방어자의 차단점: 5장의 공격면 지도화와 축소. 노출 정보를 줄이고, 그림자 자산을 정리하고, 버전 정보를 숨기면, 정찰의 수확이 줄어듭니다.
스캔과 열거 (Scanning & Enumeration)
정찰로 파악한 대상에 대해, 더 구체적으로 약점을 탐색합니다. 열린 포트와 서비스를 확인하고, 웹 애플리케이션의 경로와 엔드포인트를 열거하고, 알려진 취약점에 대한 노출을 점검합니다. 10장에서 방어자가 자신에게 수행한 스캔을, 공격자는 표적에게 수행합니다.
방어자의 차단점: 6장의 포트 닫기, 10장의 자가 진단. 닫힌 포트는 스캔할 것이 없고, 자가 진단으로 먼저 발견한 약점은 공격자가 도착하기 전에 막힙니다.
침투 (Exploitation)
발견한 약점을 실제로 악용하여 시스템에 발을 들입니다. 취약점을 익스플로잇하거나, 약한 인증을 뚫거나, 노출된 자격 증명을 사용하거나, 잘못된 설정을 악용합니다. 이 단계의 성공이 "뚫렸다"의 의미입니다.
방어자의 차단점: 이 책 전체의 기본기. 패치(4장), 강한 인증(7장), 올바른 설정. 그리고 11.2~11.5에서 다룰 흔한 약점들을 미리 막는 것.
권한 상승 (Privilege Escalation)
처음 침투했을 때 얻은 권한은 대개 제한적입니다. 공격자는 더 높은 권한 — 궁극적으로는 시스템 전체에 대한 관리 권한 — 을 얻으려 시도합니다. 잘못된 권한 설정, 취약한 시스템 구성, 노출된 자격 증명 등을 이용합니다.
방어자의 차단점: 최소 권한 원칙(7장). 각 계정과 프로세스가 최소 권한만 가지면, 침투해도 권한 상승이 어렵고, 피해가 그 권한 범위로 제한됩니다.
측면 이동 (Lateral Movement)
한 시스템을 장악한 뒤, 거기서 다른 시스템으로 이동합니다. 내부 네트워크를 가로질러 더 가치 있는 표적으로 나아갑니다. 2장에서 본 APT의 핵심 활동입니다.
방어자의 차단점: 네트워크 분할과 Zero Trust(6장). 내부를 신뢰하지 않고 분할하면, 한 시스템의 침해가 전체로 번지는 것을 막습니다(원칙 2, 침해를 가정하라).
흔적 정리와 지속 (Covering Tracks & Persistence)
공격자는 자신의 흔적을 지우고, 다시 들어올 수 있는 통로(백도어)를 남기려 합니다. 들키지 않고 오래 머무는 것이 목표입니다.
방어자의 차단점: 로깅과 모니터링(13장). 흔적을 지우기 어렵게 만들고, 이상을 빠르게 탐지하면, 공격자의 지속을 어렵게 합니다.
이 단계들을 보면, 방어가 어느 한 지점이 아니라 전체에 걸쳐 있어야 함을 알 수 있습니다. 한 단계를 막지 못해도 다음 단계에서 막을 기회가 있습니다. 이것이 깊이 방어(원칙 3)입니다.
11.2 노출된 파일과 디렉터리: 가장 흔한 첫 단추
이제 현장에서 가장 흔히 발견되는 약점들을 살펴봅니다. 그 첫 번째이자 가장 흔한 것이, 노출되어서는 안 될 파일과 디렉터리의 노출입니다. 1장 1.3에서 자동 공격의 표적으로 다뤘던 것들이, 펜테스트에서도 가장 먼저 확인하는 것들입니다.
.git 디렉터리 노출
여기서 한 번 더 강조할 만큼 흔하고 치명적입니다. .git 디렉터리는 버전 관리 도구 Git이 소스 코드의 모든 변경 이력을 저장해 두는 숨김 폴더입니다. 개발자가 배포할 때 이 디렉터리를 함께 올리고, 웹 서버가 이 디렉터리 접근을 막지 않으면, 공격자는 이것을 통째로 내려받아 전체 소스 코드와 모든 커밋 이력을 복원할 수 있습니다. 그리고 커밋 이력에는 과거에 실수로 넣었다가 지운 비밀번호나 키가 그대로 남아 있곤 합니다. 소스 코드를 얻으면 공격자는 애플리케이션의 모든 약점을 코드 수준에서 분석할 수 있습니다(3장에서 본 AI 코드 분석과 결합하면 더욱 강력합니다).
현장에서: 내가 인수받아 점검한 사이트들에서 노출된
.git은 한두 번 본 게 아닙니다. 흔한 경로는 배포를git pull한 번으로 끝내면서 웹 루트에 저장소를 통째로 둔 경우입니다. 브라우저 주소창에/.git/config를 쳐서 내용이 보이면 이미 노출된 것입니다. 노출된 저장소에서 옛.env나 키가 커밋 이력째로 흘러나오는 일이 잦으니, 발견하면 단순히 차단만 하지 말고 그 안에 담겼던 비밀을 전부 폐기·교체하십시오(11.4).
방어: 웹 서버에서 .git을 비롯한 버전 관리 디렉터리에 대한 접근을 명시적으로 차단하십시오. 더 근본적으로는, 배포 과정에서 이런 디렉터리가 아예 웹 루트에 포함되지 않게 하십시오(웹 서버가 바라보는 공개 폴더와 소스 저장소를 분리). 10장에서 다룬 자가 스캔(nuclei나 직접 요청)으로 노출 여부를 점검할 수 있습니다. 지금 바로 할 일: 자기 사이트에서 /.git/config, /.git/HEAD를 요청해 보고, 내용이 보이면 즉시 차단하고 비밀을 교체하십시오.
환경 설정 파일과 백업 파일
.env 파일(데이터베이스 비밀번호, API 키 등 가장 민감한 비밀을 한곳에 모아 두는 환경 설정 파일), 설정 파일의 백업본(config.php.bak, settings.py.old 등), 데이터베이스 덤프(backup.sql — 데이터베이스 내용을 통째로 떠낸 파일), 그리고 편집기가 남긴 임시 파일들. 이 모든 것이 웹에서 직접 접근 가능하게 노출되는 사고가 흔합니다. 단 하나의 노출된 .env로 데이터베이스 전체와 클라우드 계정이 넘어갈 수 있습니다. 백업 파일이 특히 위험한 이유는, 코드를 수정해도 옛 비밀번호가 그 안에 박제되어 남기 때문입니다. 11.6의 연쇄 사례가 바로 이 백업 파일에서 시작됩니다.
방어: 이런 민감 파일들이 웹 루트 밖에 있거나, 웹 서버에서 접근이 차단되도록 하십시오. 백업 파일을 웹에서 접근 가능한 곳에 두지 마십시오. 5장의 자가 점검 스크립트와 10장의 도구로 정기 확인하십시오.
디렉터리 목록 노출
웹 서버가 디렉터리의 내용을 목록으로 보여 주도록 설정되어 있으면, 공격자가 그 디렉터리에 어떤 파일들이 있는지 훤히 볼 수 있습니다. 의도하지 않은 파일, 백업, 숨겨 두었다고 생각한 자원들이 그대로 드러납니다.
방어: 디렉터리 목록 표시(directory listing/indexing) 기능을 비활성화하십시오. 대부분의 경우 이 기능은 꺼져 있어야 합니다.
11.3 디버그 모드와 정보 노출: 친절함이 부른 위험
두 번째로 흔한 부류는, 개발 편의를 위한 기능이 운영 환경에 남아 정보를 흘리는 경우입니다.
켜진 채 방치된 디버그 모드
대부분의 웹 프레임워크는 개발 중 문제를 진단하기 쉽도록 디버그 모드를 제공합니다. 디버그 모드에서는 오류가 발생하면 상세한 정보 — 오류가 난 코드의 위치, 변수의 값, 시스템 경로, 때로는 데이터베이스 연결 정보나 설정값 — 가 화면에 그대로 표시됩니다. 개발 중에는 더없이 유용하지만, 운영 환경에서는 재앙입니다.
운영 환경에서 디버그 모드가 켜져 있으면, 공격자는 일부러 오류를 유발하여 그 상세 정보를 수집합니다. 시스템의 내부 구조, 사용 기술과 버전, 파일 경로, 때로는 자격 증명까지 흘러나옵니다. 이것은 공격자에게 시스템의 내부 지도를 친절히 그려 주는 것과 같습니다.
그런데 디버그 모드는 정보 노출에서 그치지 않고, 그 자체가 침투 경로가 되기도 합니다. 대표적인 사례가 PHP 진영에서 널리 쓰이는 Laravel 프레임워크의 Ignition 디버그 화면 원격 코드 실행 취약점(CVE-2021-3129)입니다(원격 코드 실행, RCE = 공격자가 남의 서버에서 자기 명령을 실행하는, 가장 심각한 등급의 침해). Ignition은 오류가 났을 때 보기 좋은 디버그 화면을 띄워 주는 도구인데, APP_DEBUG=true(디버그 모드 켜짐) 상태로 운영에 올라간 사이트에서는 공격자가 이 화면의 기능을 악용해 서버를 통째로 장악할 수 있었습니다. "설정 한 줄(APP_DEBUG)을 끄지 않은 것"이 곧 서버 장악으로 이어진 것입니다. 패치는 이미 나왔지만, 디버그 모드를 끄지 않은 사이트들이 한동안 대량으로 털렸습니다. 자세한 내용은 NVD의 CVE-2021-3129 항목에서 확인할 수 있습니다.
방어: 운영 환경에서는 디버그 모드를 반드시 끄십시오. 이것은 너무나 기본적이지만, 펜테스트에서 놀랄 만큼 자주 발견되는 문제입니다. 개발과 운영 환경의 설정을 명확히 분리하고, 배포 시 디버그 모드가 꺼지는지 확인하십시오. 지금 할 일은 단순합니다. Laravel이라면 운영 서버의 .env에서 APP_DEBUG=false인지 확인하고, 다른 프레임워크라면 그에 해당하는 디버그 설정(개발용 켜짐 값)이 운영에서 꺼져 있는지 확인하십시오. CVE-2021-3129처럼 패치가 나온 지 오래된 취약점이 2026년 현재까지도 악용되는 이유가 바로 이 "설정 한 줄을 안 끈" 방치입니다 — 실제로 악용이 확인된 취약점은 CISA의 KEV 목록에서 추적할 수 있습니다. 12장에서 프레임워크별 맥락을 더 다룹니다.
상세한 오류 메시지
디버그 모드만큼 극적이지 않더라도, 지나치게 상세한 오류 메시지는 정보를 흘립니다. 데이터베이스 오류 메시지가 그대로 노출되면 데이터베이스 구조의 단서가 새고, 시스템 오류가 경로를 노출하며, 인증 실패 메시지가 "사용자명은 맞지만 비밀번호가 틀렸다"는 식으로 너무 친절하면 공격자가 유효한 계정을 식별할 수 있습니다.
방어: 운영 환경에서는 사용자에게 일반적이고 모호한 오류 메시지만 보여 주고, 상세한 내용은 외부에 노출되지 않는 로그에만 기록하십시오. 친절함과 보안 사이에서, 외부에 대해서는 보안을 택하십시오.
노출된 상태·정보 페이지
서버 상태 페이지(server-status), 정보 페이지(phpinfo), 모니터링 대시보드, API 문서 등이 인증 없이 외부에 노출되는 경우가 있습니다. 이런 페이지는 시스템 구성, 설치된 모듈, 환경 변수 등 공격자에게 유용한 정보를 담고 있습니다.
방어: 이런 진단·정보 페이지는 운영 환경에서 제거하거나, 6장의 방법으로 인증 뒤에 두거나, 접근을 제한하십시오. 필요 없는 것은 제거하는 것이 공격면 축소입니다.
11.4 자격 증명과 인증의 약점: 열쇠를 흘리다
세 번째 부류는 인증과 자격 증명에 관한 것입니다. 7장에서 SSH를 다뤘지만, 인증의 약점은 SSH에 국한되지 않습니다.
기본 자격 증명
수많은 소프트웨어, 장치, 서비스가 기본 사용자명과 비밀번호를 가지고 출고됩니다(admin/admin 같은). 이것을 바꾸지 않고 그대로 운영하는 경우가 — 믿기 어렵지만 — 매우 흔합니다. 공격자는 알려진 기본 자격 증명 목록을 가지고 있고, 가장 먼저 그것들을 시도합니다. 관리 패널, 데이터베이스, 네트워크 장비, IoT 기기 등에서 기본 자격 증명이 그대로 발견됩니다.
방어: 모든 소프트웨어와 장치의 기본 자격 증명을 설치 즉시 강한 것으로 변경하십시오. 5장의 인벤토리를 만들 때, 각 자산의 자격 증명이 기본값이 아닌지 함께 점검하십시오.
약하거나 재사용된 자격 증명
7장에서 비밀번호의 약점을 다뤘습니다. 약한 비밀번호는 무차별 대입으로 뚫리고, 재사용된 비밀번호는 한 곳의 유출이 다른 곳의 침해로 이어집니다. 펜테스트에서는 유출된 자격 증명 데이터베이스를 활용해, 표적 조직의 계정이 다른 서비스 유출에 포함되어 있는지 확인하는 것이 흔한 기법입니다(이를 자격 증명 스터핑이라 합니다 — 어디선가 유출된 아이디·비밀번호 쌍을 다른 사이트에 그대로 대입해 보는 것). 방어자도 같은 데이터를 거꾸로 활용할 수 있습니다. Have I Been Pwned에서 자신과 조직의 이메일이 알려진 유출에 포함됐는지 무료로 확인하고, 걸리는 계정의 비밀번호를 먼저 교체하십시오.
방어: 강한 비밀번호 정책, 비밀번호 재사용 금지, 그리고 무엇보다 다단계 인증(MFA, 3장·7장)입니다. MFA가 있으면 자격 증명이 유출되어도 두 번째 요소가 침입을 막습니다.
하드코딩된 비밀 정보
코드 안에 비밀번호, API 키, 토큰이 직접 적혀 있는 경우입니다. 이것이 위험한 이유는 여러 가지입니다. 코드를 보는 누구나(11.2의 .git 노출을 통해서든, 내부자든) 그 비밀을 얻습니다. 비밀을 바꾸려면 코드를 수정해야 합니다. 그리고 한 번 커밋되면 버전 이력에 영원히 남습니다.
방어: 비밀 정보는 코드에 넣지 말고, 환경 변수나 전용 비밀 관리 체계를 통해 분리하십시오. 부록 E에서 다룬 AI 코드 검토로 하드코딩된 비밀을 찾아낼 수 있습니다. 이미 커밋된 비밀이 있다면, 단순히 코드에서 지우는 것으로 부족하고, 그 비밀 자체를 폐기하고 교체해야 합니다(이력에 남아 있기 때문입니다).
11.5 잘못된 권한과 설정: 사소해 보이는 치명상
네 번째 부류는 권한과 설정의 오류입니다. 이것들은 개별적으로는 사소해 보이지만, 종종 침해의 결정적 발판이 됩니다.
과도한 권한
최소 권한 원칙의 위반입니다. 어떤 계정이나 프로세스가 자신의 작업에 필요한 것보다 훨씬 많은 권한을 가지고 있는 경우입니다. 웹 애플리케이션이 데이터베이스에 대해 필요 이상의 권한을 갖거나, 서비스 계정이 과도한 시스템 권한을 갖거나, 사용자가 불필요한 관리 권한을 갖는 식입니다. 이런 과도한 권한은 11.1에서 본 권한 상승의 지름길이 됩니다. 작은 침투가 큰 장악으로 이어지는 통로입니다.
방어: 최소 권한 원칙을 철저히 적용하십시오(7장). 각 계정과 프로세스에 꼭 필요한 권한만 부여하고, 정기적으로 권한을 검토하여 불필요한 것을 회수하십시오.
잘못된 파일 권한
파일과 디렉터리의 접근 권한이 잘못 설정되어, 읽혀서는 안 될 파일이 읽히거나, 수정되어서는 안 될 파일이 수정 가능한 경우입니다. 7장에서 SSH 개인키 파일의 권한을 강조했듯, 민감한 파일의 권한이 너무 개방적이면 그 자체가 약점입니다.
방어: 민감한 파일은 소유자만 접근할 수 있도록 권한을 엄격히 제한하십시오. 특히 설정 파일, 키 파일, 자격 증명을 담은 파일을 점검하십시오.
외부에 바인딩된 내부 서비스
5장에서 강조한 것입니다. 데이터베이스, 캐시, 관리 도구 같은 내부용 서비스가 로컬이 아니라 외부 인터페이스에 바인딩되어, 인터넷에서 직접 접근 가능한 경우입니다. 이것은 펜테스트에서 자주 발견되는 심각한 노출입니다. 외부에 노출된 데이터베이스는, 인증이 약하거나 기본값이라면 그대로 데이터 전체를 내줍니다.
방어: 내부 서비스는 로컬 인터페이스(127.0.0.1)에만 바인딩하십시오(5장, 6장). 외부 접근이 꼭 필요하다면 6장의 방법으로 게이트 뒤에 두십시오. 10장의 포트 스캔으로 노출 여부를 점검하십시오. 내 서버의 IP나 도메인을 Shodan에 넣어 보면, 공격자 눈에 어떤 서비스가 그대로 보이는지 바로 드러납니다 — 데이터베이스 포트가 검색 결과에 뜬다면 이미 누군가 찾고 있다는 뜻입니다.
안전하지 않은 직접 객체 참조와 접근 제어 누락
이것은 12장에서 더 깊이 다루지만, 펜테스트의 단골 발견이므로 짚어 둡니다. 어떤 자원에 접근할 때, 그 자원에 접근할 권한이 있는지를 제대로 확인하지 않는 경우입니다. 예를 들어, 사용자가 자신의 정보 페이지 주소에서 식별자만 바꾸면 다른 사용자의 정보가 보이는 식입니다. 인증은 되어 있지만(로그인은 했지만), 인가가 누락된(그 특정 자원에 접근할 권한 확인이 빠진) 경우입니다.
방어: 모든 자원 접근에 대해, 그 사용자가 그 자원에 접근할 권한이 있는지를 매번 확인하십시오. 이것은 12장의 접근 제어에서 자세히 다룹니다.
11.6 약점의 연쇄: 작은 것들이 모여 큰 침해가 된다
펜테스트에서 가장 중요한 통찰 하나를 마지막으로 다룹니다. 4장 4.2에서 CVSS의 한계로 언급했던 "연쇄"의 문제입니다.
실제 침해는 종종 단일한 치명적 취약점이 아니라, 여러 개의 작은 약점이 엮여서 일어납니다. 각각은 그 자체로 그리 위험해 보이지 않습니다. 노출된 디렉터리 목록 하나, 상세한 오류 메시지 하나, 약간 과도한 권한 하나. 스캐너는 이것들을 개별적으로 "낮음" 또는 "정보"로 표시할지 모릅니다. 그러나 펜테스터(그리고 실제 공격자)는 이것들을 조합합니다.
예를 들어 이런 식입니다. 디렉터리 목록 노출로 백업 파일의 존재를 발견하고, 그 백업 파일에서 옛 자격 증명을 얻고, 그 자격 증명이 다른 곳에 재사용되어 있어 그것으로 한 계정에 침투하고, 그 계정의 과도한 권한을 이용해 더 깊이 들어가는 것입니다. 각 단계는 사소하지만, 엮이면 완전한 침해가 됩니다.
이것이 의미하는 바는 두 가지입니다.
첫째, "낮음"으로 표시된 약점도 무시하지 마십시오. 그것이 연쇄의 한 고리가 될 수 있습니다. 특히 정보 노출 부류의 약점은, 그 자체로는 무해해 보여도 공격자에게 다음 단계의 단서를 줍니다.
둘째, 방어도 연쇄를 끊는 관점으로 보십시오. 모든 약점을 완벽히 없앨 수는 없더라도, 연쇄의 어느 한 고리만 끊어도 전체 공격이 무너질 수 있습니다. 깊이 방어(원칙 3)의 본질이 여기 있습니다. 한 겹이 뚫려도 다음 겹이 막으면, 연쇄가 완성되지 않습니다.
11.7 이 장이 남기는 교훈
이 장에서 확인한 것을 압축합니다.
첫째, 자동 스캔이 놓치는 것을 사람의 통찰이 봅니다. 맥락의 이해, 단서의 조합, 상상력이 펜테스트의 영역입니다. 다만 펜테스트는 엄격한 허가가 필요한 작업이며, 이 장의 지식은 방어를 위한 것입니다.
둘째, 회사를 무너뜨리는 것은 대개 가장 기본적인 것입니다. 화려한 0-day가 아니라, 노출된 파일, 켜진 디버그 모드, 기본 비밀번호, 잘못된 권한. "설마 이것이?" 싶은 사소함이 침해의 시작입니다.
셋째, 침투는 단계로 전개되고, 각 단계마다 차단점이 있습니다. 정찰·스캔·침투·권한 상승·측면 이동·지속. 한 단계를 놓쳐도 다음에서 막을 기회가 있습니다(깊이 방어).
넷째, 가장 흔한 발견들을 미리 막으십시오. 노출된 파일과 디렉터리(11.2), 디버그 모드와 정보 노출(11.3), 자격 증명의 약점(11.4), 잘못된 권한과 설정(11.5). 이것이 방어자의 최우선 점검 목록입니다.
다섯째, 작은 약점들의 연쇄를 경계하십시오. "낮음"으로 표시된 것도 연쇄의 고리가 될 수 있습니다. 방어는 연쇄를 끊는 관점으로 보십시오. 한 고리만 끊어도 전체가 무너집니다.
이 장에서 우리는 현장에서 발견되는 흔한 약점들을 폭넓게 보았습니다. 그중 많은 것이 웹 애플리케이션 자체의 문제였습니다. 노출된 경로, 접근 제어 누락, 인증의 약점. 다음 장에서는 이 웹 애플리케이션 취약점을 본격적으로, 체계적으로 다룹니다. 인젝션부터 접근 제어 붕괴, 그리고 스캐너가 결코 잡지 못하는 비즈니스 로직 결함까지 — 그리고 실제 프레임워크에서 터진 취약점의 교훈을 살펴보겠습니다.
이 장의 실행 항목
- 노출된 파일과 디렉터리를 점검하십시오.
.git,.env, 백업 파일, 디렉터리 목록. 10장의 도구로 확인하십시오. (11.2) - 운영 환경의 디버그 모드를 끄십시오. 상세 오류 메시지와 정보 페이지 노출도 점검하십시오. (11.3)
- 모든 기본 자격 증명을 변경하십시오. 5장 인벤토리의 각 자산을 점검하십시오. (11.4)
- 하드코딩된 비밀 정보를 제거하십시오. AI 코드 검토를 활용하고, 노출된 비밀은 폐기·교체하십시오. (11.4, 부록 E)
- 최소 권한 원칙을 적용하고 파일 권한을 점검하십시오. 과도한 권한과 개방적 파일 권한을 찾으십시오. (11.5)
- 내부 서비스의 외부 노출을 점검하십시오. 데이터베이스 등이 로컬에만 바인딩되었는지 확인하십시오. (11.5, 5·6장)
- "낮음" 약점도 연쇄 관점에서 검토하십시오. 정보 노출이 다음 단계의 단서가 될 수 있습니다. (11.6)
다음 장: 12장 — 웹 애플리케이션 취약점. OWASP를 넘어, 인젝션부터 비즈니스 로직 결함까지. 실제 프레임워크 CVE의 교훈.