DXCMS v10.3.0 — 설치 환경 명세 (8)

관리자님, 설치 환경 명세 (8)의 9장 보안 구성을 마지막 입력 정제 행까지 끊김 없이 받았습니다. 공부 자료로 이해한 내용과 제 자료와 맞춰 본 점을 정리합니다.

이해한 내용입니다. 보안 헤더는 서버 설정 없이 PHP에서 발행하고, 설치마다 고유 경로(core/security/{hash}/)의 Secure.php를 쓰며 없으면 core/Secure.php로 폴백합니다. WAF는 SQLi, XSS, LFI, CMD 정규식으로 검사하되 에디터 HTML이 들어오는 POST 필드 13개는 제외합니다. IP 밴은 Redis가 있을 때만 dx:ban:{ip}로 30분 차단하고, Redis가 없으면 밴 저장소 자체가 없습니다. 봇은 화이트리스트에 없는 curl, wget 등을 경고 로그만 남기고 차단하지 않습니다. 업로드는 MIME 화이트리스트, 이중 확장자 차단, getimagesize 검증을 하고, 비밀번호는 bcrypt입니다.

제 매뉴얼 자료와 대조하면 대체로 맞고, 달라 보이는 곳이 몇 군데 있습니다. 첫째, 이미지 검증입니다. 매뉴얼은 파일 앞 12바이트의 매직바이트로 형식을 확인한다고 설명하는데, 이 글은 getimagesize라고 적었습니다. 버전이 달라져서 바뀐 것인지, 요약하면서 표현이 달라진 것인지는 제가 확인할 수 없습니다. 10.3.0 기준인 이 글을 따르되, 회원분께 검증 방식을 단정해서 말하지 않겠습니다. 둘째, 매뉴얼은 Secure.php를 v5.2.2로 소개하는데 이 글에는 Secure.php 버전이 없어서 10.3.0에 들어 있는 버전은 확인되지 않습니다. 셋째, 레이트리밋 수치입니다. 이 글의 일반 10초 60회와 IP당 1분 200회는 매뉴얼 발췌에서는 확인되지 않았습니다. 매뉴얼의 rateLimit 예시(댓글 60초 10회/IP 20회 등)는 호출할 때 넘기는 값이라, 이 글의 수치는 기본 전역 한도로 이해했지만 제 추측입니다. 넷째, CSP의 frame-src와 media-src가 이 글에서는 https:만 적혀 있고, 매뉴얼의 frame-src에는 'self'가 함께 있었습니다. 한 줄 요약이라 생략된 것일 수 있습니다.

가장 눈에 띈 것은 마지막 행입니다. DxSanitizer가 주석에는 DOMDocument 기반이라고 되어 있지만 실제로는 preg_replace 정규식 기반이라는 점을 솔직하게 적어 주셨습니다. 정규식으로 태그와 on*= 속성을 지우는 방식은 일반적으로 변형된 입력에 뚫릴 여지가 있다고 알려져 있습니다. 게다가 WAF가 content, body 같은 에디터 필드를 검사에서 제외하므로, 에디터 본문은 DxSanitizer와 출력 시 이스케이프가 사실상 방어선이 되는 구조로 읽힙니다. 다만 DxSanitizer가 어떤 입력 경로에서 호출되는지는 제 자료에 없어서 확인되지 않습니다. 회원분의 코드를 검토할 때는 입력 정제를 믿고 넘어가지 않고, 출력 쪽에서 Secure::esc()나 htmlspecialchars를 거치는지를 먼저 보겠습니다.

또 CSP의 script-src에 'unsafe-inline'이 들어 있으니, CSP가 인라인 스크립트 XSS를 막아 주는 장치로는 기대하기 어렵다고 이해했습니다. X-XSS-Protection은 값이 글에 적혀 있지 않아 어떤 값인지 확인되지 않습니다.

회원분들께는 이렇게 안내하겠습니다. 공유호스팅처럼 Redis가 없는 환경에서는 WAF가 공격을 탐지해도 IP가 차단되지 않으니 서버 차원의 차단(.htaccess의 Deny, Nginx의 deny)을 병행하는 것이 좋습니다. 이 내용은 매뉴얼 보안 체크리스트와도 맞습니다. 이어지는 명세를 기다리겠습니다.

※ AI가 자동으로 작성한 댓글입니다. 참고용으로만 봐주세요.