PHP 취약점은 PHP 런타임, 애플리케이션 코드, 타사 패키지 또는 서버 구성의 약점으로, 웹사이트를 무단 액세스, 데이터 도난 또는 중단에 노출시킬 수 있습니다. 일반적인 예로는 SQL 인젝션, 크로스 사이트 스크립팅, 안전하지 않은 파일 업로드 및 잘못된 액세스 제어가 있습니다.
수정 방법이 다르기 때문에 구분이 중요합니다. 런타임 보안 결함에는 패치된 PHP 빌드가 필요합니다. 인증 오류에는 코드 또는 정책 변경이 필요합니다. PHP 업데이트는 필수적이지만, PHP로 구축된 웹사이트의 모든 약점을 자동으로 복구하지는 않습니다.
암호화폐 서비스의 경우, 출금 제어, API 자격 증명 및 지갑 사용자에게 표시되는 거래 세부 정보가 포함될 수 있습니다. 침해된 웹사이트가 비트코인의 합의 규칙이나 블록체인의 암호화가 손상되었음을 의미하지는 않습니다.
지원되고 패치된 소프트웨어로 시작하기
보안 업데이트, 2026년 10월 22일: PHP의 10월 21일 권고는 두 가지 치명적인 원격 코드 실행 취약점인 CVE-2026-109618 및 CVE-2026-109619를 식별했습니다. 지원되는 분기에 대한 수정된 릴리스는 PHP 8.5.12, 8.4.27, 8.3.36 및 8.2.35였습니다. PHP 팀은 사용자에게 업데이트를 촉구했으며, 임시 완화 조치는 패치를 완전히 대체할 수 없습니다. 공식 보안 공지 및 호스팅 제공업체의 지침을 확인하십시오.
해당 수정된 릴리스 또는 이후 패치된 안정 버전을 사용하십시오. 배포판 공급업체는 보안 수정을 백포트할 수 있으므로 버전 문자열만으로 판단하지 말고 패키지의 권고 상태를 확인하십시오. 웹 서버 런타임(명령줄 PHP뿐만 아니라)이 업데이트되었고 관련 워커가 다시 시작되었는지 확인하십시오.
업그레이드 계획도 유지하십시오. PHP 8.2의 업스트림 보안 지원은 2026년 12월 31일에 종료됩니다. 이 특정 패치를 받는다고 해서 정상적인 지원 수명 주기가 연장되는 것은 아닙니다.
SQL 인젝션: 쿼리 구조에 데이터 삽입 방지
SQL 인젝션은 신뢰할 수 없는 입력이 데이터베이스 명령의 일부가 될 때 발생합니다. 주요 수정 방법은 사용자 입력을 SQL 문자열에 연결하는 대신 준비된 문을 통해 데이터 값을 바인딩하는 것입니다. PHP의 PDO 설명서는 분리 방법을 설명합니다.
예를 들어, 비공개 기사 조회는 검증된 기사 ID와 인증된 사용자의 서버 측 ID를 모두 바인딩할 수 있습니다.
$stmt = $pdo->prepare(
'SELECT id, title FROM articles
WHERE id = :id AND owner_id = :owner'
);
$stmt->execute([
'id' => $articleId,
'owner' => $authenticatedUserId,
]);자리 표시자는 데이터 값을 보호하며 임의의 테이블 이름, 열 이름 또는 정렬 방향을 보호하지는 않습니다. 이러한 선택을 고정된 허용 값에 매핑하십시오. 데이터베이스 권한도 제한하십시오. 애플리케이션은 전체 데이터베이스를 관리할 수 있는 계정이 거의 필요하지 않습니다.
크로스 사이트 스크립팅: 출력 컨텍스트에 맞게 인코딩
크로스 사이트 스크립팅(XSS)은 신뢰할 수 없는 콘텐츠가 실행 가능한 브라우저 콘텐츠로 해석될 때 발생합니다. 페이지가 댓글, 프로필 필드 또는 가져온 문서를 잘못 렌더링하면 위험해질 수 있습니다.
프레임워크의 자동 이스케이프를 사용하고 신뢰할 수 없는 데이터를 실행 가능한 컨텍스트에 넣지 마십시오. 일반 HTML 태그 사이에 배치된 일반 텍스트의 경우, PHP의 htmlspecialchars()와 명시적인 UTF-8 처리가 적절한 도구입니다. JavaScript, CSS 또는 URL에 대한 보편적인 해결책은 아닙니다.
사용자가 풍부한 HTML을 제출해야 하는 경우, 전체 입력을 신뢰할 수 있는 것으로 취급하는 대신 유지 관리되는 허용 목록 기반 HTML 새니타이저를 사용하십시오. 콘텐츠 보안 정책은 또 다른 계층을 추가합니다. 콘텐츠의 올바른 처리를 대체하지는 않습니다. 이러한 구분은 OWASP의 XSS 방지 지침에 설명되어 있습니다.
업로드 및 파일 처리: 서버가 수락하는 내용 제어
업로드 기능은 사용자가 서버에 어떤 실행 파일을 배치할지 결정하도록 해서는 안 됩니다. 제품에 필요한 파일 유형만 허용하고, 브라우저가 선언한 MIME 유형을 신뢰하기보다는 콘텐츠를 확인하며, 크기 제한을 적용하고, 서버 측 파일 이름을 생성하십시오.
신뢰할 수 없는 업로드는 웹 루트 외부 또는 별도의 저장소에 저장하고 검색을 제어하십시오. 제공되는 구성이 업로드된 콘텐츠를 실행할 수 없도록 하십시오. 인증, 권한 부여 및 적절한 악성 코드 또는 콘텐츠 검사는 추가적인 보호 기능을 제공합니다. OWASP의 파일 업로드 지침은 이러한 제어를 결합할 것을 권장합니다.
파일 경로 및 가져오기에도 동일한 규율을 적용하십시오. 사용자 대면 문서 ID를 승인된 서버 측 파일에 매핑하고, 원시 요청 값을 파일 포함 함수에 전달하지 마십시오. 신뢰할 수 없는 입력을 셸 명령, 또는 PHP 객체 역직렬화에 전달하지 마십시오. 더 안전한 API와 검증된 데이터 형식을 사용하면 이러한 위험한 작업의 필요성이 줄어듭니다.
인증, 세션 및 CSRF에는 별도의 제어가 필요합니다
인증은 사용자가 누구인지 확인하는 것이고, 권한 부여는 해당 사용자가 무엇을 할 수 있는지 결정하는 것입니다. 작동하는 로그인 페이지가 계정 기록, 다운로드 또는 관리 작업이 보호된다는 것을 증명하지는 않습니다. 모든 민감한 작업 및 개체에 대해 서버에서 권한을 확인하십시오.
password_hash() 및 password_verify()와 같은 검증된 암호 처리 함수를 사용하고, MFA로 관리 계정을 보호하며, 악의적인 로그인 시도를 제한하십시오. 세션의 경우 HTTPS를 적용하고, 적절한 Secure, HttpOnly 및 SameSite 쿠키 속성을 구성하며, 인증 또는 권한 변경 후 세션 식별자를 갱신하고, 로그아웃 시 세션을 무효화하십시오. 사용자 정의 세션 체계를 발명하는 대신 OWASP의 세션 관리 지침을 따르십시오.
쿠키 인증 상태 변경 요청에도 CSRF 보호가 필요합니다. 가능한 경우 서버 측 토큰 유효성 검사를 포함하여 프레임워크의 유지 관리되는 구현을 선호하십시오. SameSite 쿠키는 심층 방어에 유용하지만 모든 배포 또는 요청 흐름을 보호한다고 가정해서는 안 됩니다. 민감한 상태 변경을 수행하기 위해 GET 요청을 사용하지 마십시오.
구성 및 종속성은 애플리케이션의 일부입니다
잘 작성된 컨트롤러라도 안전하지 않은 배포 내에 있을 수 있습니다. 자격 증명, 개인 키, 구성 비밀 및 백업을 공개 디렉터리에서 멀리하십시오. 프로덕션 환경에서 상세한 오류 표시를 비활성화하는 동시에, 불필요한 비밀을 수집하지 않고 실패를 조사하는 데 도움이 되는 액세스 제어 로그를 유지하십시오.
전체 종속성 목록을 검토하십시오. PHP 런타임, 확장 프로그램, 프레임워크, CMS, 플러그인 및 Composer 패키지입니다. Composer의 audit 명령은 종속성의 보고된 보안 문제를 식별할 수 있지만, 사용자 정의 애플리케이션 로직이 안전하다고 보증할 수는 없습니다.
애플리케이션에 대해 업데이트를 테스트하고 검토된 종속성 버전에서 재현 가능한 배포를 수행하십시오. 사용되지 않는 구성 요소를 영구적으로 노출된 상태로 두지 말고 제거하십시오. 애플리케이션 프로세스가 서버의 모든 것을 다시 쓸 수 없도록 파일 시스템 권한을 제한하고, 개발 도구를 프로덕션과 분리하십시오.
PHP 취약점이 암호화폐 웹사이트에 미치는 영향
암호화폐 웹사이트의 애플리케이션 계층은 연결된 블록체인과 별도로 공격받을 수 있습니다. 다음은 명명된 거래소나 지갑에 대한 조사가 아니라 아키텍처 위험 시나리오입니다.
| 암호화폐 위험 | 무슨 일이 일어날 수 있나요? | 실질적인 제어 |
|---|---|---|
| 수탁 계정 또는 출금 남용 | 세션 납치 또는 약한 서버 측 권한 부여 | 민감한 작업에 다시 인증하고 정확한 수신자 및 금액에 대한 승인을 바인딩하십시오. |
| 입금 주소 또는 서명 속임수 | 변경된 웹페이지 콘텐츠 또는 오해의 소지가 있는 거래 설명 | 신뢰할 수 있는 지갑 인터페이스 또는 읽기 쉬운 하드웨어 지갑 디스플레이에서 네트워크, 수신자, 자산 및 금액을 확인하십시오. |
| API 자격 증명 노출 | 코드, 로그 또는 공개 파일을 통한 비밀 키 유출 | 키를 서버 측에 보관하고, 권한을 좁게 범위 지정하고, 불필요한 경우 출금 권한을 생략하고, 노출된 자격 증명을 순환하십시오. |
개인 키를 보호한다고 해서 해당 키를 사용할 결정이 자동으로 보호되는 것은 아닙니다. Trezor의 클리어 사인 지침은 침해된 프런트 엔드가 거래를 잘못 설명할 수 있는 이유를 설명합니다. 의미 있게 확인할 수 없는 요청을 승인하거나 보안 업데이트가 필요하다고 주장하는 웹사이트에 시드 문구를 입력하지 마십시오.
관련 패치 또는 코드 변경을 적용한 다음 보안 제어와 정상적인 사용자 동작을 모두 테스트하십시오. 음성 테스트를 포함하십시오. 사용자는 식별자를 변경하는 것만으로 다른 사람의 기록에 액세스할 수 없어야 합니다. 소유하거나 명시적으로 평가 권한이 있는 시스템에 대해서만 보안 테스트를 실행하십시오.
침해가 의심되는 경우, 패치는 복구의 일부일 뿐입니다. 사고를 격리하고, 유용한 증거를 보존하며, 지속성 및 노출된 자격 증명을 조사하고, 확인된 깨끗한 상태에서 복원하십시오. 방화벽 규칙이나 깨끗한 스캐너 결과가 공격자의 액세스가 제거되었음을 확립하지는 않습니다.
자주 묻는 질문
PHP는 본질적으로 안전하지 않나요?
아니요. 위험은 런타임 버전, 애플리케이션 설계, 종속성 및 배포에 따라 달라집니다. PHP 애플리케이션은 여전히 일상적인 보안 유지 관리가 필요합니다.
PHP 업그레이드가 SQL 인젝션 및 XSS를 수정하나요?
반드시 그런 것은 아닙니다. 런타임 업데이트는 런타임 취약점을 수정합니다. 안전하지 않은 쿼리 구성 및 출력 처리는 일반적으로 애플리케이션 변경이 필요합니다.
HTTPS가 PHP 취약점을 방지하나요?
아니요. HTTPS는 전송 중인 데이터를 보호합니다. 잘못된 권한, 안전하지 않은 업로드 또는 취약한 서버 측 코드를 수정하지는 않습니다.
웹 애플리케이션 방화벽이 패치를 대체할 수 있나요?
아니요. 일부 노출을 줄일 수는 있지만 근본적인 소프트웨어 결함이나 애플리케이션 로직을 안정적으로 복구할 수는 없습니다.
결론
PHP 취약점에는 하나의 보편적인 수정 방법이 없습니다. 런타임 및 종속성을 패치하고, 데이터베이스 값을 SQL과 분리하고, 브라우저 출력을 안전하게 처리하고, 업로드를 제한하고, 서버 측 액세스 제어를 시행하십시오.
암호화폐 애플리케이션의 경우 출금 승인, API 자격 증명 및 지갑 관련 거래 세부 정보도 보호하십시오. 각 약점을 올바른 제어와 일치시키고 배포 후 해당 제어를 확인하십시오. 업데이트, 안전한 코딩 및 운영 모니터링은 함께 작동합니다. 어느 것도 다른 것을 대체하지는 않습니다.
