php 취약점 점검하고 막는 방법
얼마 전 정비 예약 사이트를 점검하면서 차량 사진을 올리는 기능과 관리자 계정을 먼저 확인했습니다. 예약 화면은 단순해 보여도 고객 이름과 연락처, 차량번호가 모이는 곳입니다. php 취약점은 PHP 자체의 보안 문제일 수도 있고, PHP로 만든 사이트의 코드나 설정에서 생길 수도 있습니다. 어디에 문제가 있는지 구분해야 손볼 순서도 분명해집니다.
서버의 PHP 버전부터 확인하기
가장 먼저 운영 서버에서 실제로 실행 중인 PHP 버전을 확인합니다. 개발자 컴퓨터의 버전이나 관리 화면에 적힌 숫자만 보면 놓치기 쉽습니다. 같은 서버에서도 웹 요청을 처리하는 PHP와 명령줄에서 실행하는 PHP의 버전이 다를 수 있기 때문입니다. 운영 환경의 버전과 배포판에서 제공한 보안 패치 적용 여부를 함께 확인해야 합니다.
2026년 10월 21일 PHP 공식 보안 공지는 인증 없이 원격 코드 실행으로 이어질 수 있는 취약점 두 건을 알렸습니다. 수정 버전은 PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12입니다. 해당 계열을 사용한다면 각 버전 이상으로 업데이트됐는지 우선 확인해야 합니다. 특히 이 문제는 예약 페이지의 입력 검사를 잘해 둔 사이트에도 영향을 줄 수 있어 애플리케이션 코드 수정만으로 대응할 수 없습니다. 리눅스 배포판이 수정 사항을 자체 패키지에 반영했다면 버전 숫자와 함께 공급업체의 패치 내역을 확인합니다.
PHP 8.1 이하는 PHP 프로젝트의 보안 지원이 끝났습니다. 오래된 예약 프로그램 때문에 업그레이드를 미뤘다면 테스트 환경에서 호환성을 확인한 뒤 지원 중인 버전으로 옮길 일정을 잡는 편이 안전합니다. 업데이트 후에는 웹 서버나 PHP 작업 프로세스가 새 버전으로 재시작됐는지도 확인해야 실제 요청에 수정 사항이 적용됩니다.
검색과 예약 입력은 데이터로만 다루기
차종 검색창에 입력한 글자를 SQL 문장에 그대로 이어 붙이면 SQL 삽입 문제가 생길 수 있습니다. 예를 들어 ‘아반떼’를 찾는 검색어는 검색할 값이어야지, 데이터베이스에 내릴 명령의 일부가 되어서는 안 됩니다. PHP의 PDO 준비된 명령문으로 SQL 구조를 먼저 만들고 검색어를 매개변수로 전달하면 이 경계를 지킬 수 있습니다.
다만 준비된 명령문만 썼다고 모든 검색 기능이 안전해지는 것은 아닙니다. 정렬할 열 이름이나 정렬 방향처럼 매개변수로 넣을 수 없는 부분은 서버에서 허용한 값 가운데 하나를 선택해야 합니다. 예약 번호를 전달받는 화면에서는 그 번호로 찾은 예약이 현재 로그인한 고객의 것인지도 확인해야 합니다. 입력값 처리와 접근 권한 검사는 서로 다른 문제입니다.
예약 후기나 문의 내용은 저장할 때보다 화면에 다시 표시할 때 주의가 필요합니다. 사용자가 쓴 글이 브라우저에서 코드로 해석되면 다른 방문자의 화면에 영향을 줄 수 있습니다. 일반적인 HTML 본문이나 속성에 값을 출력할 때는 문맥에 맞게 이스케이프하고, PHP에서는 htmlspecialchars에 따옴표 처리와 UTF-8 설정을 명시할 수 있습니다. 자바스크립트 안에 값을 직접 끼워 넣는 화면은 처리 방식이 달라 별도로 점검해야 합니다.
차량 사진 업로드와 관리자 계정 살피기
사고 사진이나 정비 견적서를 받는 업로드 기능은 파일 이름만 확인해서는 부족합니다. 허용할 확장자와 실제 파일 형식을 확인하고, 크기와 개수에 제한을 둡니다. 업로드한 파일은 서버가 실행 파일로 취급하지 않는 저장소에 두고, 가능하면 공개 웹 폴더 밖에서 관리하는 편이 좋습니다. OWASP의 파일 업로드 지침도 허용 목록, 저장 위치, 파일 크기 제한을 함께 다루도록 권합니다.
관리자 계정이 탈취되면 예약 목록과 고객 연락처가 한꺼번에 노출될 수 있습니다. 비밀번호는 평문으로 저장하지 않고 PHP의 password_hash로 해시한 뒤 password_verify로 확인합니다. 로그인 성공 뒤에는 세션 식별자를 새로 발급하고, 세션 쿠키에는 환경에 맞는 Secure, HttpOnly, SameSite 속성을 설정합니다. 관리자 권한이 필요한 화면에서는 로그인 여부만 확인하지 말고 해당 작업을 수행할 권한까지 검사해야 합니다.
예약 취소나 고객 정보 변경처럼 데이터를 바꾸는 요청에는 CSRF 방어도 필요합니다. 서버가 발급한 토큰을 요청과 함께 받아 검증하고, 조회용 요청만으로 예약이 취소되지 않게 만듭니다. SameSite 쿠키 설정은 이런 방어에 보탬이 되지만, OWASP는 많은 환경에서 토큰 검증과 함께 사용하도록 안내합니다.
점검 순서를 업무 흐름에 맞추기
운영자가 한꺼번에 모든 코드를 고치기는 어렵습니다. 먼저 PHP와 관련 패키지의 보안 업데이트를 적용하고, 그다음 고객 정보가 모이는 예약 조회·수정 화면과 사진 업로드, 관리자 로그인 기능을 확인합니다. 실제 고객 정보 대신 시험용 예약을 만들어 다른 계정에서 조회나 취소가 가능한지 확인하면 접근 권한 오류를 찾는 데 도움이 됩니다.
수정 뒤에는 정상적인 예약과 사진 업로드가 계속 되는지도 살펴야 합니다. 보안 설정이 지나치게 엄격해 고객의 휴대전화 사진까지 거부한다면 운영 중 다시 설정을 풀 가능성이 큽니다. 정비소에서 차량 상태를 확인할 때 한 부품만 보지 않듯, 사이트도 실행 환경과 입력 처리, 권한, 파일 보관 방식을 함께 점검하는 습관이 오래갑니다.
