Форум MySQL

нашёл 1 интересную статью по безопасности
и в конце там написано такое

Наиболее надежным способом предотвращения SQL-инъекций является использование параметризированных SQL-параметров. К примеру, в случае с PHP это возможно с помощью пакета PEAR’s DB, предлагающего интерфейс для выполнения абсолютно безопасных SQL-выражений. Обращение к БД происходит следующим образом: $p = $db->prepare("SELECT * FROM users WHERE id = ?"); $db->execute($p, array($_GET['id'])). Основная идея заключается в том, что если позиция параметров явно задана, то можно абсолютно безопасно передавать SQL-запросы базе данных, исключая возможность для параметров самим стать SQL-выражениями (в том числе зловредными). Стоит заметить, что другие механизмы, такие как использование принудительного приведения типов (например, с помощью функции intval()) в связке с экранированием строк такими функциями, как mysql_real_escape_string() или addslashes(), не являются абсолютно безопасными. Проблема в том, что существуют некоторые варианты для их обхода, а следовательно, к их использованию необходимо подходить с максимальным вниманием.

и вот теперь всего боюсь
и теперь стало интересно что такое пакет PEAR’s DB
и как это можно обойти принудительное приведение и mysql_real_escape_string()???
и не понятно что значит "позиция параметров явно задана"

ссылка на оную статью __http://www.xakep.ru/post/57950/__

Используйте PDO и подготовленные запросы, тоже самое, только без PEAR, который еще не на каждом хостинге есть. PDO сейчас есть практически везде, обеспечивает то же самое.

>и как это можно обойти принудительное приведение и mysql_real_escape_string()???
Он вам вообще не потребуется, так как проблема SQL-инъекции будет исключена как класс, строка будет вставляться в базу данных как есть, манипулировать запросом будет нельзя.

>и не понятно что значит "позиция параметров явно задана"
Это означает, что вместо подстроки у вас в запросе стоит знак вопроса, который потом будет заменен на нужную подстроку при помощи библиотеки.

Здравствуйте, cheops
правильно ли я понимаю, что речь ведется об "облегчающих жизнь" надстройках вроде jqvery в java scripte, или же действительно простой защиты вроде приведения типов недостаточно?

И в первом и во втором случае речь идет об интерфейсах, для использования подготовленных выражений MySQL, которые являются частью MySQL, а не PEAR и не PDO. Ими можно пользоваться и с помошью стандартного mysql_query();

PDO фактически стандартное расширение, расширение mysql уже устарел и не поддерживает ряд нововведений MySQL. В PHP дополнительная функциональность подключается при помощи расширений, в том числе доступ к базам данных. Когда расширение устаревает, оно заменяется новым. На смену mysql приходит mysqli и PDO. mysqli - это новый интерфейс (разработка MySQL), PDO - универсальный интерфейс для доступа к базам данных (разрабатывается сообществом). На что ориентироваться вам решать, но по моим ощущениям тренд в сторону PDO (в любом случае от mysql в новых проектах придется отказываться, если нет каких-то очень веских аргументов в пользу этой клиентской библиотеки, критичных именно для этого проекта).

что то я всё прочитал, но вопросы всё те же и остались
ничего не понял.

Можно попробовать разъяснить вопросы, дать на них развернутые ответы, но для этого их нужно озвучить. Попробуйте на основании прочитанного, сформулировать их еще раз. Что не понятно в первую очередь?

1. Непонятно что такое PEAR’s DB, для чего оно и вообще, где нибуть есть какое нибуть описание на русском. Аглицкий я читаю, но там слишком много технических терминов.

2. Как можно обойти принудительное приведение и mysql_real_escape_string()?

3. Что значит "позиция параметров явно задана". Это пожалуй самый главный вопрос. Я вообще не могу представить что это может значить. Даже приблизительно.

1. PEAR - это библиотека кода, написанная на PHP. Библиотека почти стандартна, т.е. каждый уважающий себя разработчик должен знать что это такое (использовать не обязательно, много корявых реализаций, по крайней мере было раньше). Толкового описания PEAR на русском языке я не встречал, собственно оно не появляется еще и потому, что PEAR не очень популярно, особенно в России. Как-то больше прижились FrameWork-и вроде ZendFramework или Symfony.
2. Кому? Обойти злоумышленнику или разработчику?
3. Это просто неудачная формулировка. Когда вы используете PDO, вы вместо параметров в SQL подставляете знаки вопроса, вместо которых потом подставляются параметры. Подставляются в порядке их перечисления, вместо первого знака вопроса подставляется первый параметр, вместо второго - второй параметр и т.д. Вместо знаков вопроса можно использоваться именнованные параметры

"SELECT * FROM tbl WHERE name = :name AND par = :todo"

Потом заполнять SQL-запрос при помощи массива вида array(":name" => $name, ":todo" => $todo). Т.е. тут позиция параметра задана явна, вы можете перемешать элементы в массиве как угодно, например пустить вначале :todo, а потом :name - они будут подставлены верно, так как "позиции параметров заданы явно" за счет использования именования параметров.

по первому и третьему понятно
по второму
разработчику или злоумышленнику - какая разница. Меня интересует не этическое а практическое решение
например:

$id = $_GET['id']; $id = (int)$id; if($id) {      $z = 'SELECT * FROM `table` WHERE  `id` = '.mysql_escape_string($id).'   '; }

как можно тут что-то подсунуть в запрос левое?

Тут никак, более того mysql_escape_string() тут избыточен, так как вы явно приводите $id к числу, следовательно, никаких кавычек в нем не будет, для mysql_escape_string() нет работы.

решил поставить посмотреть новую джумлу, обновил php
теперь функция mysql_escape_string() не работает, как оказалось и функция mysql_real_escape_string() тоже не работает, она тупо возвращает пустую строку.
Есть ли какая то функция полностью аналогичная mysql_escape_string()?

Хм... странно, а какая версия PHP используется? Вроде на эти функции пока никто не покушался...

php 5.4

Начиная с версии 4.3 функция mysql_escape_string() является устаревшей, а ее использование - крайне нежелательным http://www.php.net/manual/en/function.mysql-escape-string.php
Это же касается и второй функции. Хотя работать они должны. По крайней мере у меня на РНР версии 5.3.10-1ubuntu3.4 все работает.
Вместо них рекомендуется использовать расширения MySQLi или PDO_MySQL http://www.php.net/manual/en/function.mysql-real-escape-string.php