웹 취약점 진단 실습 가이드

🌿 자라는 중

목차

• 1. 큰 그림: 두 갈래로 나눈다
• 2. 취약점별 진단 포인트
• 2.1 SQL 인젝션
• 2.2 XSS
• 2.3 접근 통제 누락(IDOR)
• 2.4 파일 업로드
• 2.5 인증 우회
• 2.6 정보 노출
• 3. 진단 결과를 보고서로 쓰는 양식
• 4. 말로 설명하는 연습
• 5. 실습 환경
• 남은 것

웹 취약점 여섯 개를 로그로 하나씩 정리하고 나니, 흩어진 걸 한 장으로 묶고 싶어졌다. 이 노트는 “개념을 아는 것”에서 “실제로 찾아서 설명하는 것”으로 넘어가기 위한 실습용 정리다. 진단 실습을 하며 계속 갱신할 living 문서로 둔다.

핵심 여섯 개는 로그에 개별 정리가 있다. 여긴 진단 관점(어디를 보고, 어떻게 재현하고, 어떻게 설명하나)으로 다시 엮는다.

• SQL 인젝션 · XSS · IDOR
• 파일 업로드 · 인증 우회 · 정보 노출

1. 큰 그림: 두 갈래로 나눈다

여섯 개는 결국 두 뿌리다. 진단하다 뭔가 찾으면 이 분류부터 하면 조치가 빨리 나온다.

뿌리	취약점	한 줄 방어
입력을 안 믿어서	SQL 인젝션, XSS, 파일 업로드	입력을 값·글자로 가둔다
권한을 안 지켜서	IDOR, 인증 우회, 정보 노출	서버가 매 요청마다 권한을 다시 확인한다

2. 취약점별 진단 포인트

각 항목은 “어디를 보나 → 어떻게 재현하나 → 조치” 순서다.

2.1 SQL 인젝션

• 어디를 보나: 로그인 폼, 검색창, 게시글 번호처럼 입력이 DB 조회로 이어지는 지점.
• 재현: 입력에 따옴표(')를 넣어 에러나 반응 변화를 본다. ' OR '1'='1' -- 로 로그인 우회, ' UNION SELECT ... -- 로 데이터 추출, ' AND SLEEP(5) -- 로 블라인드 확인.
• 조치: 매개변수 바인딩(프리페어드 스테이트먼트). 입력을 구조가 아닌 값으로 분리.

2.2 XSS

• 어디를 보나: 입력이 화면에 그대로 출력되는 곳. 검색어 반사, 댓글·게시글 저장 출력, URL 값으로 DOM을 바꾸는 스크립트.
• 재현: <script>alert(1)</script> 로 실행 여부 확인. 반사형(링크 클릭 즉시), 저장형(글 저장 후 보는 사람마다), DOM 기반을 구분.
• 조치: 출력 이스케이프 또는 textContent, 추가로 CSP.

2.3 접근 통제 누락(IDOR)

• 어디를 보나: URL·파라미터의 식별자(id=1001, order=5023). 특히 순차 숫자.
• 재현: 로그인한 상태에서 식별자만 다른 값으로 바꿔 남의 자원이 열리는지 본다.
• 조치: 서버가 매 요청마다 소유권 확인. 식별자는 추측 어렵게(UUID)는 보조.

2.4 파일 업로드

• 어디를 보나: 프로필 사진, 첨부파일 등 업로드 기능.
• 재현: 실행 파일 업로드 시도, 확장자 우회(shell.php.jpg, shell.pHp, 이미지 시그니처 위장), 업로드된 파일 경로 접근.
• 조치: 확장자 화이트리스트, 내용 시그니처 검사, 업로드 폴더 실행 차단, 파일명 서버 재지정.

2.5 인증 우회

• 어디를 보나: 로그인 후 페이지, 관리자 경로, 비밀번호 재설정, 다단계 인증 흐름.
• 재현: 관리자 주소 직접 입력(강제 브라우징), 응답·쿠키의 권한 값 변조, 재설정 토큰의 식별자 변경, 2차 인증 단계 건너뛰기.
• 조치: 인증·권한은 항상 서버에서 매 요청 확인. 클라이언트가 보낸 값은 불신. 재설정 토큰은 랜덤·만료·1회용.

2.6 정보 노출

• 어디를 보나: 에러 화면, .git·백업 파일, 디렉터리 리스팅, 응답 헤더의 서버 버전, 공개된 클라우드 저장소.
• 재현: 일부러 에러를 내 메시지 내용 확인, 알려진 경로(/.git/, /config.php.bak) 접근, 폴더 직접 접근으로 목록 노출 확인.
• 조치: 운영에선 상세 에러 숨김, 관리 파일 웹 차단, 리스팅 끄기, 헤더 정보 제거, 저장소 기본 비공개.

3. 진단 결과를 보고서로 쓰는 양식

찾는 것보다 정리해서 설명하는 것이 실력이다. 취약점 하나를 네 칸으로 쓴다.

항목	무엇을 쓰나
위치	어느 URL·파라미터·기능에서 발견했나
재현	어떤 입력·요청으로 어떻게 재현하나 (단계별)
위험도	상/중/하 + 왜 (무엇이 털리나)
조치	개발자가 무엇을 어떻게 고쳐야 하나

많이 찾는 것보다 두세 개를 이 양식으로 깔끔히 쓰는 게 낫다. 위험도는 “무엇이 노출/변조되나”로 근거를 대면 설득된다.

4. 말로 설명하는 연습

화면으로 “터졌다/안 터졌다”에서 끝내지 않고, 세 가지를 소리 내어 답해본다.

1. 어떤 순서로 접근했나 (무작정이 아니라 가설 → 확인)
2. 이게 왜 취약한가 (입력을 안 믿었나, 권한을 안 지켰나)
3. 개발자라면 어떻게 막나 (2절의 조치)

못 찾아도 접근 방식을 설명할 수 있으면 절반은 된 거다. 반사형 XSS를 내 검색창으로 찔러본 노트가 이 흐름의 실제 예다. 화면만 보지 않고 개발자도구로 왜 안 터지는지까지 확인했다.

5. 실습 환경

전부 무료이고, 반드시 내 환경 또는 연습용으로 만들어진 대상에서만 한다. 운영 중인 남의 사이트에 같은 시도를 하면 정보통신망법 위반이다.

도구	용도
DVWA (도커)	취약점 실습 대상, 난이도 조절 가능
OWASP Juice Shop (도커)	실제 서비스에 가까운 연습장
Burp Suite Community	요청 가로채기·수정·재전송
PortSwigger Web Security Academy	개념+브라우저 실습 랩
KISA 상세가이드	국내 진단 용어·기준

도커로 바로 올린다.

docker run -d --name dvwa -p 8080:80 vulnerables/web-dvwa
docker run -d --name juice -p 3000:3000 bkimminich/juice-shop

Burp는 내장 브라우저(Proxy 탭의 Open browser)를 쓰면 인증서 설정 없이 바로 된다. 첫 목표는 하나다. 로그인 요청을 가로채기 → 파라미터 수정 → Repeater로 재전송 → 응답 차이 보기. 이 흐름이 손에 익으면 나머지는 응용이다.

남은 것

• DVWA 난이도 Medium 이상에서 6개 재현 기록 남기기
• 각 취약점 실습을 로그로 분리 발행하고 여기서 링크로 묶기
• 보고서 양식으로 실제 작성 예시 1건 추가

용어: 웹셸은 웹으로 서버 명령을 실행하는 악성 파일. 디페이스는 웹사이트 화면 변조 공격. 매개변수 바인딩은 입력을 SQL 구조와 분리해 인젝션을 막는 방법. CSP(콘텐츠 보안 정책)는 브라우저에서 허용된 스크립트만 실행하게 하는 헤더.