제로 코드 공격

분류 필요 **로직 플로우**, 또는 **비즈니스 로직 취약점**은 소프트웨어의 실행 흐름이나 설계상의 허점을 악용하여 개발자가 의도하지 않은 동작을 유발하는 컴퓨터 보안 취약점의 한 종류이다. 이러한 공격은 SQL 삽입이나 크로스 사이트 스크립팅(XSS)처럼 악성 코드를 시스템에 주입하는 방식이 아니라, 시스템이 제공하는 정상적인 기능을 비정상적인 순서나 방식으로 사용하여 보안을 우회하는 것이 특징이다.OWASP Foundation, "Business Logic Vulnerabilities". 2020-12-04. Retrieved 2025-09-11. 로직 플로는 애플리케이션의 특정 비즈니스 규칙에 따라 고유하게 나타나므로, 자동화된 취약점 스캐너로는 탐지하기가 매우 어렵다. 공격자는 애플리케이션의 작동 방식을 깊이 이해하고 논리적 모순을 찾아내야 하므로, 정교한 수동 테스트나 코드 검토가 요구된다.
# 특징
로직 플로우는 다른 기술적 취약점과 구별되는 몇 가지 주요 특징을 가진다. * **무(無)코드 공격**: 공격자는 악성 스크립트나 셸코드를 사용하지 않는다. 대신, 애플리케이션에 합법적인 요청을 보내지만, 그 순서나 값을 조작하여 예상치 못한 결과를 이끌어낸다. * **문맥 의존성**: 취약점은 애플리케이션의 고유한 비즈니스 로직(예: '쇼핑몰 결제 절차', '비밀번호 찾기 기능')에 깊이 의존한다. 따라서 한 애플리케이션에서 발견된 로직 플로가 다른 애플리케이션에는 존재하지 않을 수 있다. * **탐지 어려움**: 기존의 침입 탐지 시스템(IDS)이나 웹 애플리케이션 방화벽(WAF)은 알려진 공격 패턴(시그니처)을 기반으로 악성 입력을 탐지한다. 하지만 로직 플로 공격에 사용되는 요청은 정상적인 사용자의 요청과 구별하기 어렵기 때문에 이러한 시스템을 쉽게 우회할 수 있다.PortSwigger Web Security Academy, "Business logic vulnerabilities". Retrieved 2025-09-11.
# 유형 및 사례
로직 플로는 다양한 형태로 나타날 수 있으며, 주로 애플리케이션의 기능, 상태 관리, 워크플로우의 허점을 이용한다.
## 기능 및 워크플로우 악용
애플리케이션의 다단계 프로세스에서 특정 단계를 건너뛰거나 순서를 조작하여 보안 검증을 우회하는 공격이다. ; 쇼핑몰 가격 조작 사례 # 사용자가 고가의 상품 A($1,000)를 장바구니에 담고 결제 페이지로 이동한다. # 서버는 이 단계에서 상품 A의 가격을 세션에 저장한다. # 사용자는 새 탭에서 저가의 상품 B($1)를 장바구니에 추가한다. 이때 서버의 세션 정보가 상품 B의 가격으로 갱신될 수 있다. # 사용자는 원래의 결제 페이지로 돌아가서 결제를 진행한다. 만약 서버가 최종 결제 단계에서 상품 ID와 가격을 다시 검증하지 않는다면, 사용자는 고가의 상품 A를 저가 상품 B의 가격($1)으로 구매할 수 있다. 이 공격은 악성 코드를 전혀 사용하지 않았으며, 오직 애플리케이션의 정상적인 기능(장바구니 추가, 결제)을 비정상적인 순서로 조합하여 발생했다.
## UI 캐싱 오류를 이용한 정보 유출
사용자 인터페이스(UI)와 관련된 캐싱 메커니즘의 설정 오류나 설계 결함을 이용하는 공격이다. 대표적인 예로 '웹 캐시 디셉션'이 있다. ; 웹 캐시 디셉션(Web Cache Deception) 사례 웹 캐시 디셉션은 서버나 중간의 프록시 서버(CDN 등)가 동적이고 민감한 사용자 페이지를 정적 파일로 착각하여 공개적으로 캐싱하도록 유도하는 공격이다.S. Herzog, "Web Cache Deception Attack," Imperva, 2017. Available online. # 공격 대상 웹사이트 `example.com`은 사용자의 민감한 정보(예: 이름, 이메일 주소)를 보여주는 `/profile` 페이지가 있다. # 웹 서버 앞단의 캐시 서버는 `.css`, `.js`와 같은 특정 확장자를 가진 요청에 대한 응답을 공개적으로 캐싱하도록 설정되어 있다. # 공격자는 로그인된 피해자에게 악성 링크 `https://example.com/profile/photo.css`를 클릭하도록 유도한다. # 웹 애플리케이션 서버는 `/profile` 경로에 대한 요청으로 인식하고, 피해자의 개인정보가 담긴 HTML 페이지를 응답으로 생성한다. # 하지만 캐시 서버는 요청된 URL이 `.css`로 끝나므로, 이 민감한 HTML 응답을 정적 CSS 파일로 착각하고 자신의 캐시에 저장한다. # 이후 공격자는 캐시된 URL `https://example.com/profile/photo.css`에 직접 접속하여 피해자의 개인정보가 담긴 페이지를 탈취한다. 이 공격 역시 악성 코드가 아닌, URL 구조와 캐싱 시스템의 논리적 허점을 이용한 것이다.
## 과도한 신뢰 기반의 설계 오류
서버가 클라이언트로부터 받은 데이터를 충분히 검증하지 않고 신뢰할 때 발생하는 문제이다. ; 비밀번호 재설정 기능 악용 사례 # 공격자가 피해자의 ID로 비밀번호 재설정을 요청한다. # 서버는 비밀번호 재설정 링크를 생성하여 피해자의 이메일로 발송한다. 이때 링크 생성 요청의 HTTP 헤더에 공격자의 도메인을 포함하여 보낸다. (예: `Host: attacker.com`) # 만약 서버가 재설정 링크(예: `https://[HOST]/reset?token=...`)를 생성할 때 `Host` 헤더의 값을 검증 없이 그대로 사용한다면, 피해자에게 전송되는 이메일에는 `https://attacker.com/reset?token=...`과 같은 링크가 포함된다. # 피해자가 이 링크를 클릭하면, 비밀번호 재설정 토큰이 공격자의 서버로 전송되고, 공격자는 이를 이용해 계정을 탈취할 수 있다.
# 방어 방안
로직 플로를 방어하기 위해서는 기술적인 보안 솔루션뿐만 아니라, 설계 단계부터 비즈니스 로직의 잠재적 허점을 분석하는 것이 중요하다. * **위협 모델링**: 애플리케이션의 모든 기능과 워크플로우를 분석하여 각 단계에서 발생할 수 있는 논리적 위협 시나리오를 사전에 식별하고 대응책을 마련한다. * **서버 측 데이터 검증 강화**: 클라이언트로부터 전송되는 모든 데이터(가격, 수량, 권한 등)는 신뢰할 수 없는 것으로 간주하고, 모든 중요 작업 단계에서 서버 측에서 해당 데이터의 유효성을 다시 검증해야 한다. * **엄격한 워크플로우 적용**: 사용자가 특정 단계를 건너뛰거나 비정상적인 순서로 페이지에 접근할 수 없도록 상태를 철저히 관리한다. 예를 들어, 결제 완료 페이지는 반드시 유효한 결제 ID를 가진 세션에서만 접근할 수 있도록 제한해야 한다. * **개발자 교육**: 개발자들이 자신이 구현하는 비즈니스 로직이 어떻게 악용될 수 있는지 이해하도록 보안 코딩 및 설계 교육을 수행한다.
# 관련 문서
* OWASP