PHP 인젝션과 file_get_contents의 관계

최근 웹호스팅을 사용하는 한 사이트에서 똑같은 프로그램임에도 불구하고 기능이 잘 동작하지 않는 다는 이야기를 듣고 간단하게 몇가지 조사해 보니 file_get_contents() 함수가 정상적인 동작을 하지 않더군요. file_get_contents() 함수는 파라미터로 외부 사이트의 URL을 입력하면 해당 페이지의 내용을 가져와서 문자열로 리턴해 주는 개발자 입장에서는 매우 유용한 함수인데 해커들이 이런 함수를 통해서 인젝션(Injection) 공격을 수행하기 때문에 PHP 설정중에 allow_url_fopen를 0으로 설정해서 fopen(), file(), file_get_contents() 등의 함수에서 외부 URL을 사용할 수 없도록 한다는 이야기 였습니다. 해당 함수 사용 과정에 위험성이 있는지 검증해서 괜찮다고 판단하고 사용하고자 하더라도 카페24(cafe24) 등의 웹호스팅을 사용한다면 사용자가 설정을 수정할 수 있도록 기능을 제공하지 않기 때문에 이런 경우에는 아래와 같은 코드를 삽입해서 실행 과정중에 설정을 변경 적용할 수는 있습니다.

@ini_set("allow_url_fopen","1");

이왕 인젝션 공격에 대한 이야기가 나왔으므로 PHP 환경의 인젝션 공격과 file_get_contents() 함수의 관계를 통해서 여러 공격 형태를 살펴보고 소스 코드에서 어떻게 대비해야 될지 살펴볼까 합니다.

인젝션 공격은 웹 클라이언트(브라우저)에서 웹서버(아파치, IIS 등등)로 정보를 전송하는 과정에 임의의 데이터를 삽입해서 웹서버 개발자가 의도하지 않은 대로 코드를 동작시켜서 공격자의 의도를 이루거나 시스템에 손상을 가하는 일련의 행위를 지칭합니다. Cross-Site Scripting(XSS), SQL 인젝션, 코드(Code) 인젝션, 로그(Log) 인젝션등이 이 범주에 포함됩니다.

■ 크로스 사이트 스크립팅(Cross-Site Scripting, XSS)

많은 웹사이트에서 가장 많이 당하는 공격 형태이고 보안 취약성 점검툴에서도 가장 많이 검출해내는 공격 방식입니다. 단순히 정적 HTML 페이지만 보여주는 웹서버라면 공격을 받을 가능성이 매우 낮은 방식으로 많은 경우 텍스트 입력 항목등에 HTML이나 자바 스크립트(Java Script), CSS 마크업을 삽입해서 그 내용을 웹서버에서 다시 결과 페이지로 내려줄때 입력 내용이 단순 입력 내용이 아니라 공격자의 의도에 따라 동작하게 하는 공격 방식입니다. 웹 브라우저에서 동작하지만 적절한 대비를 하지 못하면 많은 사용자에게 파급되는 폭발력이 있기 때문에 매우 주의해야 합니다. 

사용자가 자바 스크립트를 입력할 수 있는 통로가 있다면 공격자는 document.write()와 같은 자바 스크립트 함수를 통해서 웬만한 동적 페이지를 웹브라우저에 구동시킬 수 있고, document.cookie.escape()와 같은 함수를 통해서 사용자 정보를 빼갈 수도 있습니다. AJAX 환경이 있다면 정보 유출과 공격에 날개를 달아주는 격이 되고 맙니다. 서버로 부터 내려온 페이지 결과는 웹 브라우저의 입장에서 보면 신뢰할 만한 내용이기 때문입니다. 

대비책의 첫번째는 철저한 입력 검사로 시작합니다. 이름이나 직업란에 HTML 태그를 입력할 수 없도록 제한하는 것과 같습니다. 게시판의 내용 입력란의 경우처럼 자유로운 입력을 받는 경우에도 HTML 태그와 자바 스크립트를 금지 시키거나 제한된 사용된 허용하는 방식으로 입력 검사 시점 부터 필터링할 필요가 있습니다. 문제성이 있는 입력 데이터를 오류 메시지와 함께 그대로 출력해버리면 이 또한 공격자들이 원하는 것이므로 인코딩(Encoding) 또는 에스케이프(Esacpe) 기능을 적절하게 사용해야 합니다. 예를 들어 자바스크립트나 HTML 태그를  표시하는 '<' , '>' 문자를 &gt; &lt;등으로 바꾸어서 웹 브라우저에서는 입력한 데이터를 삽입한 코드가 아니라 단순 텍스트로 취급하도록 할 수 있습니다. 따옴표를 포함하여 HTML로 사용하는 여러 특수 문자를 유사한 방식으로 인코딩하려면 htmlspecialchars() htmlentities() 함수를 참조합니다. 입력 자료를 인코딩 처리해서 출력하거나 문제 있는 부분을 삭제하든지 꼭 필요한 것은 입력 의도에 맞는 데이터인지 반드시 철저한 검사를 수행해야 한다는 것입니다. 웹 브라우저의 버전에 따라 약간의 차이가 있지만 HTML 헤더에 Content Security Policy (CSP) 메타 태그를 활용해서 현재 페이지에서 다른 페이지로 연동할 수 있는 신뢰할 수 있는 사이트를 지정하는 것도 또다른 예방책의 하나입니다. 엄밀히 말하면 XSS 공격은 PHP가 아닌 다른 웹 스크립트 언어를 사용하더라도 동일하게 대면할 수 밖에 없는 위협입니다.

■ SQL 인젝션

APM(Apache, PHP, MySQL) 환경에서 빈번하게 노출되던 위협입니다. 사용자가 입력한 자료를 기반으로 데이터베이스에 질의를 수행하는 과정에서 데이터베이스 질의를 위한 SQL에 비정상적인 데이터를 삽입해서 시스템에 손상을 가하거나 비정상적으로 로그인 권한을 취득해서 정보를 유출시키거나 시스템을 비정상적으로 사용하는 공격입니다. 

$db->query( "SELECT * FROM members WHERE user_id = ". $_POST['user_id']);

예를 들어 위와 같은 로그인 검사 로직이 있다면 정상적인 경우에는 데이터베이스에 저장되어 있는 사용자 아이디를 정확하게 입력해야 되지만 아이디를 몰라도 user_id 항목에 "1 or 1" 로 입력하면 실제 SQL 문장은 "WHERE user_id = 1 or 1"로 되어 WHERE 구절은 항상 참(True)인 상태가 됩니다. 이러한 방식으로 관리자 권한을 취득한다면 시스템의 모든 정보가 유출되는 것은 시간 문제일 뿐입니다.

최근에는 SQL의 문자열 비교에 사용하는 작은 따옴표(')가 SQL 요소가 아니라 단순 문자열로 취급되도록 웹 입력 자료에 자동으로 백슬래시(\)를 붙여서 에스케이프(Escape)하는 magic_quotes_gpc PHP 설정을 반영해 놓고 사용하는데 addslashes() 함수를 통해서 작업할 수도 있습니다. 그렇지만 이러한 방식도 위의 예제 처럼 문자열이 아닌 항목에 대한 공격을 막지는 못하므로 입력 자료의 사전 검사를 꼭 수행해야 합니다.

또 다른 예방법은 개발자가 약간 불편할 수 있지만 사용자가 SQL에 대한 변형을 할 수 없도록 원천적으로 차단하는 방법으로 동적으로 SQL을 조립하지 않고 미리 SQL 파싱을 요구하고 실행시점에 필요한 내용만 전달하는 Prepared Statements 또는 Parameterised Queries를 사용하는 것입니다. 이 방법을 사용하면 사용자의 비정상적인 데이터 전달로 인한 오동작이나 공격을 모두 예방할 수 있고 다중 질의의 경우 데이터베이스 질의 속도도 개선하는 효과도 있습니다.

■ 코드(Code) 인젝션

서버의 PHP 코드 실행 과정에 공격자의 코드를 삽입시키는 위협으로 가장 많은 공격은 서버에서 수행 코드를 내포시키는 include(), include_once(), require(), require_once() 함수들을 대상으로 해서 자신의 코드가 실행 과정에 반영되도록 하는 것입니다. 

include ($_GET['id'].".php");

위의 사례처럼 웹 입력 자료를 기반으로 이들 함수를 사용한다면 철저한 사전 검사를 해야 합니다. 또다른 코드 인젝션의 위험성은 eval() 함수 사용입니다. eval() 함수로 PHP 코드를 문자열로 전달하면 그대로 수행하기 때문에 eval() 함수 파라미터가 혹여라도 웹 입력과 연관성이 있다면 철저한 사전 검사를 반드시 수행해야 합니다.

■ 경로 변형

단순 로컬 뿐만아니라 HTTP, FTP 자원도 읽을 수 있는 URI()를 인식하는 include(), file(), require(), file_get_contents()등의 함수에 대한 공격으로 개발자가 의도하지 않은 다른 사이트나 디렉토리에 접근하려는 공격입니다. 이들 함수의 호출 과정에 웹 입력 자료가 연관된다면 반드시 사전 검증이 이루어져야 합니다.

기존 경로에 웹 입력 데이터를 붙이는 경우에도 "../"와 같은 경로가 붙여지면 개발자의 의도와는 어긋나는 결과가 되기 때문에 이런 경로를 걸러내는 작업이 꼭 필요합니다.

PHP 환경에서의 몇가지 인젝션 공격 형태를 살펴보았지만 뭐니뭐니해도 꼼꼼한 입력 검사와 철저한 환경 설정 확인 만이 서버를 안정적으로 운영하는 방법으로 보입니다. 물론 꼼꼼한 검사는 속도 저하와 코드의 복잡화를 유발할 수도 있지만 이또한 효과적인 공동 루틴 활용과 커뮤니티의 꾸준한 모니터링으로 효과적으로 대처할 수 있으리라 보입니다. "PHP는 무조건 보안에 약해!" 하는 말은 무식의 발로가 아닌가 싶습니다. 약간의 대비로 보안에 약하다는 오명을 씻는 PHP 프로그래밍이 되어야 겠습니다.