Что делать, если .htaccess не обрабатывает знак вопроса.

запостил: 21 Июня 2011 г.

Багоискатели не дремлют

Помнится, как-то (а было это практически ровно два года назад) я расписывал, каким образом можно защититься от SQL-инъекции при помощи файла .htaccess. И признаюсь Вам честно, уважаемый читатель, уже тогда у меня в голове засела мысль о том, что где-то там есть какая-то лазейка. В принципе, я даже догадывался, как она выглядит и каким же образом можно обойти эту .htaccess защиту. Именно поэтому я в очередной раз повторю: не надейтесь только на одну защиту, обороняйтесь всегда комплексно. Никогда не думайте, что какой-либо параметр "не пройдет". Любую защиту можно обойти.

Если Вы уже прочли пост по вышеприведенной ссылке - просто замечательно. Тогда я не буду повторяться, а сразу приступлю к разбору ошибки.

.htaccess - не панацея.

Итак, в файле .htaccess имеем такого рода правила:

RewriteRule ^(news+)/{0,1}$ news.php?module=$1
RewriteRule ^(news+)/(a-z]+)/([0-9]+)/{0,1}$ news.php?&module=$1&view=$2&id=$3

Согласен, взломщику доступ к названиям GET-параметров запрещен, и тем не менее, подобрать кое-что вручную будет не особенно сложно. Вот, например, ссылка, созданная по такому шаблону:

http://domain.com/news/post/768/

Название последнего параметра так и напрашивается - id, здесь даже анализ сайта онлайн не требуется (хотя вообще-то штука весьма полезная). Обратите внимание на содержимое .htaccess файла, именно так сей параметр и называется. Можно, конечно, начать путать код, придумывать сверхоригинальные имена для GET-параметров, но лучше этого не делать. Вы сами же запутаетесь в них при создании третьей-четвертой страницы сайта. Я уж не говорю о том, насколько "приятно" будет переносить код, написанный под такие "секретные" имена. Имена переменных должны быть прежде всего понятны.

Впрочем, я отвлекся. Каким же образом можно передать нужные параметры? А вот таким:

http://domain.com/news/?view=post&id=768

а то и вовсе:

http://domain.com/?module=news&view=post&id=768

Обидно, правда? Все старания по указанию типов данных, входящих в URL, а то и вовсе конкретных перечислимых значений летят в анналы истории. Потому лично я (повторяюсь, наверное :)) придерживаюсь правила "лишних проверок не бывает". Мало ли, вдруг я захочу в дальнейшем тот код перенести на сайт, который не будет защищаться файлом .htaccess (да, как мы видим, и этот не особо-то защищен, если взломщику известны имена GET-переменных). Но что же делать, если перелопачивать весь код в данный момент просто нет времени.

"Знак вопроса" и .htaccess

Решение назревает простое и понятное. Нужно добавить в .htaccess правило, которое будет проверять URL на наличие символа "?" и если таковой вредитель присутствует, значит, чьи-то шаловливые ручки пытаются нам внедрить что-то свое.

Все бы ничего, да есть одна маленькая проблема. При обработке правил, записанных в .htaccess, Apache работает только с тем, что имеется ДО знака вопроса. Сам символ "?" и все, что находится после него, обработчик просто-напросто не видит. Да, я тоже не знал этого и часа полтора пытался понять, почему же шаблон ^(.*\?.*)$ у меня отказывается работать.

Знак вопроса в адресе страницы? Редирект на главную!

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

А значит, решение готово. В этом конфигурационном файле пишем:

<?php
$current_url = $_SERVER['SERVER_NAME'].$_SERVER['REQUEST_URI'];
if (strpos($current_url, '?') > 0)
{
	$current_url = SITE_URL.'/';
	header('Location: '.$current_url);
}
?>

То есть банально, берем адресную строку, ищем в ней символ "?" и если таковой находится, делаем редирект на главную страницу (констата SITE_URL и содержит URL домена).

Все. Какое-то время можно спать спокойно. Впрочем, багоискатели по-прежнему не дремлют. ;)

Внимание! При копировании данного материала обязательна прямая текстовая ссылка на эту страницу.

<< вернуться