Статья Крепость из картона: обходим защиту от копирования на сайте

...или как админы-параноики защищали сайт, но забыли про curl и кнопку F12.

В 2026 году защита контента с помощью всплывающих окон в стиле рунета 2006 года вызывает легкую ностальгию и непреодолимое желание эту защиту обойти. Мы часто встречаем подобные задания в CTF, но будем честны: большинство тасков далеки от реальности, и это отталкивает специалистов, нацеленных на чистую практику. Но сработают ли классические хакерские трюки в реальных условиях? Спойлер:
Еще как.

Основная идея проста: если страница отдается браузеру целиком, с ней можно делать все что угодно. Но для обычного пользователя локальная "защита" контента от копирования может стать головной болью. На них в первую очередь и ориентирована эта статья - матерые хакеры вряд ли в ней найдут что-то полезное для себя.

Название сайта на скриншотах я закрасил от греха подальше - не из-за паранойи, а из уважения к правилам форума codeby.net и здравому смыслу. Все описанные техники универсальны и воспроизводятся на любом сайте с аналогичной защитой.

Погнали!

2.webp


Классическая ситуация: пытаешься посмотреть исходный код страницы через Ctrl+U или ПКМ, а в ответ вылетает грозное окно: "ALERT: You are not allowed to copy content or view source".

Ладно, думаю я, и нажимаю старый добрый Ctrl+P, чтобы слить страницу в PDF. И тут меня встречает вот это:

10.webp


Как оказалось, верстальщики не только заблокировали хоткеи, но и прописали стили, которые при попытке печати (даже через верхнее меню браузера) выводят ровно одну строчку с тем самым алертом.

Что ж, похоже, защита серьезная. Мой товарищ охарактеризовал ее как "абсолютную защиту контента от копирования". Давайте посмотрим, как эта "абсолютная" защита рассыпается от простейших манипуляций.

Способ 1. Встроенные инструменты разработчика (они же DevTools)

Разработчики сайта обычно вешают обработчики на горячие клавиши (F12, Ctrl+Shift+I, Ctrl+U) и на ПКМ (контекстное меню). Но они технически не способны запретить юзеру открыть панель через интерфейс самого браузера.

Кликаем на "бутерброд" настроек в правом верхнем углу (в моем случае это Firefox), идем по пути: More tools -> Web Developer Tools. И вуаля - вкладка Inspector послушно показывает нам весь исходный код. Текст статьи перед нами, копируйте сколько душе угодно, никаких алертов.

7.webp


Бонусный курьез

Как бы нелепо это ни звучало, но разработчики этой "абсолютной защиты" забыли повесить обработчик на клавишу F12. Одно нажатие - и мы снова в DevTools.

Способ 2. Отключение JavaScript

Пожалуй, самый популярный совет из интернетов. Логика проста: раз вся защита держится на честном слове клиентских скриптов, надо эти скрипты просто вырубить. Иногда этот трюк ломает верстку, и страница отказывается нормально загружаться, но наш подопытный сайт без JS чувствует себя прекрасно. Текст на месте, блокировки сняты.

В браузере Firefox (и его форках) правильнее всего отключать JavaScript через about:config, переключив параметр javascript.enabled в состояние false. Вот так:

8.webp


Способ 3. curl

Вариант для тех, кто не боится черных окошек терминала. Мне как линуксоиду этот путь ближе всего, поэтому его я применил первым делом. Запрос чистого HTML напрямую в консоли работает почти безотказно:

Bash:
curl https://example.com/protected-page/ > some_crap.html

(ссылку в примере я заменил, но суть, я уверен, вы поняли). На выходе получаем html-документ, готовый к парсингу.

11.webp


Способ 4. Кэш поисковиков и веб-архив (Wayback Machine)

Предположим, что все предыдущие методы не сработали (не представляю такую ситуацию, но допустим). Что ж, всегда можно постучаться в Wayback Machine или открыть сохраненную копию Google. Поисковым паукам все равно на скрипты запрета копирования, поэтому в их кэше лежит доступный текст.

А как же расширения?

Уверен, в комментариях обязательно спросят: "Зачем столько телодвижений, если можно поставить плагин для разблокировки в один клик?". Спору нет, это работает. Но как ИБ-специалист я считаю установку сторонних расширений в целом сомнительной затеей. Они часто превращаются в adware или молча сливают историю браузера - прецедентов было предостаточно. Поэтому я не могу рекомендовать такой метод. Так или иначе, ставить сомнительный софт ради обхода копеечной защиты - неоправданный риск.

На этом все. Надеюсь, кому-то будет интересен этот материал. Если статья понравилась - обязательно пишите об этом в комментариях. Должно быть, я один из немногих авторов, который пишет без использования ИИ, и мне интересна обратная связь.
 

Вложения

  • 4.webp
    4.webp
    18,2 КБ · Просмотры: 6
  • 8.webp
    8.webp
    19 КБ · Просмотры: 4
  • 9.webp
    9.webp
    83,7 КБ · Просмотры: 3
Последнее редактирование:
Если подобных страниц нужно много, я бы уже смотрел в сторону автоматизации - Python+Seleium или Playwright оба фреймворка могут и просто открывать ссылку в браузере, соответственно получать всё содержимое, а так же делать скрины всей страницы.
Кстати по поводу скринов - существует удобный инструмент ShareX, в нём есть возможность делать скрин с прокруткой: скрипт анализирует скриншот и пробует прокрутить страницу, если предыдущий скрин отличается, то картинка "дозаписывается"
Но это под windows)
 
  • Нравится
Реакции: Сергей Попов
Мы в соцсетях:

Взломай свой первый сервер и прокачай скилл — Начни игру на HackerLab

Похожие темы

🚀 Первый раз на Codeby?
Гайд для новичков: что делать в первые 15 минут, ключевые разделы, правила
Начать здесь →
🧭 Навигатор · ИБ 2026
Не знаешь, какой трек твой?
5 направлений ИБ, реальные зарплаты и точка входа для каждого — в одном треде.
JuniorSenior+
100K → 600K+ ₽ /мес
Открыть навигатор →
🔴 Свежие CVE, 0-day и инциденты
То, о чём ChatGPT ещё не знает — обсуждаем в реальном времени
Threat Intel →
💼 Вакансии и заказы в ИБ
Pentest, SOC, DevSecOps, bug bounty — работа и проекты от проверенных компаний
Карьера в ИБ →

HackerLab