Molayo

© 2026 Molayo

Dev.to헤드라인2026. 06. 08. 23:19

"Claude Code"가 당신의 모의 해킹(Pentesting)을 수행하게 하세요!

요약

Claude Code를 활용하여 IDOR, 인증, CSRF와 같은 보안 테스트 케이스를 수행하는 방법을 다룹니다. Burp Suite를 이용한 수동 테스트와 Claude Code를 이용한 자동화 테스트를 비교하며 AI의 실질적인 보안 테스트 효용성을 검증합니다.

핵심 포인트

  • Claude Code를 활용한 모의 해킹(Pentesting) 사례 분석
  • IDOR 취약점 탐지를 위한 자동화된 테스트 프로세스
  • 수동 도구(Burp Suite)와 AI 도구 간의 성능 및 한계 비교

AI가 보안 테스트(Security Testing)를 의미 있게 도울 수 있을까요, 아니면 그저 과장된 광고(Hype)일 뿐일까요? 이 포스트에서는 구체적인 사례를 살펴보겠습니다. 평소 Burp Suite를 사용하여 수동으로 수행하던 IDOR, 인증(Authentication), CSRF 테스트 케이스를 Claude Code를 사용하여 실행해 보고, 이를 통해 실제로 얻을 수 있는 이점과 한계가 어디인지 확인해 보겠습니다.

참고: 이 포스트는 제 YouTube 채널에서도 영상으로 확인하실 수 있습니다: https://youtu.be/JTk8brm6Zpc

테스트 케이스 (The Test Case)

테스트 대상 애플리케이션은 간단한 코드 조각(Snippet) 공유 웹 앱입니다 (소스 코드는 여기에서 확인 가능). 핵심 비즈니스 규칙은 간단합니다: 사용자는 자신의 코드 조각을 생성, 수정, 삭제할 수 있지만, 다른 사용자의 것은 할 수 없습니다. 보안 테스트 케이스 또한 매우 간단합니다: 이 규칙을 우회할 수 있는가?

이것은 전형적인 IDOR (Insecure Direct Object Reference, 부적절한 직접 객체 참조) 패턴입니다. 브라우저는 UI 수준에서 이 규칙을 강제합니다. 즉, 다른 사용자의 코드 조각에 대해서는 수정 버튼이 나타나지 않습니다. 하지만 문제는 백엔드(Backend)에서도 이 규칙을 강제하는지 여부입니다. 만약 제가 다른 사람의 코드 조각 ID를 포함한 PUT /snippets/:id 요청을 직접 만들어 전송한다면 어떤 일이 벌어질까요?

먼저 Burp Suite를 프록시(Proxy)로 사용하여 수동으로 테스트한 다음, Claude Code를 사용하여 정확히 동일한 단계를 반복합니다.

Snippet-sharing web app

수동 기준점 (The Manual Baseline)

Burp의 내장 브라우저를 통해 프록시로 트래픽을 라우팅하면, 테스트 흐름은 다음과 같습니다:

  • 로그인 후 코드 조각을 생성하고 수정합니다. 그러면 Burp의 HTTP 히스토리(HTTP history)에 PUT /snippets/:id 요청이 생성됩니다. 이를 찾아 Burp의 Repeater로 보냅니다.

Edit your snippet

Send resulting PUT request to repeater

  • GET /snippets 응답에서 다른 사용자가 소유한 스니펫 ID(is_owner: false)를 가져옵니다.

Get Id of snippet owned by a different user

  • 이전에 Repeater로 보낸 PUT 요청에서 원래 스니펫 ID를 다른 사용자가 소유한 ID로 교체합니다.

응답은 403 Forbidden입니다. 이는 권한 부여(authorization)가 작동하고 있음을 의미합니다. 동일한 테스트를 DELETE 엔드포인트에 수행하면 401 Unauthorized가 반환됩니다. IDOR는 없습니다.

IDOR blocked

Repeater에서 추가로 수행할 수 있는 두 가지 빠른 점검:

  • 인증(Authentication): 세션 쿠키를 유효하지 않은 값으로 교체 → 403 Forbidden. 애플리케이션이 인증되지 않은 요청을 올바르게 거부합니다.

Authentication test

  • CSRF 보호(CSRF protection): 동일한 변경 경로에 대해 CSRF-Token 헤더를 유효하지 않은 값으로 교체 → 403 Forbidden. CSRF 보호가 적용되어 있습니다.

CSRF test

주목할 만한 발견 사항 하나는 에러 응답(error responses)이 매우 상세하다는 점입니다. 즉, 프레임워크 이름(Express), 내부 파일 경로, 그리고 라이브러리 이름을 노출하고 있습니다. 이는 인증 결함(broken authentication)이나 CSRF 결함(broken CSRF)은 아니지만, 공격자에게 스택에 대한 불필요한 컨텍스트를 제공하는 정보 노출 (information disclosure) 취약점에 해당합니다.

Claude Code로 동일한 테스트 반복하기

여기에서의 목표는 Claude Code가 수동 작업(manual effort)을 줄이면서도 동일한 방법론을 따르고 동일한 결론에 도달할 수 있는지 확인하는 것입니다.

통합 아키텍처 (The Integration Architecture)

두 개의 MCP 서버가 이 작업을 가능하게 합니다:

Burp MCP — Claude Code가 Burp의 HTTP 히스토리 및 도구에 접근할 수 있게 해줍니다. 여기에는 캡처된 요청을 읽고 직접 조작된 HTTP 요청을 보낼 수 있는 기능이 포함됩니다. Burp Extensions 스토어에서 설치하거나 여기에서 다운로드한 후, Claude Code에 추가하세요:

claude mcp add --transport sse burp http://127.0.0.1:9876/ -s user

Playwright MCP — Claude Code가 프로그래밍 방식으로 제어할 수 있는 브라우저를 제공합니다. 중요한 세부 사항은, 모든 브라우저 활동이 수동 테스트와 동일하게 Burp의 히스토리에 캡처될 수 있도록 트래픽을 8080 포트의 Burp를 통해 라우팅하도록 구성해야 한다는 점입니다. 이는 아래 명령어에 표시된 것처럼 MCP를 추가할 때 --proxy-server=http://127.0.0.1:8080 및 --ignore-https-errors 옵션을 추가함으로써 수행할 수 있습니다.

claude mcp add playwright -s user -- npx @playwright/mcp@latest --proxy-server=http://127.0.0.1:8080 --ignore-https-errors

--ignore-https-errors는 통제된 테스트 환경에서는 괜찮습니다. 하지만 프로덕션(production) 환경에서는 절대 사용해서는 안 됩니다.

화이트박스(White-Box)의 이점

생각보다 더 중요한 세부 사항이 하나 있습니다. 바로 애플리케이션의 소스 코드 디렉토리에서 Claude Code 세션을 여는 것입니다. 이렇게 하면 Claude Code가 Burp MCP 도구와 애플리케이션의 소스 코드 모두에 동시에 접근할 수 있습니다. 이는 자칫 블랙박스(black-box) 테스트가 될 수 있었던 과정을 화이트박스(white-box) 테스트로 전환해 줍니다. Claude Code는 단순히 어떤 HTTP 상태 코드(HTTP status code)가 반환되었는지를 보고하는 것에 그치지 않고, 발견된 취약점이 원인이 된 특정 코드 라인까지 추적할 수 있습니다.

프롬프트 (The Prompt)

Claude Code에게 모호한 목표를 주는 대신, 우리가 수동으로 수행했던 것과 정확히 동일한 단계를 제공합니다:

Burp MCP를 사용하여 사용자가 다른 사용자의 공개 코드 스니펫(code snippets)을 삭제하거나 업데이트할 수 있는지 테스트하고 싶습니다. 다음 단계를 따르세요:
- Playwright 브라우저를 열고 README 파일에 있는 자격 증명으로 로그인하세요.
- 스니펫을 생성한 다음, 이를 수정하세요.
...

이 점이 중요합니다. 프롬프트는

Playwright 브라우저가 로그인하고, 테스트 스니펫 (test snippet)을 생성하고, Burp 히스토리에서 PUT 요청을 가져오고, 다른 사용자의 소유인 스니펫 ID를 찾아내고, Repeater 탭을 생성한 다음, send HTTP 도구를 사용하여 동일한 요청을 보냈습니다. 응답은 403 Forbidden이었으며, 이는 권한 부여 (authorization)가 올바르게 작동하고 있음을 의미합니다.

소스 코드를 살펴보면, [file]의 [line number] 라인에서 권한 부여가 강제되고 있습니다. 이곳에서는 업데이트나 삭제를 허용하기 전에 스니펫의 소유자 ID를 인증된 사용자의 ID와 비교합니다.

이것이 바로 구체화된 화이트박스 (white-box)의 이점입니다. 단순히 403이 반환되었음을 확인하는 것에 그치지 않고, 그 원인이 되는 코드를 직접 지목해 줍니다. 실제 침투 테스트 (engagement) 상황에서 이는 "문제를 발견함"과 "여기를 수정해야 함" 사이의 시간, 또는 이 경우에는 "보호 조치가 구현된 위치에 대한 확인" 사이의 시간을 크게 단축해 줍니다.

Claude Code 전체 응답

Claude Code response 1

Claude Code response 2

방법론을 기술 (Skill)로 패키징하기

방법론이 검증되면, 이를 적용할 때마다 전체 프롬프트 (prompt)를 다시 작성하고 싶지 않을 것입니다. Claude Code는 이름을 통해 호출할 수 있는 재사용 가능한 프롬프트 템플릿인 기술 (skills) 을 지원합니다. Claude Code에게 현재 세션을 기반으로 기술을 생성하도록 요청하세요:

Create a skill called "test-idor" based on the steps we followed in this session

다음에 다른 엔드포인트 (endpoint)나 다른 애플리케이션에서 동일한 IDOR 테스트를 실행하고 싶을 때, 방법론을 처음부터 다시 구성하는 대신 관련 컨텍스트 (context)와 함께 해당 기술을 호출하면 됩니다. 이것이 바로 AI 지원 침투 테스트 (AI-assisted pentesting)가 흥미로운 데모를 넘어 반복 가능한 워크플로 (workflow)로 진화하는 지점입니다.

이것이 유용한 경우 — 그리고 한계점

이 접근 방식은 다음과 같은 경우에 효과적입니다:

  • 여러 엔드포인트 (endpoints) 또는 애플리케이션에 걸쳐 일관되게 실행하고자 하는 정의된 방법론 (defined methodology) 이 있는 경우
  • 테스트 결과가 단순히 HTTP 계층 (HTTP layer)에서 관찰되는 것에 그치지 않고, 소스 코드 (source code)와 연결되기를 원하는 경우
  • 회귀 테스트 (regression testing) 를 수행하는 경우 — 즉, 코드 변경 후에도 이전에 테스트했던 제어 항목 (control) 이 여전히 유효한지 확인하는 경우

다음과 같은 경우에는 적합하지 않습니다:

  • 인간이 예상치 못한 무언가를 발견하고 그 실마리를 파고드는 과정에서 가치가 발생하는 탐색적 테스트 (Exploratory testing)
  • 각 단계가 사전에 지정하기 어려운 방식으로 이전 결과에 대한 추론에 의존하는 복잡한 다단계 공격 체인 (Complex multi-step attack chains)
  • 방법론 자체가 아직 개발 중인 모든 시나리오 — Claude Code에게 테스트를 요청하기 전에 무엇을 테스트할지 먼저 알고 있어야 합니다.

AI 자동 생성 콘텐츠

본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0