자동 스캐너는 알려진 패턴 — 오래된 버전, 설정 오류, 단순 인젝션 — 을 잘 찾습니다. 그런데 요즘 실제 사고의 큰 부분은 스캐너가 '정상 응답' 으로 보는 곳에서 납니다. 남의 주문서를 번호만 바꿔 열어 보는 것(IDOR), 서버가 내부 주소로 대신 요청하게 만드는 것(SSRF), 쿠폰을 두 번 쓰는 것. 이런 로직 취약점은 사람이 기능을 이해하고 손으로 눌러 봐야 나옵니다. 점검자가 어디부터 보는지 유형별로 적습니다. 허가된 범위 안에서의 점검을 전제로 합니다.
1. IDOR — 가장 흔하고 가장 단순한
점검의 기본 도구는 계정 두 개입니다. A 로 주문 상세를 열고 그 요청(예: GET /api/orders/10234)을 잡은 뒤, B 의 세션으로 번호만 바꿔 보냅니다. 읽기는 막혀 있어도 수정(PUT)·삭제(DELETE)·내보내기(export)는 열려 있는 경우가 많으니 메서드별로 봅니다. 파일 다운로드 주소, 영수증 PDF, 프로필 이미지처럼 '부속' 자원이 자주 빠집니다. 식별자가 UUID 라고 안전한 것은 아닙니다 — 어딘가(목록 API·공유 링크·로그)에 노출되면 같습니다.
2. SSRF — 서버가 대신 요청하는 모든 곳
URL 을 입력받아 서버가 가져오는 기능 — 프로필 이미지 URL, 링크 미리보기, 웹훅 주소 등록, HTML→PDF 변환, 가져오기(import) — 이 대상입니다. http://127.0.0.1:…, 내부 대역, 클라우드 메타데이터 주소를 넣어 응답이 달라지는지(시간 차이·오류 메시지 포함) 봅니다. 리다이렉트를 따라가는지도 확인합니다 — 허용된 도메인이 내부 주소로 리다이렉트하면 우회가 됩니다.
3. 권한 상승 — 화면이 아니라 API
관리자 메뉴가 안 보이는 것과 관리자 API 가 막힌 것은 다릅니다. 관리자 계정으로 기능을 쓰며 요청을 모은 뒤, 같은 요청을 일반 계정 세션으로 보냅니다. 프런트엔드가 역할을 판단하고 서버는 믿는 구조에서 자주 뚫립니다.
4. 업무 로직 — 기능을 '잘못 쓰는' 방법 찾기
- 수량에 0·음수·소수, 가격 파라미터가 요청에 들어 있는지 (서버가 다시 계산하는지)
- 쿠폰·포인트를 결제 단계에서 두 번 적용, 적용 뒤 상품 바꾸기
- 본인인증·약관 동의 단계를 건너뛰고 다음 단계 API 호출
- 비밀번호 재설정 토큰의 만료·재사용·추측 가능성
5. 경쟁 조건 — 동시에 보내 본다
잔액 차감, 쿠폰 사용, 선착순 응모처럼 '한 번만' 이어야 하는 요청을 같은 순간에 여러 개 보냅니다. 프록시 도구의 병렬 전송 기능으로 확인합니다. 두 번 처리되면 서버에 잠금이나 멱등 처리가 없는 것입니다.
개발자에게 넘길 때
로직 취약점은 '이 줄을 고치세요' 보다 '이 검사가 서버에 없습니다' 로 전달하는 편이 정확합니다. 재현 요청/응답 쌍과 함께 넘기면 대부분 바로 이해합니다.
스캐너는 '알려진 것' 을 찾고, 사람은 '이 서비스에서만 생기는 것' 을 찾습니다. 로직 취약점 점검의 절반은 기능을 사용자처럼 끝까지 써 보는 데서 시작합니다.
댓글