웹사이트, 미니프로그램 또는 App이 외부에 서비스를 제공하는 한, 반드시 스캔당하고, 탐색당하고, 공격받게 됩니다. 차이는 단지 발견되었는지 여부뿐입니다. 많은 팀이 기능 개발과 출시 속도에만 집중하고 보안 테스트는 계속 미루다가, 결국 권한 우회 API 하나 또는 업로드 지점 하나로 전체 시스템이 무너질 수 있습니다. MIC Studio는 장기간의 보안 테스트 및 리버스 엔지니어링 테스트 서비스에서 동일한 패턴을 반복적으로 목격했습니다. 실제로 시스템을 뚫는 것은 대단히 고도화된 기술이 아니라, 간과된 몇 가지 오래된 문제인 경우가 많습니다. 이 글에서는 웹사이트 보안 테스트에서 가장 흔한 취약점을 철저히 설명하고, 바로 적용할 수 있는 보안 강화 제안을 제공합니다.
一、먼저 보안 테스트의 목표와 범위를 명확히 하자
보안 테스트는 스캐너 한 세트를 구매해서 한 번 돌리고 끝내는 것이 아닙니다. 그것은 세 가지 질문에 답해야 합니다. 공격자는 어느 입구로 들어올 수 있는가? 들어온 후 얼마나 많은 것을 얻을 수 있는가? 얻은 후 얼마나 큰 피해를 줄 수 있는가?
테스트 방식에 따라 일반적으로 세 가지 유형이 있습니다.
- 블랙박스 테스트: 외부 공격자를 완전히 모방하며, 소스 코드와 계정을 보유하지 않고, 실제 공격 시나리오에 가장 근접합니다.
- 화이트박스 테스트: 소스 코드 감사를 결합하여 블랙박스로는 찾을 수 없는 심층 로직 문제를 발견할 수 있습니다.
- 그레이박스 테스트: 일부 계정 또는 API 문서를 확보하여 효율성이 가장 높고, 반복이 빈번한 프로젝트에 적합합니다.
대부분의 중소형 프로젝트의 경우 API 계층과 권한 계층을 우선 테스트하는 것이 비용 대비 효과가 가장 높습니다. 이 두 부분에서 문제가 가장 빈번하게 발생하고 결과도 가장 심각하기 때문입니다. 데이터 유출, 권한 우회 조작, 백오피스 탈취는 기본적으로 여기서 시작됩니다.
二、SQL 인젝션: 오래된 문제, 여전히 최대 위협
SQL 인젝션은 20년 넘게 존재해 왔지만, 지금까지도 각종 취약점 목록의 단골손님입니다. 이유는 간단합니다. SQL이 문자열 결합으로 만들어지는 곳이 한 군데라도 있으면 악용될 수 있기 때문입니다.
전형적인 시나리오:
- 로그인 API가 문자열 결합으로 사용자를 조회하여, `' or '1'='1`을 입력하면 비밀번호를 바로 우회합니다.
- 목록 조회의 정렬 필드, 검색 조건이 SQL에 직접 결합되어 오류 기반 인젝션 또는 시간 기반 블라인드 인젝션이 발생합니다.
- 일부 구형 시스템은 ORM을 사용하지만 네이티브 SQL을 결합하여 동일한 위험이 존재합니다.
보안 강화 제안:
- 파라미터화된 쿼리(프리컴파일드 스테이트먼트)를 전면 사용하고, 코드 규범 차원에서 문자열 결합 SQL을 금지합니다.
- 정렬 필드, 테이블명처럼 파라미터화할 수 없는 위치는 화이트리스트 검증을 사용하여 사전 설정 값만 허용합니다.
- 데이터베이스 계정은 최소 권한 원칙을 따르고, 업무 계정에는 DROP, FILE, GRANT 등 고위험 권한을 부여하지 않습니다.
- 프로덕션 환경에서는 상세 오류 출력을 비활성화하여 테이블 구조와 데이터베이스 버전 유출을 방지합니다.
- WAF를 보조 방어선으로 도입하되, 유일한 방어로 삼지 않습니다.
三、XSS 크로스 사이트 스크립팅: 가장 오래 잠복하는 인젝션
XSS의 본질은 사용자 입력이 코드로 실행되는 것입니다. 저장형 XSS는 페이지에 장기간 남아 모든 방문자에게 영향을 미치기 때문에 피해가 가장 큽니다.
전형적인 시나리오:
- 댓글, 닉네임, 개인 서명이 페이지에 직접 출력됩니다.
- 리치 텍스트 에디터가 `