제 블로그의 모든 글들은 해킹과 보안에 대한 학습용 글입니다.

해당 글을 보고 실제 홈페이지에 공격하는 것은 명백한 범죄행위임을 알려드리며,

절대로 실제 홈페이지에 공격하지 마시기 당부드립니다. 실제 공격한 부분에 대한 책임은

본인이 지셔야 하며, 블로그를 통해 공유한 블로거와는 무관함을 알려드립니다.

안녕하세요. 이번 포스팅에서는 지난 ARTEX AI 설치 및 MCP 연동 실습에 이어, 실제 웹사이트를 대상으로 AI 기반 보안 진단을 수행한 과정을 공유하겠습니다.

지난번에는 ARTEX AI를 Windows 환경에 설치하고 Playwright Browser MCP와 OWASP ZAP MCP를 연결하는 데 성공했습니다.

하지만 도구가 연결되었다고 해서 AI가 곧바로 웹 취약점을 찾아주는 것은 아니었습니다.

브라우저로 웹사이트를 탐색해도 ZAP에 HTTP 요청이 기록되지 않았고, ZAP에 기록이 있어도 MCP가 일부 상세 데이터를 읽지 못하는 문제가 발생했습니다.

이번에는 이러한 문제를 해결하면서 웹 취약점 진단과 보고서 작성까지 진행했습니다.

이번 실습은 2026년 10월 말부터 11월 4일까지 진행한 내용을 정리한 것입니다.

1. 이번 실습의 목표

이번 실습에서는 다음과 같은 목표를 세웠습니다.

1. Python으로 로컬 웹 보안 실습 서버 구축
2. OWASP ZAP을 이용한 HTTP 응답 헤더 점검
3. 보안 헤더 설정 전후 비교
4. ARTEX AI와 Playwright MCP를 통한 외부 테스트 사이트 구조 분석
5. Playwright 브라우저의 HTTP 요청을 ZAP 프록시로 전달
6. ZAP 패시브 스캔 결과 분석
7. AI가 탐지한 취약점의 오탐 가능성 검토
8. AI를 활용한 웹 취약점 진단 보고서 작성

실습 과정에서 Spider, Active Scan, SQL Injection 및 XSS 공격 페이로드는 실행하지 않았습니다.

외부 테스트 사이트에서는 정상적인 페이지 요청과 이미 수집된 HTTP 응답에 대한 패시브 분석을 수행했습니다.

2. 실습 환경 구성

이번 실습에 사용한 환경은 다음과 같습니다.

구분실습 환경

ARTEX에는 Playwright Browser MCP 도구 25개와 OWASP ZAP MCP 도구 17개가 연결되어 있었습니다.

이 환경에서 ARTEX는 AI 분석과 도구 실행을 담당하고, Playwright는 브라우저 탐색을, ZAP은 HTTP 통신 수집 및 보안 경고 탐지를 담당하도록 구성했습니다.

3. Python으로 로컬 웹 보안 실습 서버 구축

먼저 Windows에서 로컬 웹 서버를 실행했습니다.

실습 폴더는 다음과 같이 구성했습니다.

C:\AI-Security-Lab
 ├─ index.html
 └─ secure_server.py

초기 서버는 Python의 기본 HTTP 서버를 이용했습니다.

python -m http.server 8000 --bind 127.0.0.1

이후 웹 브라우저에서 다음 주소에 접속했습니다.

http://127.0.0.1:8000/

실습 페이지에는 검색 기능과 로그인 테스트용 입력 폼을 구성했습니다.

초기 HTML에는 다음과 같은 로그인 폼이 있었습니다.

<form action="/" method="GET">
    <input name="username" placeholder="아이디">
    <input name="password" type="password">
    <button type="submit">로그인 테스트</button>
</form>

여기서 보안상 문제가 발견되었습니다.

로그인 폼이 GET 방식으로 구성되어 있기 때문에 비밀번호를 입력하고 제출하면 해당 값이 URL의 쿼리 문자열에 포함될 수 있습니다.

이는 브라우저 방문 기록이나 프록시 로그 등에 민감정보가 남을 위험을 증가시킵니다.

실습에서는 실제 비밀번호를 제출하지 않고 HTML 구조만 확인했습니다.

실제 서비스에서는 POST 방식과 HTTPS를 사용하고, 서버 측에서 인증정보를 안전하게 처리해야 합니다.

4. OWASP ZAP으로 로컬 서버 보안 점검

다음으로 ZAP 프록시를 경유하여 로컬 웹 서버에 요청을 전송했습니다.

Windows CMD에서 다음 명령어를 실행했습니다.

curl.exe --noproxy "" --proxy http://127.0.0.1:8080 http://127.0.0.1:8000/

ZAP History에서 HTTP 200 OK 응답을 확인했습니다.

초기 서버의 응답 헤더에는 다음 정보가 포함되어 있었습니다.

HTTP/1.0 200 OK
Server: SimpleHTTP/0.6 Python/3.14.7
Content-type: text/html

이 응답에는 Python 버전이 노출되어 있었고, 주요 브라우저 보안 헤더도 설정되지 않았습니다.

ZAP 패시브 스캔에서 다음 네 가지 경고가 확인되었습니다.

점검 항목위험도

이 단계에서는 실제 공격 가능성을 검증한 것이 아니라, 응답 헤더의 보안 설정 미흡 사항을 확인한 것입니다.

5. Python 웹 서버 보안 헤더 개선

이제 직접 서버 설정을 변경했습니다.

Python의 SimpleHTTPRequestHandler를 상속하여 보안 헤더를 추가하는 방식입니다.

from http.server import HTTPServer, SimpleHTTPRequestHandler
from functools import partial

class SecureHandler(SimpleHTTPRequestHandler):
    server_version = "SecurityLab"
    sys_version = ""

    def end_headers(self):
        self.send_header("X-Frame-Options", "DENY")
        self.send_header("X-Content-Type-Options", "nosniff")
        self.send_header(
            "Content-Security-Policy",
            "default-src 'self'; frame-ancestors 'none'; "
            "form-action 'self'; base-uri 'self'"
        )
        super().end_headers()

handler = partial(
    SecureHandler,
    directory=r"C:\AI-Security-Lab"
)

server = HTTPServer(("127.0.0.1", 8000), handler)
print("Secure Web Server: http://127.0.0.1:8000")
server.serve_forever()

파일명은 secure_server.py로 저장했습니다.

실행 명령어는 다음과 같습니다.

python C:\AI-Security-Lab\secure_server.py

서버 실행 후 ZAP 프록시를 경유하여 다시 요청했습니다.

curl.exe --noproxy "" --proxy http://127.0.0.1:8080 -i http://127.0.0.1:8000/

실제 응답에서 다음 보안 헤더가 확인되었습니다.

HTTP/1.0 200 OK
Server: SecurityLab
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Content-Security-Policy: default-src 'self'; frame-ancestors 'none'; form-action 'self'; base-uri 'self'

개선 전후 결과는 다음과 같습니다.

점검 항목 개선 전, 개선 후

실제 HTTP 응답에서 설정이 적용된 사실을 확인했습니다.

다만 Python의 기본 HTTP 서버는 운영환경용 웹 서버가 아니므로, 이 코드는 로컬 학습 목적으로만 사용하는 것이 적절합니다.

또한 로그인 폼의 GET 방식 문제는 이 단계에서 수정하지 않았습니다.

6. ARTEX AI의 ZAP MCP 조회 오류 경험

보안 헤더 개선 후 ARTEX AI에게 ZAP History를 분석하도록 지시했습니다.

그런데 예상과 다른 결과가 나왔습니다.

ZAP 프로그램에서는 HTTP 200 응답이 확인되었지만, ARTEX의 MCP 조회에서는 일부 History 상세 기록을 읽지 못했습니다.

실제 오류는 다음과 같았습니다.

Error: mcp: decode json response: unexpected EOF

ARTEX는 상세 기록을 읽지 못한 상태에서 보안 헤더가 미적용된 것처럼 보고하기도 했습니다.

하지만 CMD에서는 이미 보안 헤더 적용을 확인한 상태였습니다.

여기서 중요한 교훈을 얻었습니다.

AI 도구가 데이터를 읽지 못했다는 사실과 실제 보안 설정이 존재하지 않는다는 사실은 전혀 다릅니다.

따라서 보안 컨설턴트는 AI 분석 결과를 그대로 받아들이기보다 원본 HTTP 응답과 진단 증적을 직접 확인해야 합니다.

7. 외부 ASP.NET 테스트 사이트 분석

다음으로 ASP.NET 웹 보안 실습용 사이트를 분석했습니다.

대상 사이트는 다음과 같습니다.

http://testaspnet.vulnweb.com/

ARTEX의 Playwright Browser MCP를 이용하여 메인 페이지에 접속하고 HTML 구조를 수집했습니다.

분석 결과는 다음과 같았습니다.

분석 항목결과

링크 목록에서는 뉴스, 댓글, 로그인, 회원가입 등의 페이지가 확인되었습니다.

또한 일부 링크에는 id 파라미터가 포함되어 있었습니다.

이러한 파라미터는 SQL Injection 등의 점검 대상이 될 수 있지만, 단순히 파라미터가 존재한다고 해서 취약점이 있는 것은 아닙니다.

이번 실습에서는 SQL Injection 및 XSS 공격을 수행하지 않았으므로 해당 항목은 취약점 후보로만 분류했습니다.

8. Playwright와 OWASP ZAP 프록시 연동 문제 해결

외부 사이트의 구조 분석은 성공했지만, 처음에는 ZAP History에 HTTP 요청이 기록되지 않았습니다.

원인은 Playwright Browser MCP에 ZAP 프록시가 설정되지 않았을 가능성이 높았습니다.

ARTEX의 MCP 설정에서 기존 실행 인자는 다음과 같았습니다.

-y @playwright/mcp --headless

여기에 프록시 설정을 추가했습니다.

-y @playwright/mcp --headless --proxy-server=http://127.0.0.1:8080

설정을 저장한 뒤 다시 사이트에 접속했습니다.

이번에는 ZAP History에서 다음 요청이 확인되었습니다.

항목실제 결과

드디어 Playwright가 발생시킨 HTTP 요청을 ZAP에서 수집하는 데 성공했습니다.

이때부터 ARTEX와 ZAP을 연계한 보안 분석이 가능해졌습니다.

9. OWASP ZAP 패시브 스캔 결과

ZAP의 경고 화면에서 총 10종류의 보안 경고가 확인되었습니다.

번호경고 항목위험도

이는 ZAP에서 탐지한 경고 유형 10개를 의미합니다. 실제 공격으로 입증된 취약점 10개라는 의미는 아닙니다.

특히 정보성 경고는 반드시 취약점으로 분류되는 것은 아닙니다.

10. 실제 HTTP 응답 헤더 분석

ZAP에 수집된 응답에는 다음과 같은 정보가 포함되어 있었습니다.

HTTP/1.1 200 OK
Cache-Control: private
Content-Type: text/html; charset=utf-8
Server: Microsoft-IIS/8.5
X-AspNet-Version: 2.0.50727
Set-Cookie: ASP.NET_SessionId=...; path=/; HttpOnly
X-Powered-By: ASP.NET

이 응답을 통해 다음과 같은 보안 설정 미흡 사항을 확인했습니다.

첫째, 서버와 프레임워크 버전 정보가 노출되었습니다.

둘째, 세션 쿠키에 SameSite 속성이 명시되어 있지 않았습니다.

셋째, CSP와 클릭재킹 방지 헤더 및 X-Content-Type-Options 헤더가 확인되지 않았습니다.

다만 응답 헤더에 표시된 버전만으로 실제 서버의 패치 수준이나 알려진 취약점의 악용 가능성을 확정할 수는 없습니다.

또한 SameSite 속성 누락이 곧바로 세션 탈취를 의미하는 것도 아닙니다.

보안 진단에서는 이러한 차이를 구분해야 합니다.

11. 가장 중요한 실습: CSRF 오탐 가능성 분석

이번 실습에서 가장 흥미로웠던 항목은 다음 경고였습니다.

Absence of Anti-CSRF Tokens
Risk: Medium
CWE-352

ZAP은 HTML의 POST 폼에서 일반적인 Anti-CSRF 토큰을 찾지 못했습니다.

그런데 해당 사이트는 ASP.NET Web Forms를 사용하고 있었고, HTML에는 다음 필드가 존재했습니다.

<input type="hidden" name="__VIEWSTATE" ...>
<input type="hidden" name="__EVENTVALIDATION" ...>

여기서 주의할 점이 있습니다.

__VIEWSTATE는 주로 페이지 상태 유지와 무결성 보호에 사용됩니다.

__EVENTVALIDATION은 허용된 이벤트 및 입력값의 유효성을 검증하는 기능입니다.

두 기능 모두 CSRF 방어를 직접 보장하는 전용 토큰은 아닙니다.

ASP.NET에서는 사용자별 ViewStateUserKey 설정이나 별도의 CSRF 토큰 검증 등으로 방어를 강화할 수 있습니다.

따라서 단순히 ViewState와 EventValidation이 존재한다는 이유로 CSRF 취약점이 없다고 판단해서는 안 됩니다.

반대로 ZAP이 토큰을 탐지하지 못했다는 이유만으로 실제 CSRF 공격이 가능하다고 확정해서도 안 됩니다.

이번 진단에서는 해당 항목을 추가 검증 필요로 분류했습니다.

12. ARTEX AI를 이용한 취약점 진단 보고서 작성

이후 ARTEX AI에게 지금까지 수집한 ZAP 데이터를 기반으로 웹 취약점 진단 보고서를 작성하도록 지시했습니다.

보고서에는 다음 내용을 포함하도록 했습니다.

• - 취약점명 및 위험도
• - 대상 URL
• - 취약점 현황
• - 판정 근거
• - 보안 영향
• - 조치 방안
• - 재진단 방법

ARTEX는 보안 헤더 누락, 쿠키 속성 미흡, 서버 정보 노출, CSRF 추가 검증 항목을 구분하여 보고서 초안을 작성했습니다.

하지만 AI가 작성한 보고서에서도 기술적으로 부정확한 표현이 일부 발견되었습니다.

예를 들어 SameSite 누락을 세션 탈취와 직접 연결하거나, ViewState와 EventValidation의 존재를 CSRF 방어의 충분한 근거처럼 설명하는 부분이 있었습니다.

따라서 최종 보고서에서는 이러한 표현을 수정했습니다.

실무 보고서에 사용할 수 있는 종합 의견 예시는 다음과 같습니다.

웹 보안 진단 종합 의견

본 진단은 OWASP ZAP 패시브 스캔 및 HTTP 응답 분석을 통해 웹 애플리케이션의 보안 설정 현황을 점검하였으며, 주요 보안 헤더 미설정, 세션 쿠키 보안 속성 미흡, 웹 서버 및 프레임워크 정보 노출 등의 사항을 확인하였다.

또한 ASP.NET Web Forms 기반 POST 요청 처리 구간에서 일반적인 Anti-CSRF 토큰이 식별되지 않았으나, 서버 측 CSRF 방어 구현 여부가 확인되지 않아 해당 항목은 추가 검증이 필요한 사항으로 분류하였다.

확인된 보안 설정 미흡 사항에 대해서는 서비스 운영 특성을 고려한 보안 정책 적용 및 불필요한 시스템 정보 노출 최소화를 권고한다.

본 진단 결과는 수집된 HTTP 응답 및 패시브 스캔 증적을 기준으로 작성되었으며, SQL Injection, XSS 등 능동적 검증이 필요한 취약점의 존재 여부를 판단하는 근거로 활용할 수 없다.

13. 이번 실습에서 배운 점

이번 실습을 통해 AI 보안 진단 자동화의 가능성과 한계를 모두 경험할 수 있었습니다.

첫 번째는 MCP 연결만으로 자동화가 완성되지 않는다는 점입니다.

Playwright와 ZAP을 연결했더라도 프록시 설정이 누락되면 브라우저의 HTTP 요청을 ZAP에서 분석할 수 없었습니다.

두 번째는 AI의 분석 결과를 반드시 검증해야 한다는 점입니다.

MCP 데이터 조회 오류로 인해 실제 적용된 보안 헤더를 AI가 확인하지 못하는 상황이 발생했습니다.

세 번째는 보안 경고와 실제 취약점을 구분해야 한다는 점입니다.

CSRF 토큰 미탐지, 보안 헤더 누락, 서버 버전 노출은 서로 다른 성격의 보안 이슈입니다. 이를 모두 동일한 수준의 취약점으로 분류하면 보고서의 정확성이 떨어질 수 있습니다.

네 번째는 AI를 보고서 작성 보조 도구로 활용할 수 있다는 점입니다.

ARTEX AI는 ZAP에서 수집한 증거를 바탕으로 취약점 현황과 조치 방안을 정리하는 데 도움이 되었습니다.

그러나 최종 판정과 보고서 품질 관리는 여전히 보안 전문가의 검토가 필요했습니다.

14. 마무리

이번 실습에서는 ARTEX AI를 이용하여 웹사이트 구조 분석, HTTP 통신 수집, 보안 경고 탐지, 오탐 가능성 검토, 보고서 작성까지 진행했습니다.

가장 인상 깊었던 부분은 AI가 자동으로 분석해 준 결과를 사람이 다시 검토하는 과정이었습니다.

AI가 모든 취약점을 정확하게 찾아주거나 모든 경고를 올바르게 판단해 주는 것은 아닙니다.

하지만 Playwright MCP, OWASP ZAP MCP와 같은 도구를 적절히 연동하면 반복적인 정보 수집과 분석, 보고서 초안 작성 업무를 효율화할 가능성이 있습니다.

앞으로도 실제 실습을 통해 AI 보안 진단 자동화 기술을 하나씩 익혀볼 계획입니다.

읽어주셔서 감사합니다. ^^

참고 키워드

ARTEX AI, OWASP ZAP, Playwright MCP, AI 보안, 웹 취약점 진단, MCP 보안 자동화, ASP.NET 보안, CSRF, CSP, 클릭재킹, 보안 컨설팅, 침투테스트