GOTROOT / 모의해킹

웹 취약점 점검, 실제로 어디가 뚫릴까 — 현장에서 늘 같은 자리 | GOTROOT

체크리스트는 많지만 실제로 뚫리는 곳은 늘 비슷합니다. 인가·입력·세션·로직과 더불어, 서비스가 기대는 컴포넌트의 알려진 취약점까지 — 스캐너가 잘 잡는 것과 사람이 봐야 하는 것을 실제 요청/응답 예시와 함께 정리했습니다.

GOTROOT 리서치 팀 2026. 6. 5.

웹 점검을 오래 하다 보면 한 가지를 깨닫게 됩니다. 취약점 ‘종류’는 수백 가지지만, 실제로 사고가 나는 자리는 늘 비슷하다는 점입니다. 그래서 이 글은 “모든 항목”을 나열하기보다, 저희가 현장에서 거의 매번 다시 들여다보게 되는 자리들을 솔직하게 적어보려 합니다. 점검을 준비하시는 분들께 참고가 되면 좋겠습니다.

스캐너가 잘 잡는 것, 사람이 봐야 하는 것

먼저 짚어두고 싶은 건, 자동 스캐너가 결코 쓸모없지 않다는 점입니다. 오히려 반사형 XSS나 알려진 설정 오류처럼 ‘패턴이 분명한’ 결함은 스캐너가 사람보다 빠르고 꼼꼼합니다. 다만 맥락이 필요한 곳은 사람이 거들어야 합니다.

스캐너가 잘 잡는 편	사람이 봐야 하는 편
반사형 XSS, 알려진 CVE, 헤더·설정 누락	접근통제(IDOR/BOLA) — “이 요청이 허용돼야 하나?”
디렉터리 노출, 기본 자격증명	비즈니스 로직 — 결제·쿠폰·단계 건너뛰기
오래된 라이브러리 ‘버전’ 표시	그 버전이 이 설정에서 ‘실제로’ 악용되는지

가장 자주 다시 보는 자리: 접근통제

경험상 가장 흔하고, 가장 조용히 위험한 곳입니다. 로그인은 잘 막아두었는데, 로그인 ‘이후’에 “이 사람이 이 데이터를 봐도 되는가”를 확인하지 않는 경우죠. 식별자 하나만 바꿔도 남의 정보가 보이는지 두 계정으로 비교합니다.

// 내 계정(A)의 세션으로, 남(B)의 인보이스를 요청해 봅니다
GET /api/invoices/10024 HTTP/1.1
Cookie: session=<사용자 A>

// 응답이 이렇게 온다면 — 접근통제 결함입니다 (정상이라면 403/404)
HTTP/1.1 200 OK
{ "id": 10024, "owner": "user_B", "amount": 480000, ... }

숫자 ID만의 이야기가 아닙니다. “추측 불가능해 보이는” UUID도 다른 화면·로그·열거를 통해 흘러나오는 경우가 많아, 식별자의 무작위성만으로는 인가를 대신할 수 없습니다.

입력이 코드가 되는 지점

신뢰 경계를 넘은 입력이 쿼리·명령·요청으로 해석되는 곳을 봅니다. 반사형은 자동화로도 잘 잡히지만, 저장형·블라인드·2차 인젝션은 손으로 확인해야 할 때가 많습니다. 아래는 점검에서 자주 쓰는 확인용 입력들입니다.

# SQLi (블라인드, 참/거짓으로 응답 변화를 관찰)
id=10 AND 1=1      → 정상
id=10 AND 1=2      → 응답이 달라짐 → 주입 가능 신호

# 저장형 XSS (입력이 다른 사용자 화면에서 실행되는지)
<img src=x

# SSRF (서버가 내부로 요청하도록 유도 — 클라우드에선 특히 치명적)
url=http://169.254.169.254/latest/meta-data/

세션과 비즈니스 로직

세션은 토큰의 엔트로피, 로그아웃·만료 처리, 쿠키 속성(HttpOnly·Secure·SameSite), 상태 변경 요청의 CSRF 방어를 봅니다. 그리고 스캐너가 결코 알 수 없는 영역이 비즈니스 로직입니다 — 결제 금액 변조, 수량·할인 음수, 승인 단계 건너뛰기, 쿠폰을 동시에 여러 번 쓰는 경쟁 상태처럼 ‘의도된 흐름을 깨는’ 시나리오는 사람이 직접 설계해 확인합니다.

한 걸음 더 — 우리가 기대고 있는 컴포넌트

코드가 깨끗해도, 그 웹 서비스가 올라가 있는 프레임워크·라이브러리·플러그인 하나가 입구가 되는 경우가 많습니다. 실제 표적 공격(APT)도 바로 이 지점을 노립니다. 그래서 저희는 점검할 때 사용 중인 컴포넌트와 버전을 식별하고, 공개된 보안 권고문에 해당하는지 대조한 뒤, ‘이 설정에서 실제로 악용되는지’를 통제된 범위에서 확인합니다. 막 공개된 패치를 거꾸로 읽어 익스플로잇을 재구성하는 1-day 관점이 여기에 들어갑니다.

이 과정이 궁금하시면 0-day는 어떻게 발굴되는가 글에 패치 디핑부터 정리해 두었습니다. “버전이 낮다”가 아니라 “이렇게 악용됩니다”까지 보여드리는 게 목표입니다.

현장 노트: 보고서를 받으신 개발자분이 가장 반가워하시는 건 ‘재현 절차’입니다. 같은 요청을 그대로 따라 해 결함을 눈으로 확인하면, 고치는 속도가 확연히 빨라지더라고요.

자주 묻는 질문

자동 스캐너만으로는 부족한가요?

패턴이 분명한 결함엔 스캐너가 효율적입니다. 다만 접근통제·비즈니스 로직·체이닝처럼 맥락 판단이 필요한 곳은 사람의 확인이 더해져야 안심할 수 있습니다.

점검은 얼마나 자주 받으면 좋을까요?

연 1회 정기 점검에, 인증 구조나 주요 기능이 크게 바뀔 때 추가 점검을 권해드립니다. 변경이 곧 새로운 틈이 생기는 순간이라서요.

마치며

좋은 점검은 항목을 채우는 일이 아니라, 실제로 뚫리는 자리를 우선순위로 짚어드리는 일인 것 같습니다. 우리 서비스가 어디까지 버티는지 함께 확인해 보고 싶으시면 편하게 모의해킹 상담으로 물어봐 주세요.