PDO 주입 방지 원리 분석 및 PDO 사용 시 주의사항

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

왜 사용합니까? 대신 PDO mysql_connect가 아닌가요?

왜 PDO가 주입을 방지할 수 있나요?

PDO를 사용할 때 Injection을 예방하기 위해 특별히 주의해야 할 점은 무엇인가요?

1. PDO를 우선적으로 사용해야 하는 이유는 무엇인가요?

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

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

Prepared 문에 대한 매개변수를 인용할 필요가 없으면 드라이버가 이를 자동으로 처리합니다. 애플리케이션은 준비된 명령문만 사용하므로 개발자는 SQL 삽입이 발생하지 않는다고 확신할 수 있습니다(단, 쿼리의 다른 부분이 이스케이프되지 않은 입력으로 작성되는 경우 SQL 주입은 여전히 ​​가능합니다.

PDO의 준비 메소드를 사용하더라도 주요 목적은동일한 SQL 템플릿 쿼리의 성능을 향상시키는 것입니다. SQL 인젝션 방지

동시에 PHP 5.3 이전 버전의 PHP 매뉴얼

Prior to PHP 5.3.6, this element was silently ignored. The same behaviour can be partly replicated with the PDO::MYSQL_ATTR_INIT_COMMAND driver option, as the following example shows.

Warning

The method in the below example can only be used with character sets that share the same lower 7 bit representation as ASCII, such as ISO-8859-1 and UTF-8. Users using character sets that have different representations (such as UTF-16 or Big5) must use the charset option provided in PHP 5.3.6 and later versions.

에 경고 메시지가 나와 있습니다. 6에서는 이 요소가 자동으로 무시되었습니다. PDO::MYSQL_ATTR_INIT_COMMAND 드라이버를 사용하여 부분적으로 복제할 수 있습니다. 경고아래 예의 방법은 ASCII와 동일한 하위 7비트 표현을 공유하는 문자 집합에만 사용할 수 있습니다. ISO-8859-1 및 UTF-8. 다른 표현(예: UTF-16 또는 Big5)이 있는 문자 집합을 사용하는 사용자는 반드시 사용해야 합니다. 문자 집합 옵션은 PHP 5.3.6 이상 버전에서 제공됩니다.

은 PHP 5.3.6 및 이전 버전에서는 DSN의 문자 집합 정의가 지원되지 않지만 사용해야 함을 의미합니다. PDO::MYSQL_ATTR_INIT_COMMAND设置初始SQL, 即我们常用的 set names gbk指令。

일부 프로그램을 보았지만 여전히 추가 래시를 사용하려고 합니다. 주입을 방지하기 위한 목적으로 이것이 실제로 더 많은 문제가 있다는 것을 모두가 알고 있습니다. 자세한 내용은 http://www.lorui.com/addslashes-mysql_escape_string-mysql_real_eascape_string.html

을 참조하세요. 또한 몇 가지 방법이 있습니다. 데이터베이스 쿼리를 실행하고 SQL에서 select, Union, ....과 같은 키워드를 정리합니다. 이러한 접근 방식은 제출된 텍스트에 학생 연합이 포함되어 있는 경우 대체 후 원본 내용이 변조되는 무차별적이고 바람직하지 않은 처리 방법임은 분명합니다.

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

$pdo = new PDO(" mysql: 호스트=192.168.0.1;dbname=test;charset=utf8","root");

$st = $pdo->prepare("select * from info where id = ? 및 이름 = ?");

$id = 21;

$name = 'zhangsan ';

$st->bindParam(1,$id);

$st-> binParam( 2,$name);

$st->execute();

$st->fetchAll();

?>

환경은 다음과 같습니다.

PHP 5.4.7

Mysql 프로토콜 버전 10

MySQL Server 5.5.27

php와 mysql 서버 간의 통신에 대한 자세한 내용은 Wireshak을 사용하여 연구용 패킷을 캡처한 후 아래와 같이 필터 조건을 tcp.port==3306으로 설정했습니다.

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

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

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

사실 이는 문자열을 이스케이프 처리하기 위해 일반적으로 mysql_real_escape_string을 사용하는 방식과 다릅니다. 그런 다음 SQL 문으로 연결하는 데에는 차이가 없습니다.(PDO 로컬 드라이버에 의해 이스케이프됩니다.) 분명히 이 경우에도 SQL 주입이 가능합니다. 즉, pdo prepare의 mysql_real_escape_string이 PHP에서 로컬로 호출되어 로컬 단일 바이트 문자 집합을 사용하여 쿼리하고 멀티 바이트 인코딩된 변수를 전달할 때 여전히 SQL 주입 취약점이 발생할 수 있습니다(PDO를 사용할 때 이유를 설명하는 PHP 5.3.6 이전 버전의 문제 중 하나). 권장 사항 php 5.3.6+으로 업그레이드하고 DSN 문자열에 문자 세트를 지정하는 이유

php 5.3.6 이전 버전의 경우 다음 코드는 여전히 SQL 주입 문제를 일으킬 수 있습니다.

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

$var = chr(0xbf) ". OR 1=1 /*";

$query = "SELECT * FROM 정보 WHERE 이름 = ?";

$stmt = $ pdo->prepare($query);

$stmt->execute(array($var))

이유 동일합니다.

올바른 이스케이프는 mysql 서버에 대한 문자 집합을 지정하고 변수를 MySQL 서버로 보내 문자 이스케이프를 완료하는 것입니다. >그렇다면 PHP 로컬 이스케이프를 비활성화하고 MySQL 서버가 이를 이스케이프하도록 하는 방법은 무엇입니까?

PDO에는

PDO::ATTR_EMULATE_PREPARES , 로컬에서 준비를 시뮬레이션하기 위해 PHP를 사용할지 여부를 나타냅니다. 그리고 방금 캡처한 패킷 캡처 분석 결과에 따르면 PHP 5.3.6+는 기본적으로 로컬 변수를 사용합니다. SQL을 실행하고 MySQL 서버로 전송한 후 이 값을 false로 설정하고 다음 코드와 같은 효과를 시도해 봅니다. $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에서 수행됨). PHP 5.3.6 이상 버전에서는 이미 이 문제를 처리했습니다. 로컬 시뮬레이션 사용 여부 mysql 서버 준비 또는 호출 준비. DSN에 문자 세트를 지정하는 것은 유효하지 않으며 세트 이름 의 실행이 필수적입니다.

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

그런데, DSN에 charset이 지정된 경우에도 세트 이름 을 실행해야 합니까?

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

A. 프로그램) 제출된 인코딩은 무엇입니까

B. mysql 서버에 클라이언트가 요구하는 결과의 인코딩이 무엇인지 알려주세요

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

그렇다면 DSN에서 문자 세트를 지정하는 역할은 무엇입니까? 이는 단지 로컬 드라이버가 이스케이프할 때 지정된 문자 세트를 사용한다고 PDO에 알려줄 뿐입니다. mysql 서버 통신 문자 집합), MySQL 서버 통신 문자 집합을 설정하려면 set names 명령도 사용해야 합니다.

사진이 누락된 경우 zhangxugg@163.com으로 이메일을 보내 PDF 버전을 요청할 수 있습니다.

왜 일부 새 프로젝트에서는 PDO를 사용하지 않고 기존 mysql_XXX 함수 라이브러리를 사용하는지 알 수 없나요? PDO를 올바르게 사용한다면 SQL 인젝션은 근본적으로 제거될 수 있습니다. 각 기업의 기술 리더와 일선 기술 R&D 인력은 이 문제에 주의를 기울이고 프로젝트 진행 속도와 안전 품질을 높이기 위해 PDO를 최대한 활용하는 것이 좋습니다. .

직접 SQL 주입 필터링 함수 라이브러리를 작성하려고 하지 마세요(번거롭고 알 수 없는 취약점이 쉽게 발생할 수 있습니다).

위 내용을 포함하여 PDO의 Anti-Injection 원리에 대한 분석과 PDO 사용 시 주의사항을 소개하고 있으니 PHP 튜토리얼에 관심이 있는 친구들에게 도움이 되었으면 좋겠습니다.