DXCMS 보안 아키텍처 평가 보고서
1. 문서 개요
본 문서는 DXCMS의 보안 구조를 애플리케이션 보안만으로 평가하지 않고, 다음과 같은 다층 구조를 전제로 평가한다.
Internet
│
▼
[서버 자체 보안 엔진]
│ Python / C
▼
[Web Server]
│
▼
[DXCMS Core]
│
├── Secure.php
│
└── Security Plugins
│
└── DX Bot Challenge
특히 DXCMS가 두 가지 배포 환경을 전제로 한다는 점을 중요하게 반영한다.
- 서버를 직접 통제할 수 있는 환경
- 서버 프로그램을 설치할 수 없는 공유호스팅 환경
따라서 이 보고서에서 Secure.php와 보안 Plugin을 단순히 "한 파일에 기능이 몰려 있다" 또는 "PHP 보안은 서버 보안보다 약하다"라는 관점으로만 평가하지 않는다.
핵심 평가 기준은 "각 환경에서 가능한 보안 계층을 어떻게 제공하고, Plugin 확장을 통해 보안 계층을 추가할 수 있게 했는가"이다.
2. 최종 평가 요약
종합 판정
DXCMS는 단일 보안 기능을 제공하는 CMS가 아니라, 환경에 따라 보안 계층을 증설할 수 있도록 설계된 다층 보안 아키텍처에 가깝다.
특히 다음 구조는 높게 평가할 수 있다.
DXCMS
│
┌────────┴────────┐
│ │
기본 보안 확장 보안
Secure.php Plugin
│ │
└────────┬────────┘
│
애플리케이션 계층
│
┌──────────┴──────────┐
│ │
서버 직접 운영 공유호스팅
│ │
Python / C PHP Plugin
보안 엔진 Bot Challenge
서버를 통제할 수 있는 사용자는 PHP보다 낮은 계층에 보안 엔진을 둘 수 있고, 공유호스팅 사용자는 DXCMS Plugin을 통해 애플리케이션 계층에서 추가 방어를 할 수 있다.
이 설계는 CMS를 만든 사람 자신만 사용하는 시스템이 아니라, 서로 다른 환경의 외부 개발자들이 가져다 사용하는 플랫폼이라는 전제를 반영한 것으로 평가된다.
3. 가장 중요한 설계 판단: 단일 Secure.php
3.1 단일 파일 자체를 약점으로 판단하면 안 된다
core/Secure.php가 여러 보안 기능을 담당한다고 해서 자동으로 잘못된 구조는 아니다.
특히 DXCMS는 PHP 5.6부터 동작하는 호환성을 고려하면서, 외부 개발자가 Core의 보안 구조를 일일이 이해하지 않아도 되도록 하나의 표준 보안 진입점을 제공하는 방향으로 설계된 것으로 볼 수 있다.
즉 목적은:
모든 보안 알고리즘을 하나의 클래스에 영원히 가둔다.
가 아니라,
Core에서 보안 기능의 표준 진입점을 통일하고, 필요한 사용자는 Plugin/Extend/Override 등의 방법으로 가지를 친다.
에 가깝다.
3.2 CMS 제품 관점에서는 장점이 있다
외부 개발자가 DXCMS를 설치하면 보안 기능이:
Secure
Session
CSRF
Header
Upload
Rate Limit
WAF
...
각각 흩어져 있는 경우 각 구성요소의 관계를 알아야 한다.
반면 표준 진입점을 하나로 두면 Core의 기본 동작을 파악하기가 쉬워진다.
특히 사용자가 실제 운영 과정에서 Core를 수정하거나 별도의 Plugin을 붙이게 되는 CMS에서는 "개발자 혼란을 줄이는 것" 자체가 아키텍처 요구사항이 될 수 있다.
4. DXCMS의 가장 큰 보안 장점: Plugin 확장
DXCMS에서 Plugin은 단순한 UI 기능 추가 수단이 아니다.
보안 기능도 Plugin으로 추가할 수 있다.
대표적으로 제공된 DX Bot Challenge Plugin은 다음과 같은 흐름을 가진다.
요청
↓
Plugin 진입
↓
환경/경로 확인
↓
Bot/User-Agent 검사
↓
통과 쿠키 확인
↓
Challenge 발급
↓
브라우저 JS 계산
↓
POST 검증
↓
HMAC 검증
↓
통과 쿠키 발급
↓
원래 URL로 이동
이는 공유호스팅에서 서버 프로그램을 설치할 수 없는 사용자에게 중요한 의미가 있다.
5. DX Bot Challenge Plugin 코드 평가
5.1 장점
A. 직접 접근 차단
Plugin 파일과 handler에:
if (!defined('DX_CMS')) exit('Direct access not allowed.');
가 적용되어 있다.
PHP 파일 자체를 웹에서 직접 호출하는 기본적인 공격면을 줄이는 방식이다.
B. HMAC 기반 토큰
Challenge 서명과 통과 쿠키에 HMAC-SHA256을 사용한다.
IP + timestamp
↓
HMAC-SHA256(secret)
↓
token
따라서 단순히 timestamp를 조작한다고 통과 토큰을 만들어낼 수 있는 구조는 아니다.
C. 쿠키에 IP를 결합
통과 쿠키는:
timestamp.token
형태이며 token 계산에 IP가 들어간다.
따라서 쿠키만 복사하는 공격에 대해 일정한 방어 효과가 있다.
D. hash_equals() 사용
서명 비교에 hash_equals()를 사용하고 있다.
이는 단순 == 비교보다 적절한 선택이다.
E. Challenge의 재사용 시간 제한
Challenge timestamp를 검사하여 10분이 넘으면 실패시킨다.
F. 원래 URL 검증
redir가 절대 URL 형태가 되지 않도록 /로 시작하는지 확인하고 아니면 /로 되돌린다.
Open Redirect 방지 의도가 들어간 부분이다.
G. 로그 디렉터리 접근 방어
로그 디렉터리에 .htaccess와 web.config를 생성하여 웹에서 직접 로그를 열람하기 어렵게 한다.
Apache와 IIS 환경을 동시에 고려한 흔적이다.
H. 공유호스팅 현실을 고려
별도의 Redis, C/C++, Python daemon, reverse proxy 등이 없어도 PHP Plugin만으로 동작하도록 구성되어 있다.
이 부분은 DXCMS의 제품 목표와 매우 잘 맞는다.
6. 하지만 DX Bot Challenge를 "강력한 봇 차단"이라고 부르면 안 된다
이 부분은 냉정하게 평가해야 한다.
현재 Challenge는:
nonce
timestamp
signature
↓
JavaScript
↓
SHA-256
↓
response
를 계산한다.
그러나 계산에 필요한 값이 브라우저에 모두 전달된다.
즉 현대적인 자동화 도구가 JavaScript를 실행할 수 있다면 Challenge를 수행할 수 있다.
따라서 이것은:
- JS 실행 여부 확인
- 단순 HTTP 클라이언트 차단
- 저급 봇/스크립트 억제
- 일정 수준의 자동화 비용 증가
에는 의미가 있지만,
고도화된 Headless Chrome/Playwright/Puppeteer 계열 봇을 인간과 완전히 구분하는 시스템은 아니다.
이 차이는 명확히 해야 한다.
7. User-Agent 기반 Bot Allowlist의 한계
현재 허용 봇은 User-Agent 문자열을 기준으로 판단한다.
예:
Googlebot
Bingbot
GPTBot
ClaudeBot
Applebot
PerplexityBot
...
문제는 User-Agent는 위조할 수 있다는 것이다.
따라서:
User-Agent = Googlebot
이라고 해서 실제 Google crawler라는 보장은 없다.
평가
SEO/검색봇을 통과시키기 위한 편의 기능으로는 적절하지만, 신뢰 가능한 Bot 인증 수단으로 사용해서는 안 된다.
고급 환경에서는 공식 crawler IP 검증, reverse DNS + forward confirmation, 공급자 IP range 검증 등을 추가할 수 있다.
8. IP 추출은 개선 여지가 있다
코드는:
HTTP_X_FORWARDED_FOR
HTTP_X_REAL_IP
REMOTE_ADDR
순으로 IP를 가져온다.
문제는 X-Forwarded-For와 X-Real-IP가 신뢰하는 Reverse Proxy에서만 설정된다는 보장이 필요하다는 것이다.
공격자가 웹서버에 직접 접근할 수 있는 환경에서 해당 헤더를 임의로 설정할 수 있다면 로그의 IP와 IP 기반 정책이 왜곡될 수 있다.
따라서 서버 환경을 명확하게 알고 있다면:
Trusted Proxy 목록
↓
해당 Proxy에서 온 요청만
X-Forwarded-For 신뢰
구조가 더 안전하다.
다만 이것은 DXCMS 전체의 치명적 취약점이라고 단정할 문제는 아니며 배포 환경별 프록시 정책 문제에 가깝다.
9. Secret Key 생성에 대한 평가
Plugin은 우선순위를:
DB 설정
↓
.secret_key
↓
자동 생성
으로 두고 있다.
가능한 경우 openssl_random_pseudo_bytes()를 사용한다.
그러나 fallback에서는:
md5(uniqid(mt_rand(), true) . microtime(true))
형태가 사용된다.
이 방식은 암호학적으로 강한 난수 생성 방식으로 볼 수 없다.
개선 권고
PHP 5.6 호환성을 유지해야 한다면:
- OpenSSL 사용 가능 여부를 필수 조건으로 만들거나
- 안전한 난수원을 사용할 수 없는 환경에서는 명시적으로 설치/구성 오류를 내거나
- 최초 설치 과정에서 강한 랜덤 키를 생성하여 안전하게 저장
하는 방식이 더 좋다.
이 부분은 보안 코드에서 실제 개선 대상으로 판단한다.
10. Cookie 보안 설정
현재 통과 쿠키에는:
Secure
HttpOnly
가 적용된다.
이는 좋은 선택이다.
다만 코드상 SameSite 속성을 직접 설정하지 않는다.
현대적인 배포환경에서는 SameSite 정책을 명시적으로 관리하는 편이 좋다.
특히 인증/세션/CSRF 관련 쿠키라면 다음 정책을 환경과 기능에 맞게 검토해야 한다.
Secure
HttpOnly
SameSite=Lax
또는 필요한 경우 더 엄격한 정책.
OWASP 역시 세션 관리에서 쿠키 속성, 세션 고정, 노출, CSRF, 세션 탈취 등을 별도로 검증하도록 권고한다. citeturn0search14turn0search16
11. CSRF와 Bot Challenge는 서로 다른 보안 기능이다
이 부분은 특히 중요하다.
Bot Challenge가 성공했다고 해서:
CSRF 안전
이 되는 것은 아니다.
Bot Challenge의 목적은:
자동화된 요청
을 어렵게 하는 것이다.
CSRF의 목적은:
피해자의 인증 상태를 이용하여
의도하지 않은 요청을 실행시키는 공격
을 방어하는 것이다.
OWASP 역시 CSRF를 별도의 세션 보안 문제로 다룬다. citeturn0search1turn0search9
따라서 DXCMS에서는:
Bot Challenge
+
CSRF Token
+
Session Security
+
Authorization
을 서로 다른 계층으로 봐야 한다.
12. 서버 자체 보안 엔진과 결합했을 때 평가가 달라진다
사용자가 설명한 것처럼 실제 운영 서버에는 Python/C 기반 자체 보안 엔진이 별도로 존재한다면 전체 구조는:
공격 요청
│
▼
┌──────────────────┐
│ C / Python Engine│
│ 서버 보안 계층 │
└────────┬─────────┘
│
▼
Web Server
│
▼
┌──────────────────┐
│ DXCMS │
│ │
│ Secure.php │
└────────┬─────────┘
│
▼
┌──────────────────┐
│ Security Plugin │
│ Bot Challenge │
└──────────────────┘
이렇게 된다.
이것은 방어 심도의 Defense in Depth 구조다.
각 계층이 서로 다른 역할을 담당할 수 있다.
13. 서버 보안 엔진과 Plugin은 경쟁하지 않는다
오히려 역할이 다르다.
서버 엔진
네트워크
프로세스
IP
패킷/요청
웹서버 이전/앞단
비정상 트래픽
등을 더 낮은 계층에서 다룰 수 있다.
DXCMS Secure
Session
CSRF
Input
Upload
Application security
Authorization support
등 애플리케이션 내부 문제를 다룬다.
Security Plugin
Bot Challenge
사이트별 정책
특정 서비스 보안
사용자 정의 차단
등을 추가한다.
따라서 세 계층이 합쳐질수록 단일 방어수단에 대한 의존도가 낮아진다.
14. 공유호스팅이라는 조건을 고려하면 DX Bot Challenge의 의미가 커진다
공유호스팅 사용자는 일반적으로:
C/C++ daemon 설치
Python daemon 실행
iptables
WAF module
Nginx module
Reverse Proxy
L7 gateway
등을 자유롭게 구성할 수 없다.
그런 환경에서:
DXCMS
+
Security Plugin
만으로 추가적인 요청 검증 계층을 제공하는 것은 현실적인 제품 설계다.
따라서 이 Plugin의 목표를:
"최첨단 봇 방어"
라고 보면 과장이고,
"서버를 통제할 수 없는 공유호스팅 환경에서 PHP 수준의 추가적인 자동화 요청 방어 계층을 제공한다."
라고 정의하면 상당히 합리적이다.
15. PHP 5.6 호환성에 대한 보안 평가
여기서는 반드시 구분해야 한다.
DXCMS가 PHP 5.6 호환 코드를 작성한 것과 PHP 5.6을 보안상 권장하는 것은 완전히 다른 문제다.
PHP 5.6은 공식적으로 지원 종료된 브랜치다. PHP 공식 지원표는 지원 종료된 브랜치를 더 이상 보안 수정 대상으로 지원하지 않으며, 오래된 버전 사용은 패치되지 않은 취약점에 노출될 수 있다고 명시한다. citeturn0search6turn0search11
따라서:
DXCMS 코드의 PHP 5.6 호환성
≠
PHP 5.6 서버의 보안성
이다.
DXCMS가 PHP 5.6부터 최신 PHP까지 동작하도록 설계한 것은 호환성 측면에서는 강점이지만, 실제 운영 서버는 가능한 경우 현재 지원되는 PHP 브랜치를 사용하는 것이 맞다.
16. DXCMS 보안의 강점
매우 강하게 평가할 부분
① 다층 보안을 Plugin으로 확장할 수 있음
9.5/10
② Core 보안 진입점 통일
9/10
③ 공유호스팅 환경까지 고려
9.5/10
④ 서버 보안 계층과 애플리케이션 보안 계층을 분리할 수 있음
9.5/10
⑤ Hook/Plugin 구조가 보안 기능에도 활용 가능
9/10
⑥ PHP 구버전 호환성을 고려하면서 보안 기능을 구현
8.5/10
단, 구버전 PHP 자체를 보안적으로 권장한다는 의미는 아니다.
17. 보안상 개선이 필요한 부분
① User-Agent만으로 봇 신뢰
중간 위험
② Forwarded IP 신뢰 정책
배포 환경에 따라 중간 위험
③ Secret fallback의 난수 품질
개선 권고
④ SameSite 쿠키 정책 명시
개선 권고
⑤ JS Challenge의 한계
설계 한계
고도화된 Headless Browser를 상대로는 충분한 봇 방어가 아니다.
⑥ PHP 애플리케이션 계층의 한계
서버/네트워크 계층의 공격을 PHP Plugin만으로 해결할 수 없다.
18. DXCMS 보안 점수
단순히 Secure.php만 평가하면:
7~8점 수준으로 보일 수 있다.
하지만 실제 제품 구조를 기준으로:
Secure.php
+
Security Plugin
+
서버 C/Python 엔진
+
환경별 fallback
+
공유호스팅 대응
+
Plugin/Hook 확장
까지 평가하면 이야기가 달라진다.
최종 평가
영역 평가
Core 보안 구조 8.8/10 확장형 보안 구조 9.4/10 Plugin 보안 확장성 9.5/10 공유호스팅 대응 9.5/10 세션/토큰 기본 설계 8.5/10 Bot Challenge 7.5/10 고급 Bot 방어 6.5/10 서버 보안과의 연계 가능성 9.5/10 보안 아키텍처 철학 9.3/10 전체 보안 설계 9.0/10
19. 최종 결론
DXCMS의 보안은 "Secure.php가 얼마나 많은 보안 함수를 가지고 있는가"로 평가하면 안 된다.
DXCMS의 진짜 보안 설계는:
DXCMS Security
│
┌─────────────────┼─────────────────┐
│ │ │
Core Secure Plugin Security Server Security
│ │ │
기본 보안정책 사이트별 확장 C / Python
│ │ │
└─────────────────┼─────────────────┘
│
Defense in Depth
라는 구조에 있다.
그리고 이것이 Plugin Architecture의 진짜 가치다.
Plugin이 단순히:
게시판 하나 추가
결제수단 하나 추가
위젯 하나 추가
하는 수준에 머무르지 않고,
보안 계층 자체를 추가할 수 있다.
는 것이다.
특히 서버를 직접 통제할 수 없는 공유호스팅 사용자에게 이것은 상당히 현실적인 장점이다.
따라서 저는 현재 확인한 자료를 기준으로 DXCMS의 보안 아키텍처 자체는 상당히 잘 설계된 편이라고 평가한다.
다만 **"군사급 보안", "완벽한 봇 방어", "PHP만으로 서버 보안을 대체한다"**라고 평가해서는 안 된다.
가장 정확한 표현은 다음과 같다.
DXCMS는 단일 보안 모듈에 모든 것을 맡기는 CMS가 아니라, Core의 기본 보안 위에 Plugin을 통해 사이트별 보안 계층을 추가하고, 서버를 직접 통제할 수 있는 환경에서는 별도의 서버 보안 엔진까지 결합할 수 있도록 설계된 확장형 Defense-in-Depth CMS이다.
이 평가가 현재 확인한 DXCMS의 구조와 가장 잘 맞는다.
20. 감사 범위와 한계
본 평가는 다음을 기준으로 한다.
- DXCMS의 기존 소스 분석 결과
- 이번에 제공된
dx-bot-challengePlugin의 실제 코드 Secure.php를 포함한 DXCMS 보안 구조에 대한 앞선 소스 분석- 사용자가 설명한 Python/C 서버 보안 엔진의 구조
- 실제 운영 사이트에 해당 구조가 적용되어 있다는 사용자 설명
- OWASP Web Security Testing Guide의 일반적인 세션/CSRF/보안 테스트 기준
따라서 이것은 침투 테스트(Penetration Test) 보고서가 아니라 소스코드 및 보안 아키텍처 리뷰다.
실제 취약점 확정에는 별도의 동적 테스트가 필요하다.
특히 다음 테스트를 수행하면 평가 정확도가 크게 올라간다.
1. Session Fixation
2. Session Hijacking
3. CSRF
4. Cookie Attribute
5. Open Redirect
6. Upload Bypass
7. SQL Injection
8. XSS
9. SSRF
10. Path Traversal
11. Authentication Bypass
12. Authorization Bypass
13. Bot Challenge Automation Bypass
14. IP Spoofing / Proxy Trust
15. Rate Limit Bypass
16. Replay Attack
17. Plugin Isolation
18. Hook Abuse
19. Extend Abuse
20. Log Injection
OWASP의 최신 WSTG도 인증, 권한, 세션, 입력검증, 오류처리, 암호화, 비즈니스 로직, API 등을 별도 영역으로 테스트하도록 구성한다. citeturn0search9turn0search10
최종 한 문장
DXCMS의 보안은 "보안 코드가 완벽해서 강한 시스템"이라기보다, "서버·Core·Plugin이라는 서로 다른 계층에 보안을 배치할 수 있도록 설계되어 있어 강한 시스템으로 발전시킬 수 있는 구조"라는 점이 가장 큰 장점이다.
