Очевидный метод «взлома» таких способов «защиты» – использование нестандартного браузера, игнорирующего указание «не кэшировать страницы».

Нужно иметь в виду, что если единственная задача взломщика – получить на диске точную копию HTML-страницы или подключаемого JavaScript-файла, то «браузер», решающий такую задачу, пишется за 10 минут на любом языке типа Perl или Java. Все, что нужно – отправить на сервер стандартный запрос по HTTP-протоколу (например, такой же, какой выдает Internet Explorer), получить соответствующий ответ и сохранить его на диске. В большинстве современных языков программирования такая задача решается тривиально.

Существует и общее решение, позволяющее справиться с любым видом «блокировки кэширования». Это proxy-сервер, устанавливаемый на клиентский компьютер и «пропускающий через себя» без модификаций все HTTP-запросы. Такой proxy может быть совершенно «невидимым» и для клиента, и для сервера. «По пути» proxy-сервер может сохранять на диске все проходящие через него HTML- и JavaScript-файлы. Скажу больше: proxy-сервер с такими возможностями, скорее всего, уже давно существует, например, среди бесплатных утилит ускорения доступа в Интернет.

Нестандартная обработка запросов к файлам

Однажды я столкнулся с любопытной схемой защиты, основанной на нестандартной реакции веб-сервера на самый обыкновенный (с виду) файл. К HTML-странице был подключен сложный JavaScript-файл с традиционным расширением .js. Но это был не обычный текстовый файл, а PHP-скрипт, возвращающий браузеру JavaScript-код. Веб-сервер был настроен таким образом, что конкретно этот файл с расширением .js обрабатывался интерпретатором PHP.

PHP-скрипт полностью анализировал заголовок HTTP-запроса, посылаемый браузером серверу. Каждый такой заголовок среди прочего содержит поле «Referer»: URL документа, инициировавшего данный запрос (если таковой имеется). Для Java-скриптов, подключаемых тегом:

<script language="JavaScript" src="..."></script>

Поле «Referer» в заголовке запроса всегда содержит адрес HTML-страницы, внутри которой находится указанный тег. Если же попытаться прочитать тот же Java-скрипт, просто набрав его URL в адресной строке браузера, то поле «Referer» будет отсутствовать.

PHP-скрипт, «притворявшийся» обычным .js-файлом, проверял, действительно ли «Referer» соответствует адресу страницы, к которой этот JavaScript должен быть подключен, или одной из таких страниц. Если это условие соблюдалось, то PHP возвращал корректный работоспособный JavaScript. В противном случае возвращался другой JavaScript – тоже сложный, но совершенно бесполезный.