Я бы, всё-таки, настраивал не mod-rewrite, а само приложение.
Ему просто надо понять — валидный ли запрос — до того, как производить какие-либо действия.
Потому что, с одной стороны, запроск к картинкам или XML файлам, конечно можно простым правилом увести с индекса,
но с другой — во-первых, иногда их надо тоже обрабатывать динамически, а во-вторых, всякие '/phpmyadmin/', которыми скрипт-киддис бомбардируют все сайты подряд, под этот шаблон все равно не попадают, как и куча другого мусора.
Единственная проблема в том, что точка входа обрабатывает одинаково как валидные запросы, так и не валидные.
Откуда же приходит невалидный — дело десятое. На боевом сайте их будет приходить множество, так что лучше сразу проверять валидность.
Все известные мне случаи двойного срабатывания, даже такие экзотические, были вызваны повторным запросом на сервер. Самый верный вариант убедиться, кстати — логи доступа.
open_basedir не имеет отношения ни к include, ни к document_root
эта директива ничего не подменяет, в том числе поведение realpath.
она просто не дает открывать файлы, расположенные выше указанного каталога.
Рекомендую запустить этот код с такой командной строкой: /index.php?_SESSION[auth]=1
и посмотреть в массив $_SESSION.
Учитывая, что практически во всех нубокодах, использующих register_globals, функция session_start(), согласно распространённому суеверию, «должна вызываться в самой первой строке, до любых других операторов», то имеем невозбранную дыру размером с футбольное поле.
При родных register_globals хотя бы этого ужаса не будет, поскольку присвоение произойдёт до старта сессии, при котором массив $_SESSION обнулится.
Вы, наверное, не понимаете, что это бомба, которая сто крат хуже, чем родная register_globals
Если там мы ещё не успели ничего наприсваивать переменным, и надежда у хакера только на забывчивость, то здесь можно запросто переписать любую уже установленную до запуска этого кода переменную. Addslashes отдельно доставляют.
Подтверждается поговорка конца прошлого века — «хуже register_globals только то, как пользователи РНР борются с ней»
Вообще, даже вообразить не мог, что в 2013 году буду участвовать в такой дискуссии.
Не нужно иметь в виду то, чего не существует. Атака — это внедрение.
Внедрить код 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.
Фреймворки в плане кода разбирать чуть менее, чем бесполезно.
Такие советы всегда дают только те, кто сам ни в одном приложении (с исходниками — на минуточку — в десятки мегабайт) не пытался разобраться сам.
При этом именно фреймворк — совершенно отдельное приложение, не являющееся сайтом, а предоставляющее инструментарий для создания сайта. То есть это всё равно что изучать устройство автомобиля, изучая станки, на которых он делается.
Если говориьт о фреймворках, то изучать надо идеологию и документацию. И это будет действительно полезно.
- Папа, а правда, что Солнце восходит на востоке, а садится на западе? - Точно встаёт? Работает? Ничего не трогай!