현재 mysqli PHP 확장 기능을 사용하고 있습니다.mysqli prepared statements 및 mysqli_real_escape_string
전통적으로 저는 사용자 입력을 피하기 위해 mysqli_real_escape_string을 사용했습니다. 그러나 나는 준비된 문장을 사용하기 위해 코드를 가능한 한 적은 단계로 변경하려고한다.
내 변수를 모두 바인드하기 위해 준비된 문을 사용했다면 SQL 주입이 불가능하다고 확신 할 수 있습니까? (그리고 mysqli_real_escape_string 완전히 분배?)
감사
올바르게 모든 변수를 결합하면 극적으로 SQL 인젝션의 위험을 줄일 수 있습니다. 당신이 예를 들어, 동적 SQL을 만들 경우 SQL 주입을 얻을 여전히 가능 :
'SELECT * FROM ' . $tablename . ' WHERE id = ?'
을하지만,이 같은 일을 피할 경우는 문제가있을 것이다 않을 수 있습니다.
보안에 대해 말하면, 변수를 올바르게 바인딩하거나 서식을 지정하면 두 방법간에 차이가 없습니다.
바인딩은 모든 케이스에 사용할 수 있기 때문에 더 간단합니다. 이스케이프는 사용할 수 없으므로 (이스케이프/인용 대신 일부 변수를 캐스트해야합니다.) 바인딩은 훨씬 간단합니다.
또한 바인딩 또는 이스케이프 처리로 식별자를 안전하게 만들 수 없음을 유의하십시오. 따라서 쿼리에서 필드 이름이나 연산자를 사용해야하는 경우 스크립트에서 하드 코딩 된 값을 사용해야합니다.
다음은 주제에 대한 저의 견해입니다.
동적 SQL 문자열을 사용하는 경우 올바르게 작동하는 이스케이프 기능이 필요합니다. 데이터 값이 탈출하고 나면
http://dev.mysql.com/doc/refman/5.0/en/news-5-0-22.html
, SQL 문자열 구문 분석하고 데이터베이스에 의해 컴파일 될 수있다 :이 (틀림없이) 이전의 예에서 볼 수 있듯이 불행하게도,이 경우는 항상 아닙니다 섬기는 사람. 이스케이프 기능이 제대로 작동하지 않거나 영리한 새 SQL 주입 공격이 발견되면 서버에서 SQL 문에 대한 데이터를 실수로 범할 가능성이 있습니다.
매개 변수와 함께 prepared statement를 사용하면 명령문은 먼저 구문 분석되고 컴파일됩니다. 데이터 값은 실행될 때 컴파일 된 명령문과 결합됩니다. 이렇게하면 SQL 로직이 데이터 값과 분리되므로 두 개를 혼동하지 않아야합니다.이 발생하지 않아야합니다.
예, 그렇습니다. mysqli_real_escape_string을 없앨 수는 있지만, 매개 변수가있는 준비된 문을 사용하면 SQL 삽입이 불가능하다고 말할 수 있습니다. 버그 수정이 훨씬 더 어려워 지지만, mysqli_real_escape_string 버그와 마찬가지로 아직 발견되지 않은 (또는 새로 생성 된) 버그로 인해 불가능 해 보이는 가능성이 항상 존재한다고 생각합니다.
예, 자세한 내용은 http://www.sjmp.de/php/php-mysql-mehr-sicherheit-und-erhoehte-performance-durch-mysqli-und-prepared-statements/을 참조하십시오. – Tobias