PDO 안티 인젝션 원리 분석 및 PDO_php 스킬 사용 시 주의사항 요약

이 글은 PDO의 주입 방지 원리 분석과 PDO 사용 시 주의 사항을 자세히 설명하고 참고할 수 있도록 모든 사람과 공유합니다. 구체적인 분석은 다음과 같습니다.

우리 모두는 PDO를 합리적이고 올바르게 사용하면 SQL 삽입을 기본적으로 예방할 수 있다는 것을 알고 있습니다. 이 기사에서는 주로 다음 두 가지 질문에 답합니다.
mysql_connect 대신 PDO를 사용하는 이유는 무엇입니까?
PDO가 주입 방지인 이유는 무엇입니까?
PDO를 사용할 때 주입 방지를 위해 특별히 주의해야 할 점은 무엇인가요?

1. PDO 사용을 우선시해야 하는 이유는 무엇인가요?

PHP 매뉴얼에는 다음과 같이 매우 명확하게 나와 있습니다.
준비된 문 및 저장 프로시저
더 성숙한 데이터베이스 중 다수는 준비된 문 개념을 지원합니다. 이는 응용 프로그램이 실행하려는 SQL에 대한 일종의 컴파일된 템플릿으로 간주할 수 있으며, 준비된 문은 두 가지를 제공합니다. 주요 혜택:

쿼리는 한 번만 구문 분석(또는 준비)하면 되지만 동일하거나 다른 매개변수를 사용하여 여러 번 실행할 수 있습니다. 쿼리가 준비되면 데이터베이스는 실행 계획을 분석, 컴파일 및 최적화합니다. 쿼리가 복잡한 경우 이 프로세스는 시간이 많이 걸릴 수 있으므로 다른 매개변수를 사용하여 동일한 쿼리를 여러 번 반복해야 하는 경우 애플리케이션이 분석/컴파일을 반복하지 않아도 됩니다. /optimize 주기. 이는 준비된 명령문이 더 적은 리소스를 사용하므로 더 빠르게 실행된다는 것을 의미합니다.

Prepared 문에 대한 매개 변수는 따옴표로 묶을 필요가 없습니다. 애플리케이션이 준비된 문을 독점적으로 사용하는 경우 개발자는 SQL 주입이 발생하지 않는다고 확신할 수 있습니다(그러나 다른 부분에서는 이스케이프되지 않은 입력으로 쿼리가 작성되고 있지만 SQL 삽입은 여전히 ​​가능합니다.

PDO의 prepare 메소드를 사용해도 주로 동일한 SQL 템플릿의 쿼리 성능을 향상시키고 SQL 주입을 방지합니다
동시에 PHP 매뉴얼에는 경고 메시지가 나와 있습니다
PHP 5.3.6 이전에는 이 요소가 자동으로 무시되었습니다. 다음 예제와 같이 PDO::MYSQL_ATTR_INIT_COMMAND 드라이버 옵션을 사용하여 동일한 동작을 부분적으로 복제할 수 있습니다.
경고
아래 예의 방법은 ISO-8859-1 및 UTF-8과 같이 ASCII와 동일한 하위 7비트 표현을 공유하는 문자 세트에만 사용할 수 있습니다(예: UTF-16). 또는 Big5)는 PHP 5.3.6 이상 버전에서 제공되는 charset 옵션을 사용해야 합니다.

즉, PHP 5.3.6 및 이전 버전에서는 DSN의 charset 정의가 지원되지 않습니다. 대신 PDO::MYSQL_ATTR_INIT_COMMAND를 사용하여 일반적으로 사용되는 set names gbk 명령인 초기 SQL을 설정해야 합니다.

아직도 삽입을 방지하기 위해 addlash를 사용하려는 프로그램을 본 적이 있지만 실제로는 더 많은 문제가 있습니다. 자세한 내용은 http://www.jb51.net/article/49205.htm 또한 몇 가지 방법이 있습니다. 데이터베이스 쿼리를 실행하기 전에 SQL에서 select, Union, ....과 같은 키워드를 정리합니다. 이 접근 방식은 제출된 텍스트에 학생회가 포함되어 있는 경우, 대체 텍스트가 원래 내용을 변조하여 무고한 사람들을 무차별적으로 죽이는 것이므로 바람직하지 않습니다.


2. PDO가 SQL 주입을 방지할 수 있는 이유는 무엇인가요?
먼저 다음 PHP 코드를 살펴보세요.

코드 복사 코드는 다음과 같습니다.

$pdo = new PDO("mysql:host=192.168.0.1;dbname=test;charset=utf8","root");
$st = $pdo->prepare("ID =? 및 이름 = ?인 정보에서 *를 선택하세요.");

$id = 21;
$name = '장산';
$st->bindParam(1,$id);
$st->bindParam(2,$name);

$st->execute();
$st->fetchAll();
?>


환경은 다음과 같습니다.
PHP 5.4.7
MySQL 프로토콜 버전 10
MySQL 서버 5.5.27

PHP와 MySQL 서버 간의 통신 내용을 자세히 이해하기 위해 특별히 Wireshark를 사용하여 연구용 패킷을 캡처한 후 아래와 같이 필터 조건을 tcp.port==3306으로 설정했습니다.



이런 방식으로 불필요한 간섭을 피하기 위해 mysql 3306 포트와의 통신 데이터만 표시됩니다.
Wireshak은 wincap 드라이버를 기반으로 하며 로컬 루프백 인터페이스에서 청취를 지원하지 않는다는 점에 유의하는 것이 중요합니다(PHP를 사용하여 로컬 mysql에 연결하더라도 청취할 수 없음). 다른 머신(가상)에서 MySQL에 연결하십시오. 브리지된 네트워크의 컴퓨터도 테스트할 수 있습니다.

그런 다음 PHP 프로그램을 실행하면 청취 결과는 다음과 같습니다. PHP는 단순히 SQL을 MySQL 서버로 직접 보냅니다.



사실 이는 문자열을 이스케이프한 다음 이를 SQL 문으로 연결하기 위해 mysql_real_escape_string을 일반적으로 사용하는 것과 다르지 않습니다(PDO 로컬 드라이버에 의해서만 이스케이프됩니다). 분명히 이 경우 SQL 주입이 여전히 가능합니다. say pdo prepare에서 mysql_real_escape_string을 호출하여 쿼리를 실행하기 위해 PHP에서 로컬로 호출할 때 로컬 단일 바이트 문자 집합이 사용되며, 멀티 바이트 인코딩 변수를 전달하면 여전히 SQL 주입 취약점이 발생할 수 있습니다(PHP 5.3.6 이전). 문제 중 PDO를 사용할 때 PHP 5.3.6으로 업그레이드하고 DSN 문자열에 문자 세트를 지정하는 것이 권장되는 이유를 설명합니다.
PHP 5.3.6 이전 버전의 경우 다음 코드로 인해 여전히 SQL 삽입 문제가 발생할 수 있습니다.

코드 복사 코드는 다음과 같습니다.

$pdo->query('SET NAMES GBK')

$var = chr(0xbf) . chr(0x27) . " OR 1=1 /*"; $query = "SELECT * FROM 정보 WHERE 이름 = ?"; $stmt = $pdo->준비($query)
$stmt->execute(array($var));


그 이유는 위의 분석과 일치한다.

올바른 이스케이프는 mysql Server에 대한 문자 세트를 지정하고 변수를 MySQL Server로 보내 문자 이스케이프를 완료하는 것입니다.

그렇다면 어떻게 PHP 로컬 이스케이프를 금지하고 MySQL 서버가 이를 이스케이프하도록 할 수 있습니까?
PDO에는 PHP를 사용하여 로컬에서 준비를 시뮬레이션할지 여부를 나타내는 PDO::ATTR_EMULATE_PREPARES라는 매개변수가 있습니다. 그리고 방금 본 패킷 캡처 및 분석 결과에 따르면 PHP 5.3.6은 여전히 ​​기본적으로 로컬 변수를 사용하여 이를 SQL로 연결하여 MySQL 서버로 전송합니다. 다음 코드:

코드 복사 코드는 다음과 같습니다. $pdo = new PDO("mysql:host=192.168.0.1;dbname=test;","root");

$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);//방금 추가한 내용입니다

$st = $pdo->prepare("ID =? 및 이름 = ?인 정보에서 *를 선택하세요.");
$id = 21;
$name = '장산';

$st->bindParam(1,$id);
$st->bindParam(2,$name);
$st->execute();
$st->fetchAll();
?>


프로그램을 실행하고 Wireshark를 사용하여 패킷을 캡처하고 분석하면 다음과 같습니다.

보셨나요? 이것이 바로 마술입니다. 이번에는 PHP가 SQL 템플릿과 변수를 두 번에 걸쳐 MySQL로 보내고, MySQL은 변수와 SQL 템플릿을 두 번에 걸쳐 이스케이프 처리하는 것을 볼 수 있습니다. SQL 주입 문제는 해결되었지만 DSN에 charset 속성을 다음과 같이 지정해야 합니다.

코드 복사 코드는 다음과 같습니다.$pdo = new PDO('mysql:host=localhost;dbname= test;charset =utf8', 'root');

이를 통해 SQL 인젝션 문제를 근본적으로 해소할 수 있다. 이에 대해 명확하지 않은 경우 zhangxugg@163.com으로 이메일을 보내 함께 논의할 수 있습니다.

3. PDO 사용시 주의사항

위의 사항을 알고 나면 SQL 삽입을 방지하기 위해 PDO를 사용할 때의 몇 가지 주의 사항을 요약할 수 있습니다.

1. PHP를 5.3.6으로 업그레이드합니다. 프로덕션 환경의 경우 PHP 5.3.9로 업그레이드하는 것이 좋습니다. PHP 5.3.8에는 치명적인 해시 충돌 취약점이 있습니다.

2. PHP 5.3.6을 사용하는 경우 PDO의 DSN에 charset 속성

을 지정하십시오.

3. PHP 5.3.6 및 이전 버전을 사용하는 경우 PDO::ATTR_EMULATE_PREPARES 매개변수를 false로 설정하세요(즉, MySQL은 변수 처리를 수행함). , 여부에 관계없이 로컬 시뮬레이션 준비를 사용하거나 mysql 서버 준비를 호출할 수 있습니다. DSN에 문자 세트를 지정하는 것은 유효하지 않으며 세트 이름 의 실행이 필수적입니다.

4. PHP 5.3.6 이하 버전을 사용하는 경우 Yii 프레임워크에서는 기본적으로 ATTR_EMULATE_PREPARES 값을 설정하지 않으므로 데이터베이스 구성 파일에서 emulatePrepare 값을 false로 지정하시기 바랍니다.

그렇다면 질문이 있습니다. DSN에 charset이 지정된 경우에도 세트 이름 을 실행해야 합니까?

네, 저장할 수 없습니다. 세트 이름 에는 실제로 두 가지 기능이 있습니다:

A. 클라이언트(PHP 프로그램)가 제출한 인코딩을 mysql 서버에 알려줍니다.
B. mysql 서버에 클라이언트가 요구하는 결과의 인코딩이 무엇인지 알려주세요

즉, 데이터 테이블이 gbk 문자 세트를 사용하고 PHP 프로그램이 UTF-8 인코딩을 사용하는 경우 쿼리를 실행하기 전에 세트 이름 utf8을 실행하고 mysql 서버에 이를 올바르게 인코딩하도록 지시할 수 있습니다. 프로그램에서 인코딩할 필요가 없습니다. 이런 방식으로 우리는 utf-8 인코딩으로 mysql 서버에 쿼리를 제출하고, 얻은 결과도 utf-8 인코딩으로 표시됩니다. 이렇게 하면 프로그램에서 변환 인코딩 문제가 해결됩니다. 이렇게 하면 잘못된 코드가 생성되지 않습니다.

그러면 DSN에서 문자 세트를 지정하는 역할은 무엇입니까? 로컬 드라이버가 이스케이프할 때 지정된 문자 세트를 사용한다는 것을 PDO에 알려줄 뿐입니다(mysql 서버 통신 문자 세트를 설정하지 않음). 세트 이름 지시어를 사용하세요.

일부 새 프로젝트에서는 왜 PDO를 사용하지 않고 전통적인 mysql_XXX 함수 라이브러리를 사용하는지 정말 알 수 없습니다. PDO를 올바르게 사용하면 SQL 주입이 근본적으로 제거될 수 있습니다. 각 회사의 기술 리더와 최전선 기술 R&D 인력은 이 문제에 주의하고 최대한 PDO를 사용하여 프로젝트 진행 속도와 안전 품질을 높일 것을 강력히 권장합니다. .

자신만의 SQL 주입 필터링 라이브러리를 작성하려고 하지 마십시오(지루하고 알 수 없는 취약점이 쉽게 생성될 수 있음).

이 기사가 모든 사람의 PHP 프로그래밍 설계에 도움이 되기를 바랍니다.