PDO 주입 방지 원리 분석 및 예방 조치_php 기술

우리 모두는 PDO를 합리적이고 올바르게 사용하면 SQL 삽입을 기본적으로 예방할 수 있다는 것을 알고 있습니다. 이 기사에서는 주로 다음 두 가지 질문에 답합니다.

mysql_connect 대신 PDO를 사용하는 이유는 무엇입니까?

PDO 항주사제인 이유는 무엇인가요?

PDO를 사용할 때 주입 방지를 위해 특별히 주의해야 할 점은 무엇인가요?

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

PHP 매뉴얼에는 다음과 같이 매우 명확하게 나와 있습니다.

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

준비된 문 및 저장 프로시저
더 성숙한 데이터베이스 중 다수는 준비된 문 개념을 지원합니다. 이는 응용 프로그램이 실행하려는 SQL에 대한 일종의 컴파일된 템플릿으로 간주할 수 있으며, 준비된 문은 두 가지를 제공합니다. 주요 이점:

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

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.lorui.com/addslashes-mysql_escape_string을 참조하세요. -mysql_real_eascape_string.html

또한 몇 가지 방법이 있습니다. 데이터베이스 쿼리를 실행하기 전에 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를 사용하여 연구용 패킷을 캡처했습니다. Wireshak을 설치한 후 필터 조건을 아래와 같이 tcp.port==3306으로 설정했습니다.

불필요한 간섭을 피하기 위해 mysql 3306 포트와의 통신 데이터만 표시됩니다.

wireshak은 wincap 드라이버를 기반으로 하며 로컬 루프백 인터페이스에서 청취를 지원하지 않는다는 점에 유의하는 것이 중요합니다(PHP를 사용하여 로컬 mysql 메소드에 연결하더라도 청취할 수 없습니다). 머신(브리지 네트워크가 있는 가상 머신도 사용 가능) ) 테스트용 MySQL.

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

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

5.3.6 이전 PHP 버전의 경우 다음 코드로 인해 SQL 삽입 문제가 발생할 수 있습니다.

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

$pdo->query('SET NAMES GBK');
$var = chr(0xbf) . chr(0x27) . " OR 1=1 /*";
$query = "SELECT * FROM 정보 WHERE 이름 = ?";
$stmt = $pdo->prepare($query);
$stmt->execute(배열($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.4로 업그레이드하는 것이 좋습니다. 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 주입 필터링 함수 라이브러리를 작성하려고 하지 마세요(번거롭고 알 수 없는 취약점이 쉽게 발생할 수 있습니다).

위 내용은 이 글의 전체 내용입니다. 매우 실용적입니다.