많은 사장님들이 공식 웹사이트에 기대하는 것은 '열리고, 보이고, 전화번호를 남길 수 있으면' 충분하다고 생각합니다. 오픈 당일 검수 후 몇 년 동안 아무도 다시 로그인해서 확인하지 않습니다.
어느 날 고객이 전화해서 "귀사 웹사이트에 들어가면 도박 페이지로 넘어가요"라고 하거나, 다크웹에서 데이터베이스가 판매되고 있다는 이메일을 받고 나서야 문제가 이미 오래전부터 존재했다는 것을 알게 됩니다.
웹사이트 보안 테스트는 대기업만을 위한 사치가 아닙니다. 여러분의 사이트에 관리자 페이지, 폼, 고객 데이터가 있다면 정기적인 점검이 필요합니다.
먼저 이해하기: 보안 테스트는 무엇을 테스트하는가
많은 사람들이 보안 테스트를 '취약점 스캔'이라고 생각합니다. 스캐너를 설치하고 한 번 돌려서 보고서를 받는 것. 하지만 이는 절반만 하는 것입니다.
완전한 보안 테스트는 최소 세 가지 계층을 다뤄야 합니다:
첫 번째 계층은 설정과 노출 영역입니다. 관리자 로그인 주소가 /admin 같은 기본 경로인지, 테스트 환경을 끄지 않고 공용 인터넷에 그대로 노출했는지, 데이터베이스 포트가 외부에 열려 있는지, 백업 파일이 웹사이트 루트 디렉토리에 있어서 직접 다운로드할 수 있는지. 이런 문제는 고급 기술이 필요 없지만 사고 발생 확률이 가장 높습니다.
두 번째 계층은 일반적인 웹 취약점입니다. SQL 인젝션, 권한 우회, 파일 업로드, XSS, 취약한 비밀번호. 특히 관리자 시스템에서 일반 계정이 URL 파라미터를 조작해 다른 사람의 주문을 볼 수 있는지 여부는 많은 기업 웹사이트 개발 시 전혀 고려하지 않았던 부분입니다.
세 번째 계층은 비즈니스 로직입니다. 예를 들어 예약 미니프로그램에서 프론트엔드 제한을 우회해 중복 제출이 가능한지, 쿠폰 API가 스크립트로 무한 발급될 수 있는지, 인증 코드가 형식적으로만 존재하는지. 이런 문제는 스캐너로는 발견할 수 없고 수동 테스트만 가능합니다.
세 계층을 모두 점검해야 자신의 위치를 알 수 있습니다.
왜 '정기적'이어야 하고 '한 번'으로는 안 되는가
보안 테스트는 백신 접종이 아닙니다. 한 번 맞으면 평생 면역이 아닙니다. 건강검진에 더 가깝습니다. 올해 정상이라고 내년도 정상이라는 보장은 없습니다.
이유는 명확합니다:
시스템이 변합니다. 귀사의 웹사이트는 이번 분기에 온라인 상담을 추가하고, 다음 분기에 결제를 연동하고, 연말에 CMS 버전을 교체할 수 있습니다. 코드를 수정할 때마다 새로운 구멍이 생길 수 있습니다. 지난번 테스트에서 문제가 없었던 것은 그 기능이 아직 존재하지 않았기 때문입니다.
구성 요소가 변합니다. 웹사이트에서 사용하는 프레임워크, 플러그인, 서드파티 SDK의 새로운 취약점이 지속적으로 공개됩니다. 아무것도 건드리지 않았지만 의존하는 것이 변한 것입니다.
공격 방식이 변합니다. 자동화 도구는 매일 전 세계 IP를 스캔하며 반년 동안 업데이트되지 않은 사이트를 찾습니다. 공격자는 여러분을 선택하는 것이 아니라 침입하기 쉬운 곳을 선택합니다.
실용적인 주기는: 핵심 비즈니스 시스템은 6개월에 한 번, 일반 기업 웹사이트는 최소 연 1회, 대규모 개편이나 신규 기능 추가 후 추가 점검. 결제, 회원 가입, 관리자 시스템이 있다면 6개월 주기에 가깝게 가져가세요.
구체적 사례: 웹사이트 개편 후 놓친 것
흔한 예를 들어보겠습니다.
어느 회사가 웹사이트를 개편하면서 비주얼 업그레이드, 제품 필터 추가, '온라인 문의' 폼 추가, 그리고 관리자 페이지를 구 시스템에서 새 CMS로 이전했습니다. 개발 기간은 한 달, 오픈 검수에서는 페이지 표시와 폼 제출 여부만 확인했고 모두 정상이어서 승인했습니다.
3개월 후 문제 발견: 새 관리자 로그인에 실패 횟수 제한도, 인증 코드도 없었습니다. 즉, 스크립트로 무한 비밀번호 시도가 가능했습니다. 또한 문의 폼 API에 빈도 제한이 없어 수만 건의 스팸 데이터가 쏟아져 데이터베이스 응답이 느려졌습니다.
이 두 가지 문제는 기본 보안 테스트로 10분 이내에 발견할 수 있습니다. 하지만 개편 프로세스에서 이 부분을 담당하는 사람이 없었습니다.
이것이 보안 테스트를 오픈 프로세스에 포함해야 하는 이유입니다. 사고 후에 보완하는 것이 아니라. 웹사이트 개발 납품 체크리스트에 '보안 테스트 통과' 항목이 있어야 합니다.
직접 테스트할 것인가, 외부에 맡길 것인가
모든 것을 외주로 할 필요는 없습니다. 기본적인 조치는 팀이 직접 할 수 있습니다:
- 관리자 강력 비밀번호 강제, 2차 인증 활성화
- 사용하지 않는 테스트 환경, 샘플 페이지, 기본 계정 비활성화
- 백업 파일과 로그 디렉토리가 공용 인터넷에서 접근 가능한지 확인
- 서드파티 구성 요소의 알려진 취약점 정기 확인
이것들은 운영 규율에 해당하며 비용이 낮고 효과가 높아 하지 않을 이유가 없습니다.
하지만 권한 우회, 인젝션, 로직 우회, 리버스 테스트처럼 공격 경로를 구성해야 하는 부분은 일반적으로 전문가가 필요합니다. 자체 인력이 부족해서가 아니라, 개발자와 테스터가 자사 시스템에 너무 익숙해 '정상 경로'를 따라가기 쉬워 공격자가 어디서 우회할지 생각하기 어렵기 때문입니다.
어떤 경우 MIC Studio에 적합한가
다음 조건에 해당한다면 저희의 개입을 고려해 보세요:
첫째, 웹사이트나 미니프로그램이 막 오픈했거나 대규모 개편을 마친 경우, 독립적인 시각으로 점검하여 명백한 구멍이 없는지 확인해야 합니다.
둘째, 관리자 시스템이 다중 역할 권한을 다루는 경우, 예를 들어 대리점, 직원, 관리자 등급이 있어 권한 우회 문제가 걱정되는 경우.
셋째, 해킹을 당했거나 스팸 데이터가 쏟아졌거나 협박 이메일을 받은 경우, 먼저 문제를 파악한 후 강화 방안을 논의해야 합니다.
넷째, App이나 스크립트 기반 비즈니스가 있는 경우, API 수준의 리버스 테스트를 통해 데이터 전송과 인증이 신뢰할 수 있는지 확인해야 합니다.
MIC Studio는 기업 웹사이트 개발, 미니프로그램 개발, App 개발 시 보안 테스트를 납품 단계의 일부로 포함하며, 별도의 웹사이트 보안 테스트 의뢰도 받습니다. 테스트 후에는 이해하기 어려운 스캔 보고서가 아닌 실행 가능한 수정 체크리스트를 제공합니다.
즉시 실행할 수 있는 세 가지 제안
첫째, '보안 테스트'를 다음 개편 검수 체크리스트에 추가하세요. 내년까지 기다릴 필요 없이 다음 코드 수정 시에 포함하면 비용이 가장 낮습니다.
둘째, 오늘 바로 세 가지를 확인하세요: 관리자 로그인 주소를 추측할 수 있는지, 테스트 환경이 꺼져 있는지, 웹사이트 루트 디렉토리에 의심스러운 파일이 있는지. 30분이면 확인할 수 있습니다.
셋째, 핵심 시스템에 고정된 재테스트 시점을 정하세요. 캘린더에 6개월에 한 번으로 적어두고 때가 되면 실행하세요. 기억에 의존하지 마세요.
보안이라는 것은 사고가 없을 때는 돈 낭비처럼 보이지만, 사고가 났을 때 가장 저렴한 투자였음을 알게 됩니다.