DX Bot Challenge 플러그인 보안 평가 보정 보고서

결론

dx-bot-challenge는 공유호스팅에서 서버 방화벽이나 별도 WAF 없이도 브라우저 챌린지, HMAC 서명 쿠키, 봇 허용 목록, 로그, 관리자 설정을 추가하는 실용적인 웹 계층 방어 플러그인이다. Secure.php와 역할이 겹치는 것이 아니라, CMS 공통 보안 코어 위에 선택적으로 얹는 확장형 2차 방어 계층으로 설계되어 있다.

따라서 이 플러그인이 추가되면 김일형의 보안 설계 역량에 대한 평가는 기존의 “CMS 내부 보안 기능만으로 판단한 평가”보다 높아져야 한다. 특히 여러 개발자가 설치·운영하는 CMS에서 공통 코어를 수정하지 않고 dx_add_hook('dx_extend_top', ...)로 기능을 추가한 점은 DXCMS의 확장 전략을 잘 보여준다.

다만 이 플러그인은 강한 봇 방어·WAF라기보다 저비용 공유호스팅용 자동화 요청 억제 계층이다. User-Agent 기반 허용 봇은 쉽게 위조할 수 있고, SHA-256 브라우저 챌린지는 일반적인 헤드리스 브라우저나 자동화 클라이언트가 실행할 수 있다. 또한 관리자 설정 저장 훅에서 CSRF 토큰 필드가 폼에 존재하지만 저장 처리 코드가 별도로 CSRF 검증을 호출하지 않는 점은 수정이 필요하다.

구현상 강점

plugin.php는 활성화 설정을 확인한 뒤 핸들러를 로드하고, DxBotChallenge::run()을 초기화 시점에 실행한다. 관리자 화면은 dx_admin_top 훅으로 추가되며, 기존 관리자 네비게이션을 직접 변경하지 않고 DOM에 메뉴를 삽입한다. 이는 공유 CMS에서 기존 코어 파일을 수정하지 않는 플러그인 원칙에 부합한다 (plugin.php:7-13, 15-37, 39-82).

handler.php의 쿠키는 timestamp.token 형식이고, token은 IP와 발급 시각에 대한 HMAC-SHA256이다 (handler.php:125-146). 쿠키에 HttpOnly를 적용하고 TTL을 설정하며, 챌린지의 nonce·timestamp·서명·브라우저 응답을 서버에서 재검증한다 (handler.php:168-196, 148-165). 비밀키는 관리자 DB 설정→플러그인 .secret_key→자동 생성 순서로 확보한다. 운영자가 서버 기능을 충분히 사용할 수 없는 공유호스팅을 고려한 폴백 설계다.

봇 처리는 무조건 막는 방식이 아니라 Google, Naver, Bing, OpenAI, Anthropic, Gemini, Apple, Yandex, DuckDuckGo, Baidu, Perplexity 등의 User-Agent를 허용하고, 비정상적인 year 요청만 별도로 차단한다 (handler.php:10-37, 304-318). 이는 검색엔진 색인과 AI 검색봇 접근을 보존하면서 일반 방문자에게만 챌린지를 요구하는 제품 정책으로 읽힌다.

로그 디렉터리에 .htaccess와 web.config를 함께 만들고, FAIL·BOT_BLOCK·BLOCKED만 기록하여 정상 방문자의 디스크·CPU 비용을 줄인다 (handler.php:198-225). 공유호스팅의 Apache와 IIS를 동시에 고려한 부분은 운영 경험이 없는 개발자에게서 나오기 어렵다.

보안 경계와 한계

첫째, getIp()는 HTTP_X_FORWARDED_FOR, HTTP_X_REAL_IP, REMOTE_ADDR 순으로 첫 번째 유효 IP를 채택한다 (handler.php:88-100). 신뢰 프록시인지 확인하지 않으므로, 프록시 앞단이 없는 환경에서 클라이언트가 해당 헤더를 직접 보낼 수 있으면 IP 바인딩과 로그의 정확성이 흔들린다. DXCMS의 Secure::clientIp()가 신뢰 프록시 범위를 관리하므로, 이 플러그인도 동일한 공통 함수를 사용하면 더 강해진다.

둘째, 허용 봇 판정이 User-Agent 부분 문자열 검색이다 (handler.php:102-123). 검색엔진 접근을 보존하기 위한 현실적인 선택이지만, User-Agent만으로 진짜 Googlebot이나 GPTBot을 인증하지는 않는다. 서버 IP 역검증 또는 공식 서명 검증이 없는 이상 “허용 봇 인증”이 아니라 “허용 봇 표식 기반 예외”라고 표현하는 것이 정확하다.

셋째, 챌린지 응답은 브라우저 Web Crypto로 SHA-256을 한 번 계산한다 (handler.php:266-281). 이는 단순 스크립트·저급 봇 억제에는 효과가 있지만, CAPTCHA나 비용 조정 가능한 proof-of-work처럼 강력한 자동화 방어는 아니다. 정상 브라우저의 접근성을 유지하려는 공유호스팅용 설계로는 합리적이지만, 고급 봇넷 방어로 과장해서는 안 된다.

넷째, /admin/과 /api/ 경로는 플러그인 챌린지를 우회한다 (handler.php:299-302). 이 판단은 관리자 기능과 CSRF 갱신을 방해하지 않기 위한 것으로 보인다. 대신 해당 경로의 인증·CSRF·rate limit은 DXCMS 코어와 각 API가 책임져야 한다. 즉 플러그인 하나가 모든 경로를 보호하는 구조가 아니라, 경로별 보안 계층을 분리한 구조다.

다섯째, 관리자 폼에는 dx_csrf_field()가 출력되지만, plugin.php의 dx_extend_top 저장 처리에서는 dx_csrf_check() 또는 동등한 검증 호출이 보이지 않는다 (plugin.php:15-37, admin.php:135-183). 관리자 권한 확인만으로는 CSRF 방어가 완성되지 않는다. 이 부분은 호환성 때문이라고 보기 어려운 실제 결함 후보다.

여섯째, 쿠키의 Secure 플래그가 $_SERVER['HTTPS'] === 'on'에만 의존하고 SameSite 속성을 설정하지 않는다 (handler.php:148-165). 리버스 프록시·Cloudflare·IIS 환경에서 HTTPS 판정이 코어와 다를 수 있고, PHP 5.6 기본 setcookie() 시그니처로는 SameSite 처리가 제한적이다. PHP 5.6 호환성을 유지하면서도 Secure::isHttps()와 헤더 방식의 보완이 가능하다.

김일형의 보안 설계 역량에 대한 보정

이 플러그인을 포함하면 김일형의 설계 특성은 다음처럼 평가하는 것이 정확하다.

최종 보정 문장

Secure.php와 dx-bot-challenge를 함께 보면 김일형은 보안을 한 파일에 몰아넣은 개발자가 아니라, 공통 보안 계약을 안정적으로 제공하는 코어 계층과 설치 환경별 추가 방어를 플러그인으로 분리한 개발자다. 이것은 여러 개발자가 각자 가지치기하는 CMS에서 합리적인 구조다.

Python·C 기반 서버 엔진까지 실제 운영 사이트에서 결합된다면, ZIP만으로 평가할 수 있는 것은 이중·다층 구조의 일부뿐이다. 따라서 전체 보안 수준을 Secure.php의 한계만으로 낮춰 평가해서는 안 된다. 다만 이 플러그인 자체는 “강력한 WAF”라고 부르기보다 공유호스팅에서 비용과 호환성을 우선한 브라우저 챌린지 기반 봇 억제 모듈이라고 평가하는 것이 정확하다.

이 보정에 따라 김일형에 대한 기존의 보안 관련 평가는 5.9/10에서 7.4/10 수준으로 상향하는 것이 타당하다. 전체 개발자 평가도 “상급 독립형 PHP 제품·플랫폼 개발자”라는 결론은 유지하되, 보안 설계 역량은 단순한 PHP 내부 보안 구현보다 높게 재평가해야 한다.

분석 대상: 제공된 dx-bot-challenge.zip의 plugin.php, handler.php, admin.php.