많은 사업주가 보안을 처음 진지하게 바라보는 시점은 웹사이트에 악성 코드가 심어지고, 관리자 페이지에 누군가 로그인하고, 사용자 데이터가 통째로 다운로드된 이후입니다. 이때 로그를 뒤지고 취약점을 보수하면 비용이 처음부터 방어를 잘 갖추는 것보다 훨씬 커지는 경우가 많습니다.
솔직히 말하면, 웹사이트 개발에서 흔한 보안 취약점 대부분은 고도로 어려운 기술이 아니라 기본 작업이 제대로 되지 않은 것입니다. 아래에서는 실전에서 가장 자주 밟는 함정을 하나씩 정리합니다.
一、인젝션 계열 취약점: SQL 인젝션과 명령 인젝션
SQL 인젝션은 가장 전형적인 취약점입니다. 원인은 간단합니다. 프로그램이 사용자 입력을 SQL 문에 직접 이어 붙이기 때문입니다. 예를 들어 로그인 입력란에 잘 구성된 문자열을 입력하면 비밀번호 검증을 우회하고, 심지어 사용자 테이블 전체를 빼낼 수도 있습니다.
일반적인 방법과 회피법:
- 파라미터화 쿼리나 ORM을 사용하고, 문자열 직접 연결을 손으로 작성하지 않기
- 데이터베이스 계정은 최소 권한으로 할당하고, 읽기 전용 업무에는 쓰기 권한을 주지 않기
- 운영 환경의 상세 오류 출력을 끄기. 오류 정보 자체가 정보가 됩니다
- 입력에 타입 검증 적용하기. 예를 들어 ID는 숫자만 허용
명령 인젝션도 마찬가지입니다. 일부 스크립트 개발 환경에서는 이미지 처리나 파일 생성을 위해 시스템 명령을 호출해야 하는데, 파일명을 명령에 직접 이어 붙이면 공격자가 다른 명령까지 실행할 수 있습니다. 이런 문제는 백오피스 관리 시스템에서 특히 흔합니다.
二、권한과 권한 우회: 로그인했다고 권한이 있는 것은 아님
이것은 기업 웹사이트와 백오피스 시스템에서 가장 과소평가되기 쉬운 유형입니다. 사용자가 분명히 로그인했지만 접근해서는 안 되는 데이터에 접근합니다.
두 가지로 나뉩니다:
- 수평 권한 우회: 일반 사용자 A가 URL의 주문 번호를 바꿔 사용자 B의 주문을 보게 됨
- 수직 권한 우회: 일반 사용자가 관리자 API에 직접 접근. 예를 들어 사용자 삭제, 데이터 내보내기
구체적인 시나리오: 어떤 예약형 미니프로그램 개발 프로젝트에서 API가 `/api/order/detail?id=1001`였습니다. 프런트엔드는 자신의 주문만 표시했지만, 백엔드에서 이 주문이 현재 사용자 소유인지 검증하지 않았습니다. id를 1002로 바꾸기만 하면 다른 사람의 휴대폰 번호와 주소를 볼 수 있었습니다.
방법:
- 데이터와 관련된 모든 API에서 서버 측에 「현재 사용자가 이 데이터에 접근할 권한이 있는지」를 검증해야 함
- 프런트엔드에서 버튼을 숨기는 방식으로 권한 제어를 하지 않기
- 관리자 백오피스와 사용자 측 API를 분리하고, 인증 로직을 독립적으로 운영
三、파일 업로드와 파일 포함
파일 업로드 자체는 문제가 없습니다. 문제는 「업로드 후 실행될 수 있는지」입니다.
흔한 함정:
- 프런트엔드 확장자만 검증해서, 패킷을 잡아 바꾸면 PHP, JSP를 업로드할 수 있음
- 업로드 디렉터리에 실행 권한이 있어서, 스크립트를 올리면 바로 서버를 장악함
- 파일명을 예측할 수 있어서, 공격자가 순회하며 다운로드할 수 있음
권장 방법:
- 서버 측에서 파일 타입을 검증하고, 블랙리스트가 아니라 화이트리스트 사용
- 업로드 디렉터리에서는 스크립트 실행을 금지하고 정적 접근만 허용
- 파일 이름을 무작위 문자열로 변경하고 원래 경로를 유지하지 않기
- 이미지 파일은 2차 처리를 하면서 끼어 있을 수 있는 악성 내용도 함께 제거
四、API와 비즈니스 로직 취약점
많은 취약점은 코드 수준이 아니라 비즈니스 흐름에 있습니다. 예를 들어:
- SMS 인증번호에 횟수 제한이 없어 무차별 대입이 가능함
- 결제 콜백에 서명 검증이 없어 「결제 완료」를 위조할 수 있음
- 쿠폰을 동시에 받을 수 있어 한 사람이 백 장을 받음
- 비밀번호 찾기 흐름을 우회해 타인의 비밀번호를 바로 재설정할 수 있음
이런 문제는 App 개발과 미니프로그램 개발에서 특히 주의할 가치가 있습니다. API 노출 면이 전통적인 웹사이트보다 넓기 때문입니다. 많은 사람이 「App에서는 API가 보이지 않으니 안전하다」고 생각하지만, 실제로는 패킷 캡처 도구를 켜면 요청이 훤히 보입니다.
회피 제안:
- 핵심 API에 빈도 제한과 리스크 제어 추가
- 결제, 환불 등 민감한 작업은 반드시 서버 측 서명 검증과 2차 확인을 거치기
- 비즈니스 상태 전이는 서버 측에서 판단하고, 프런트엔드가 보낸 상태를 신뢰하지 않기
五、의존성 구성 요소와 설정 문제
많은 기업 웹사이트가 문제를 겪는 이유는 직접 작성한 코드에 구멍이 있어서가 아니라, 사용하는 오픈소스 프레임워크와 플러그인 버전이 너무 오래되었기 때문입니다.
- 서드파티 CMS, 홈페이지 제작 시스템을 장기간 업데이트하지 않음
- 미들웨어 기본 설정을 바꾸지 않음. 예를 들어 백오피스 약한 비밀번호, 기본 포트 외부 개방
- 클라우드 서버 보안 그룹이 너무 크게 열려 있어 데이터베이스가 공용 인터넷에 직접 노출됨
- 테스트 환경, 백업 파일, .git 디렉터리가 운영 환경에 동기화됨
방법은 아주 소박합니다. 의존성을 정기적으로 업데이트하고, 배포 전에 설정 점검을 한 번 하고, 외부에 열면 안 되는 포트를 닫고, 운영 환경의 불필요한 디버그 파일을 삭제합니다.
어떤 경우에 MIC Studio를 찾는 것이 적합할까
프로젝트가 아래 몇 가지 상황에 해당하고, 자체 팀에 체계적으로 점검할 여력이 없다면 전문 팀에 한 차례 보안 테스트를 맡기는 것이 더 경제적입니다:
- 기업 웹사이트를 막 개편해 배포했고, 회원, 폼, 결제가 관련됨
- 미니프로그램 개발 또는 App 개발이 테스트 제출 단계에 들어갔고, API가 많고 로직이 복잡함
- 백오피스 관리 시스템이 다중 역할 권한을 다루며 권한 우회 위험이 높음
- 리버스 테스트가 필요하고, API가 대량 호출되거나 데이터가 크롤링될 위험을 평가해야 함
- 이미 보안 사고가 발생했고, 원인을 파악하고 강화 조치를 해야 함
MIC Studio의 방식은 먼저 자산과 API를 정리한 뒤, 인젝션, 권한, 업로드, 로직, 설정 방향으로 테스트를 진행하고, 재현 가능한 문제 목록과 수정 제안을 제공하는 것입니다. 이해하기 어려운 스캔 보고서만 주는 것이 아닙니다.
마무리: 바로 할 수 있는 세 가지
1. 배포 전에 권한 자체 점검을 한 번 하기: 모든 API를 나열하고, 하나씩 「로그인하지 않아도 접근할 수 있는가」「사용자 ID를 바꾸면 다른 사람 데이터를 볼 수 있는가」를 물어보기.
2. 입력과 출력을 잘 관리하기: 모든 사용자 입력을 검증하고, 모든 데이터베이스 작업을 파라미터화하고, 모든 오류 정보를 외부에 노출하지 않기.
3. 보안을 지속적인 행동으로 여기기: 의존성을 정기적으로 업데이트하고, 설정을 정기적으로 점검하고, 중요한 버전 배포 전에 한 차례 보안 테스트를 진행하기. 사고가 난 뒤에 보수하지 않기.
보안은 일회성 프로젝트가 아니라 개발 프로세스의 일부입니다. 조금 더 일찍 명확히 생각해두면 나중에 번거로움이 훨씬 줄어듭니다.