mysql_real_escape_string() 및 mysql_escape_string()은 MySQL 애플리케이션 보안에 충분합니까?

MySQL 보안: mysql_real_escape_string() 및 mysql_escape_string()이 적절한가요?

애플리케이션 보안을 위한 mysql_real_escape_string() 및 mysql_escape_string()의 효능 논쟁을 불러일으켰습니다. 이러한 함수는 알려진 SQL 주입 벡터를 방지하지만 그 제한으로 인해 더욱 발전된 공격에 취약해질 수 있습니다.

SQL 주입 민감성

mysql_real_escape_string()을 사용하더라도 PHP 변수가 쿼리에 통합되는 시나리오에서는 여전히 SQL 주입에 취약합니다. 예를 들어 다음 코드를 고려해 보세요.

<code class="php">$sql = "SELECT number FROM PhoneNumbers " .
       "WHERE " . mysql_real_escape_string($field) . " = " . mysql_real_escape_string($value);</code>

정교한 해커는 다음 입력을 사용하여 이 쿼리를 이용할 수 있습니다.

<code class="php">$field = "1=1"
$value = "1"</code>

이는 의도한 논리를 우회하여 대신 (잠재적으로) 모든 레코드를 반환합니다.

LIKE 공격

mysql_real_escape_string()은 다음과 같은 LIKE 공격을 방지하는 데 효과적이지 않습니다.

<code class="php">$sql = "SELECT number FROM PhoneNumbers " .
       "WHERE " . mysql_real_escape_string($field) . " LIKE " . mysql_real_escape_string($value);</code>

A 악의적인 사용자는 $value를 %로 설정하여 모든 레코드를 검색할 수 있으며 잠재적으로 민감한 데이터가 노출될 수 있습니다.

문자 집합 악용

Internet Explorer는 2011년에도 여전히 문자 집합 악용에 취약합니다. 이 취약점은 SQL 주입과 유사하게 공격자에게 데이터베이스에 대한 제어권을 부여할 수 있습니다.

준비된 명령문: 사전 예방적 접근

mysql_real_escape_string() 및 mysql_escape_string()은 모두 취약합니다. 그것은 반응적 방어 메커니즘이다. 반면에 준비된 진술은 적극적인 솔루션을 제공합니다. 유효하고 프로그래밍된 SQL만 실행함으로써 준비된 문은 기본 데이터베이스의 취약점에 관계없이 예기치 않은 SQL 실행의 위험을 크게 줄입니다.

다음은 준비된 문을 사용하는 예입니다.

<code class="php">$statement = $pdo->prepare('SELECT url FROM GrabbedURLs ' .
                           'WHERE ' . $column . '=? ' .
                           'LIMIT ' . intval($limit));
$statement->execute(array($value));</code>

준비된 명령문은 mysql_real_escape_string()을 사용하는 것보다 안전하고 덜 장황합니다. 알려진 위협과 알려지지 않은 위협으로부터 보호하기 위해 데이터베이스 서버의 보호 조치에 의존합니다.

위 내용은 mysql_real_escape_string() 및 mysql_escape_string()은 MySQL 애플리케이션 보안에 충분합니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!