Самый наивный прием – борьба с мышкой

Очень многие авторы «систем защиты» в первую очередь начинают рассуждать следующим образом.

Чтобы увидеть исходный текст страницы, посетитель должен выбрать в браузере команду «View Source». Самый типичный способ это сделать – «всплывающее» меню, доступное по правой кнопке мышки. Пишем на JavaScript обработчик нажатия правой кнопки мышки, который вместо визуализации локального меню высвечивает какое-нибудь ругательство. Есть еще команда «View/Source» в основном меню браузера. Кладем главную страницу внутрь фрейма: тогда Internet Explorer покажет по этой команде тривиальный FRAMESET. А если умный пользователь увидит внутри FRAMESET адрес страницы с фреймом и откроет ее непосредственно? И с этим можно справиться – достаточно проверить в JavaScript, что мы находимся внутри нужного фрейма, и если это не так, то сразу уйти на страницу с «ругательствами».

Одна из самых очевидных ошибок таких авторов – они забывают про кэш браузера. Обычно проще всего получить все исходные тексты, «спрятанные» таким образом, очистив кэш в Internet Explorer и затем зайдя на «защищенную» веб-страницу. После этого достаточно заглянуть в папку «Temporary Internet Files» и обнаружить там все «спрятанные» HTML- и JavaScript-файлы.

С кэшированием, правда, можно бороться.

Борьба с кэшированием

Более «подкованные» разработчики защитных механизмов могут вспомнить про кэширование страниц и попытаться его отключить. В принципе это не так уж сложно. Для запрета кэширования существуют специальные элементы в заголовке HTTP-ответа:

  Pragma: no-cache

  Cache-Control: no-cache

(имеет смысл указать оба элемента). Заголовок HTTP-ответа достаточно легко настраивается в любом сервере. Для тех, кто не имеет доступа к нужным настройкам своего сервера, существуют эквивалентные META-теги в самом HTML:

<meta http-equiv="Pragma" content="no-cache">

<meta http-equiv="Cache-Control" content="no-cache">