Не нужно иметь в виду то, чего не существует. Атака — это внедрение.
Внедрить код INFORMATION_SCHEMA не помогает.
Остальное — софистика, которая путает причину со следствием.
Я не знаю, кто придумал этот вопрос, какого ответа он ждёт, и — главное — какие практические выводы собирается из него делать, но таких вопросов я ему могу насочинять миллион. В 5-й версии РНР была очень сильно повышена производительность. Значит, вирус, написанный на РНР, будет исполняться быстрее, и сможет заразить больше компьютеров. Получается, новая версия опаснее старой!
На самом деле, этот ответ не совсем верный. Акцент должен быть немного другой.
Всех всегда сбивает с толку двусмысленность понятия «abstraction» в DBAL:
— это может быть абстракция наружу, позволяющая одними и теми же методами работать с разными БД
— но в то же время мы можем абстрагироваться и внутри нашего приложения, от конкретного API, работая с унифицированными методами доступа к БД.
И вот в контексте этого вопроса нам совершенно неважно первое, но принципиально важно второе.
Являясь недообстракцией, PDO реализует тучу полезных и необходимых вещей, отсутствующих в mysqli из коробки
Таких как
— гарантированное получение в массив строки из БД без плясок с бубном
— биндинг по значению, а не по ссылке
— именованные плейсхолдеры
— методы для получения нужного результата
— функции-хелперы, такие как execute() сразу с данными
и многое другое.
Именно поэтому PDO является предпочтительным выбором, если сравнивать обращение к этим API напрямую из кода. А не потому что поддерживает много баз — ведь вопрос-то все равно про использование с mysql.
В качестве же базы для DBAL, предназначенного для работы с mysql, mysqli предпочтительнее, поскольку предоставляет гораздо более низкоуровневый доступ к API.
Там есть рекомендация использовать DBAL. Кем он будет написан — вопрос десятый.
При этом PDO частично является DBAL, а Mysql — вообще не является.
Отсюда делается очень простой вывод:
Если выбор между raw PDO и raw Mysqli — то PDO
Если планируется использовать враппер, то mysqli, как база для написания оного, будет предпочтительнее.
По поводу развития — PDO надо будет лет 10 ещё развиваться, чтобы достичь уровня поддержки mysql API, который сейчас реализован в mysqli.
Фреймворки в плане кода разбирать чуть менее, чем бесполезно.
Такие советы всегда дают только те, кто сам ни в одном приложении (с исходниками — на минуточку — в десятки мегабайт) не пытался разобраться сам.
При этом именно фреймворк — совершенно отдельное приложение, не являющееся сайтом, а предоставляющее инструментарий для создания сайта. То есть это всё равно что изучать устройство автомобиля, изучая станки, на которых он делается.
Если говориьт о фреймворках, то изучать надо идеологию и документацию. И это будет действительно полезно.
Хотел писать свой ответ, но потом увидел последний абзац и решил просто плюсануть. Не вижу никаких реальных проблем с «играми». Если доступ к записи открыт, то какая разница, как на нее зашёл пользователь — по прямой ссылке или перебором? Если закрыт, то обеспечивать эту закрытость надо чем угодно, но только не «случайными числовыми индексами».
stdit странный вопрос.
во-первых, он это открытым текстом сразу сказал — «серверные prepared statements… не планирую использовать». Т.е. запрос целиком готовится на клиенте.
Во-вторых, ваш же собственный PDO работает точно так же, судя по приведённым логам.
Во-первых, автор, судя по его словам, использует PDO в режиме совместимости, то есть, запрос уходит на сервер с уже постановленными значениями.
Во-вторых, в реальности компилировать всё равно придётся, поскольку чтобы выполнить новый запрос, новый инстанс РНР снова выполнит prepare.
Ж:-О
Мда, вот так читаешь себе хабр, не ждешь подвоха, и вдруг — «на боевом сервере отладку в браузер. патамушта привык».
А потом все удивляются, откуда у похапешников такая репутация.
И версия РНР в таком случае — это самая мелкая из проблем, с которыми придется столкнуться.