어떤 업무용 웹 애플리케이션의 취약점 진단을 두 가지 도구로 진행해 보았습니다. 정석적인 DAST인 OWASP ZAP과, LLM 에이전트가 스스로 생각하며 공격하는 ARTEX입니다. 같은 앱을 진단했음에도 발견되는 항목들이 완전히 달랐기 때문에, 그 차이점을 정리하여 공유합니다.
0. 결론부터 말씀드리자면
- ZAP은 이미 알려진 취약점을 빠르고 광범위하게 조사하는 데 능숙합니다. 헤더 설정 누락이나 오래된 라이브러리 등이 해당됩니다. 빠르고 저렴하며, 매번 같은 결과가 나옵니다.
- ARTEX는 애플리케이션의 의미를 읽고 깊이 파고드는 데 능숙합니다. 권한의 구멍이나 다른 화면에서 발생하는 문제에 강점을 보입니다.
- 차이점의 근본은 '어디를 보고 있느냐'에 있습니다. ZAP은 기록된 요청을 변형하여 보내고 그 응답을 확인합니다. ARTEX는 애플리케이션의 구조를 읽고 다음에 시도할 것을 스스로 결정해 나갑니다.
- 어느 쪽이 우월하다고 할 수 없습니다. 두 가지를 조합하면 서로의 사각지대를 메울 수 있습니다.
1. 비교 대상
| OWASP ZAP | ARTEX |
|---|
| 종류 | 시그니처/룰 기반 DAST (Dynamic Application Security Testing) |
| ... | |
2. 직접 사용해 보니 알게 된 운영상의 차이점
ZAP: 선언적이고 매번 동일함
- Automation Framework의
plan.yaml에 작업을 나열만 해두면 실행됩니다. 같은 plan이라면 매번 같은 결과가 나오기 때문에 CI/CD 파이프라인에 적용하기 쉽습니다.
- SPA(Single Page Application)와의 궁합은 다소 아쉽습니다. 일반 스파이더로는 POST API를 거의 찾을 수 없었습니다. 이미 알려진 엔드포인트를
requestor로 하나씩 직접 알려줘야 했습니다.
- 인증이 필요한 스캔은 세 가지 방식으로 시도했습니다. 가장 안정적이었던 것은 폼(form) 기반의 인증 방식입니다. 로그아웃을 감지하면 자동으로 재로그인을 시도해 주었습니다. 쿠키를 고정적으로 전달하는 방식은 중간에 세션이 끊기면서 후반부가 완전히 비로그인 상태로 실행되었습니다.
- 'HTTP 200이면 성공'이라고 단정할 수 없습니다. 이 애플리케이션의 경우, 미로그인 상태에서도 200을 반환하며
{success:false}를 돌려줍니다. 실제로 통과했는지 여부는 응답 내용이나 DB 변화로 확인해야 합니다.
ZAP은 조건을 바꿔가며 총 3회 실행했습니다. 모든 회차에서 Passive(관찰만 하는 방식)와 Active(공격 요청을 보내는 방식)를 모두 수행했습니다.
| 회차 | 로그인 여부 | 쓰기 관련 API | 결과 |
|---|
| ① | 없음 | 대상 (미로그인이라 쓰기는 불가함) | 헤더 미비점이나 오래된 JS 라이브러리 등. ZAP의 성과는 거의 이 회차에서 나왔습니다 |
| ... | | | |
| 로그인을 하고 돌려도 ZAP의 성과는 크게 늘지 않았습니다. 타인의 데이터가 보이는 것과 같은 권한 문제는 수동 확인을 통해 발견했습니다. | | | |
관리자 계정으로 실행하면 삭제나 리셋이 실제로 수행됩니다. 쓰기 관련 API는 제외하고, 데이터를 망가뜨려도 괜찮은 환경에서 별도로 시도해 보는 것을 추천합니다.
ARTEX: 스스로 생각하며 매번 다름
- 목표를 주면 조사하기 → 가설 세우기 → 시도하기 과정을 스스로 반복합니다.
- 초기 설정 단계에서 막히기 쉽습니다. 모델이나 토큰 상한선 설정에 따라 출력이 빈 상태로 멈추는 경우가 있습니다.
- 실제로 값을 기록하며 확인하기 때문에 진단 대상의 데이터가 오염될 수 있습니다. 격리된 DB와 전후 스냅샷은 필수입니다.
ARTEXの探索グラフ模式図
ARTEX의 탐색 과정 (화면을 재현한 모식도이며 내용은 더미). 목표를 시도로 구체화하고, 사실로부터 소견을 이끌어냅니다. 한 번에 끝나지 않고, 결과를 단서 삼아 다음 시도를 만들어 수십 라운드 동안 깊이 파고듭니다.
3. 왜 발견되는 항목들이 다른가
차이가 가장 크게 나타난 문제 유형은 두 가지였습니다. 하나는 기록한 값이 다른 화면에서 문제를 일으키는 경우(Stored XSS)이고, 다른 하나는 타인의 데이터를 조작할 수 있는 경우(권한 미비점)입니다.
同じ道のりでも見ている範囲が違う図
저장된 값이 다른 화면에 나타나기까지의 과정. ZAP의 시야는 진입점 응답에서 끊기고, 문제가 발생한 저장소부터 다음은 사각지대가 됩니다. ARTEX는 출구까지 쫓아갑니다.
ZAP이 놓치는 이유
- 테스트하는 것은 기록된 요청에 포함된 항목들만입니다. 시드(seed)에 없는 항목은 단 한 번도 시도하지 않습니다.
- 보는 것은 그 순간의 응답뿐입니다. 작성한 곳과 표시되는 곳이 다르면 연결고리를 파악할 수 없습니다.
- '이 ID는 누구의 것인가'를 알지 못합니다. 따라서 권한 구멍은 원리적으로 지적하기 어렵습니다.
攻撃面と各ツールが触れる範囲の図
ZAP이 시도하는 것은 알려준 항목(파란색)뿐입니다. ARTEX는 화면의 의미로부터, 알려주지 않은 항목(주황색)까지 찾아냅니다.
ARTEX가 발견할 수 있었던 이유
- 화면의 의미로부터 테스트해야 할 항목을 찾아낸다.
- 통과하는 요청(request)을 스스로 구성하므로, 실제로 저장 단계까지 도달한다.
- "여기에 저장한 값이 어디에 나타날까"를 생각하며 다른 화면까지 확인해 나간다.
- ID를 타인의 것으로 변경해도 통과하는 것을 발견할 수 있다.
가상의 앱으로 예시하자면
레시피를 공유하는 앱으로 가정해 보겠습니다.
架空のレシピ共有アプリでの2つの例
둘 다 ZAP은 응답만 보고 끝내는 반면, ARTEX는 다른 화면까지 확인하러 간다.
4. 각각의 강점 및 약점
特性レーダー ZAP vs ARTEX
6가지 축으로 비교했다. ZAP은 포괄성(Coverage), 재현성(Reproducibility), 속도에 강하다. ARTEX는 시스템 이해, 권한 및 로직의 취약점, 화면 간 문제에 강하다. 전문 분야가 명확하게 나뉘었다.
ARTEX 측 3가지 축의 의미
- 앱 시스템 이해: 화면이나 기능의 목적을 파악하는 능력. "이 항목은 다른 사람에게도 보인다"와 같은 전제를 스스로 세운다.
- 권한/로직 취약점: 타인의 데이터가 보이거나, 절차를 건너뛸 수 있다. 같은 예상치 못한 움직임을 찾아내는 힘.
- 화면 간 문제 발견: 한 화면에서 입력한 값이 다른 화면에서 일으키는 문제를 추적하는 힘.
| 강점 | 약점 |
|---|
| ZAP | 알려진 취약점을 넓고 일정한 품질로 조사할 수 있다. 매번 같은 결과가 나와 CI에 적합하다. 무료이고 빠르다. |
| ARTEX | 의미를 읽고 테스트할 항목을 찾아낸다. 권한 및 로직의 취약점, 화면 간 문제까지 파고들 수 있다. |
5. 어떻게 사용해야 하는가
- CI 또는 정기 점검이라면 ZAP. 매번 같은 결과가 나오고 무료다.
- 릴리스 전 깊이 있는 진단이라면 ARTEX. 단, 격리된 환경에서 진행해야 한다.
- 추천 순서는 다음과 같다. 먼저 ZAP으로 설정 누락이나 오래된 라이브러리를 대략적으로 스캔한다. 다음 ARTEX로 권한 취약점이나 화면 간 문제를 깊이 파고든다. 마지막으로 나온 지적을 판별한다. 재현 확인이나 수정안 마련은 AI에게 맡길 수 있지만, 정말 위험한지, 언제 고칠지는 사람이 결정해야 한다.
6. 안전하게 진행하기 위한 요령
- 격리된 DB에서 실행한다. 전후에 모든 테이블의 행 수와 체크섬을 가져와 차이점을 본다.
- 실질적인 피해가 발생하는 기능은 제외한다. SMS나 이메일 전송, 삭제 또는 탈퇴, 결제, 로그아웃 등. ARTEX는 실제로 실행하므로 특히 주의해야 한다.
- HTTP 200을 성공으로 간주하지 않는다. 응답 내용이나 DB 변화로 확인한다.
- 로그아웃을 감지하고 다시 진입하는 메커니즘을 준비한다. 인증 기반 스캔의 누락이 줄어든다.
- ARTEX는 모델 선택이 지갑과 직결된다. 똑똑한 모델일수록 깊게 파주지만, 토큰 소모량도 엄청나다. 방치하면 12시간 동안 계속 파고들 수 있어 다음 날 아침 청구 금액에 눈을 뜨게 된다. 반면 저렴한 모델로 아끼면 이번에는 아무것도 파내지 못하고 끝날 수도 있다. 상황을 보면서 "여기까지만 충분하다"라고 손으로 멈춰주는 조력자가 필요하다.
- Claude에게 진단이나 분석을 도움 받으면 중간에 거부되는 경우가 있다. 이는 Claude 측의 보안 이용 제한이 작동하기 때문이며, 정상적인 검증에서도 발생한다. 작업이 끊어질 것을 전제로 계획하는 것이 좋다.
7. 요약
- ZAP은 기록된 요청을 변형하여 보내 그 자리의 응답을 본다. ARTEX는 앱의 의미를 읽고 결과를 확인하러 간다.
- 보는 위치가 다르기 때문에 발견할 수 있는 문제의 종류도 명확하게 나뉜다. 헤더나 알려진 CVE는 ZAP. 권한이나 로직의 취약점, 화면 간 문제는 ARTEX이다.
- 둘 중 하나만 사용하는 것이 아니라 둘 다 사용하는 것이 좋다. 넓고 얕게는 ZAP, 깊게는 ARTEX. 그리고 마지막에 "정말로 위험한지"를 결정하는 것은 사람의 일이다.
Discussion