Mikhail Tarasov

Почему твой любимый сайт небезопасен (и как это проверить самому)

Mikhail Tarasov·26 Dec 2025

Привет! Недавно мне написал друг: "Слушай, ты же в кибербезе, глянь мой любимый интернет-магазин - он безопасный?" Я зашёл, посмотрел и чуть не подавился травяным чаем. HTTP вместо HTTPS, SQL-инъекции в поиске, XSS прямо в комментариях. Я ему такой: "Бро, этот сайт защищён как картонная коробка от дождя".

Занимаюсь баг-хантингом уже несколько месяцев, нашёл уязвимости в куче российских сайтов -от онлайн-магазинов до банков. И знаешь, что я понял? 95% сайтов, которыми мы пользуемся каждый день, имеют проблемы с безопасностью. Не все критичные, но они есть.

Сегодня я покажу тебе, как самому проверить любой сайт на базовые косяки. Без Burp Suite, без программирования. Только браузер, глаза и немного здравого смысла. Поехали! 💻

Почему сайты небезопасны? (мой опыт)

За годы работы в кибербезопасности я вывел несколько закономерностей:

Разработчики думают о функционале, а не о безопасности

Я общался с десятками программистов. Их задача - сделать фичу, чтобы работала. "Безопасность потом добавим" - а потом не добавляют. Я находил SQL-инъекции в сайтах, которые работают по 5-7 лет. Просто никто не проверял.

Дедлайны убивают всё

"Надо запустить к Новому году!" - и запускают с дырами размером с ворота. Security audit? Дорого. Пентест? Некогда. Результат - сайт работает, но течёт как решето.

Устаревшие технологии везде

Я видел сайты на PHP 5.3 (2009 год!), забытые админки на /admin с паролем admin123, библиотеки с известными CVE. В 2025 году! Это наша печальная реальность.

Человеческий фактор

Разработчик оставил debug-режим на проде, забыл убрать тестовую страницу, захардкодил API-ключи в JavaScript. Я такое вижу каждую неделю, честное слово.

Понял картину? Теперь научу тебя проверять сайты самостоятельно. 💪

Базовые признаки небезопасного сайта

Начнём с того, что видно невооружённым глазом. Это красные флаги — увидел хоть один, будь настороже.

1. HTTP вместо HTTPS — главный грех

Первое, что я проверяю — адресная строка браузера.

Как я проверяю:

🔍 Открываю сайт
🔍 Смотрю на адресную строку
🔍 Должен быть замочек 🔒 и https://

Что это значит:

Если сайт на HTTP (без замочка):

  • Твой пароль летит открытым текстом по сети
  • Любой в кафе с Wireshark видит твои данные
  • Твой провайдер видит всё, что ты делаешь
  • MITM-атака делается за минуту

Где это критично:

❗ Интернет-магазины (данные карты!)
❗ Любые сайты с логином/паролем
❗ Формы с личными данными
❗ Банки и финансовые сервисы (хотя тут HTTP - это уже клиника)

Мой кейс:

Месяц назад проверял местный интернет-магазин электроники в Курске. Сайт полностью на HTTP! Форма оплаты — тоже HTTP! Я им написал в обратную связь. Ответили: "У нас всё работает нормально, жалоб не было". Я такой: "Ребят, вы отправляете данные карт незашифрованными!" Они: "Мы не храним данные карт, они идут сразу в банк". Я: "Но они идут через ОТКРЫТОЕ соединение!"

В итоге забил, но сам там ничего не покупаю. И тебе не советую на HTTP-сайтах что-либо вводить. 🚫

Лайфхак: Видишь HTTP в магазине - закрывай вкладку и ищи другой магазин. Это либо лохотрон, либо полная безответственность.

2. Подозрительные URL

Фишинг маскируется под легитимные сайты. Я сам чуть не повёлся пару раз.

Как я проверяю:

🔍 Внимательно читаю домен
🔍 vk.com ≠ vvk.com ≠ vk-security.ru
🔍 sberbank.ru ≠ sber-online.com ≠ sberbank-enter.ru

Трюки, которые я видел:

  • Замена символов: о (кириллица) вместо o (латиница) - глазом не отличишь
  • Дефисы: ya-ndex.ru вместо yandex.ru
  • Похожие домены: gosuslugi.com вместо gosuslugi.ru
  • Хитрые поддомены: vk.com.fake-site.ru (настоящий домен тут fake-site.ru!)

Реальная история:

Мне пришло SMS якобы от Сбера: "Подозрительная операция на 48,000₽. Подтвердите: sber-security-check.online/confirm". Я, как параноик, сразу заметил левый домен. Зашёл через VPN и виртуалку - идеальная копия сайта Сбера! Попросили ввести номер карты, CVV, код из СМС. Классический фишинг.

Я зарепортил домен, хостинг заблокировал через день. Но сколько людей успело повестись -тстрашно представить. 😰

3. Проблемы с сертификатом

Даже HTTPS может быть с косяками.

Как я проверяю:

🔍 Кликаю на замочек в адресной строке
🔍 Смотрю информацию о сертификате
🔍 Проверяю срок действия и кому выдан

Красные флаги:

🚩 Сертификат просрочен
🚩 Выдан другому домену
🚩 Самоподписанный (self-signed)
🚩 Браузер ругается и показывает предупреждение

Мой случай:

Зашёл на сайт местной IT-компании (ирония!). Хром выдал предупреждение: "Ваше подключение не защищено". Сертификат просрочен на 3 месяца! Я им написал. Ответ: "Спасибо, знаем, обновим на следующей неделе". Прошёл месяц — сертификат так и просрочен. Профессионализм, да. 🤦

Проверка своими руками (как я это делаю)

Теперь переходим к активным проверкам. Это первые шаги, которые я делаю, когда оцениваю сайт.

4. Смотрю HTTP-заголовки

Это как посмотреть на фундамент дома - сразу видно, крепкий он или нет.

Как я делаю:

🔍 Жму F12 (или правой кнопкой → "Исследовать")
🔍 Вкладка "Network" / "Сеть"
🔍 Обновляю страницу (F5)
🔍 Кликаю на первый запрос → "Headers" / "Заголовки"

На что я смотрю:

Ищу security headers:

✅ X-Frame-Options - защита от кликджекинга (должен быть!)
✅ X-Content-Type-Options: nosniff - защита от MIME-атак
✅ Strict-Transport-Security - принудительный HTTPS
✅ Content-Security-Policy - мощная защита от XSS

Нет ни одного? Я уже знаю, что сайт уязвим к базовым атакам.

Server header:

Вижу Server: Apache/2.2.15 или nginx/1.10.1? Это древние версии с кучей известных CVE. Нормальные админы их скрывают или обновляют.

Реальный пример:

Проверял сайт онлайн-школы программирования (не буду называть). Открыл Network - нет НИ ОДНОГО security header. Server: Apache/2.4.6 (это 2013 год, Карл!). Я подумал: "Учат программированию, а сами не могут настроить элементарную безопасность".

Написал им подробное письмо с рекомендациями. Молчали месяц, потом ответили: "Спасибо, передали техническим специалистам". Полгода прошло -ничего не изменилось. Проверял недавно - всё так же. 🤷

5. Проверяю формы на XSS

Формы - моя любимая точка входа. Тут чаще всего косячат.

Что я делаю:

🔍 Нахожу любую форму (поиск, комментарии, обратная связь)
🔍 Вставляю тестовый payload: <script>alert('TEST')</script>
;🔍 Отправля
ю🔍 Смотрю, что произойдёт

Важно: Это НЕ взлом! Это проверка безопасности. Я не краду данные, не ломаю функционал. Это как проверить, закрыта ли дверь - дёрнул ручку и понял.

Что может быть:

✅ Норм: Данные обработались, payload не выполнился (есть фильтрация)
⚠️ Так себе: Код показался как текст (санитизации нет, но есть экранирование)
🚨 Провал: Вылез алерт с "TEST" (уязвимость подтверждена!)

Мой кейс:

Проверял сайт местной администрации (область не скажу, чтоб не светить). Форма "Обращения граждан". Вставил <script>alert('XSS')</script> в поле "Текст обращения". Отправил.

Перешёл на страницу моего обращения (она доступна по прямой ссылке) — БАХ! Алерт выскочил! Это Stored XSS - я мог бы заxssить любого, кто откроет эту страницу. Даже админов, которые просматривают обращения.

Зарепортил через official channels. Пофиксили через 3 месяца. Награды не было (госструктура), но зато получил благодарственное письмо. Повесил на стену для прикола. 😄

6. Проверяю на SQL-инъекции

SQLi - это классика, которую до сих пор находят. Я нахожу регулярно.

Как я проверяю:

🔍 Нахожу параметр в URL: site.ru/catalog?id=5
🔍 Добавляю одинарную кавычку: site.ru/catalog?id=5'
🔍 Смотрю на ответ

Что ищу:

🚨 SQL ошибка в ответе: "MySQL Error", "Syntax error", "You have an error in your SQL syntax" - BINGO! Это SQLi!
⚠️ Страница сломалась: 500 ошибка, белый экран - возможно, уязвимость есть
✅ Всё ОК: 404 или игнорирование кавычки - защита работает

ВАЖНО: Я иду только до этого шага! Одна кавычка - это проверка. Если начать эксплуатировать (UNION SELECT, дампить базу) без разрешения - это уже статья 272 УК РФ. Не делай так!

7. Читаю исходный код страницы

Разработчики любят оставлять секреты в коде. Я их люблю находить.

Как я делаю:

🔍 Правая кнопка → "Просмотр кода страницы" (Ctrl+U)
🔍 Ctrl+F для поиска
🔍 Ищу ключевые слова:

  • api_key
  • token
  • password
  • secret
  • admin
  • TODO
  • DEBUG

Что я нахожу:

  • API-ключи прямо в JS-коде
  • Закомментированные админские функции
  • Внутренние URL и endpoints
  • Информацию о версиях ПО
  • Комментарии типа // TODO: добавить проверку авторизации

Легендарный случай:

Сайт доставки еды (федеральная сеть, название не скажу). Открыл исходник страницы. Поиск по "api". Нашёл:

var YANDEX_MAPS_KEY = "секретный-ключ-123";
var PAYMENT_GATEWAY_SECRET = "prod-secret-key";

Это был боевой API-ключ от Яндекс.Карт с привязанной банковской картой компании! Плюс секрет от платёжного шлюза! Я мог накрутить им запросы на миллионы, но я не мудак.

Срочно написал в службу безопасности с severity: CRITICAL. Они удалили ключи из кода за 2 часа. Получил приглашение на закрытую программу.

Разработчика, который это закоммитил, наверное, уволили. Но это не моя вина - я спас им задницу. 🔥

8. Проверяю robots.txt

Этот файл - как карта сокровищ для хакера.

Как я делаю:

🔍 Открываю site.ru/robots.txt
🔍 Ищу Disallow:
🔍 Пробую зайти на запрещённые пути

Что часто нахожу:

User-agent: *
Disallow: /admin/
Disallow: /backup/
Disallow: /test/
Disallow: /api/v2/

Это как вывеска: "Тут у нас админка, не смотрите сюда!" Конечно я смотрю! 😎

Инструменты для ленивых (но я их тоже использую)

Если лень руками проверять, есть автоматические сканеры. Я их использую для первичной оценки.

9. Онлайн-сканеры

Mozilla Observatory (observatory.mozilla.org):

Я проверяю там все свои проекты. Вводишь URL - получаешь оценку от A+ до F и список рекомендаций.

Мой личный сайт получил B+. Добавил пару headers - стал A. Доволен как слон.

SecurityHeaders.com:

Быстрая проверка только HTTP-заголовков. Использую постоянно.

SSL Labs (ssllabs.com/ssltest):

Проверяет качество HTTPS-соединения. Оценка от A+ до F.

Проверял сайт одного банка (не Сбер) - получил B. У банка! Их TLS-конфигурация поддерживает устаревшие протоколы. Написал им - тишина. Ну окей, ваши проблемы. 🤷

10. Расширения для браузера

Я использую каждый день:

Wappalyzer:
Показывает технологии сайта (CMS, фреймворки, библиотеки). Помогает понять, с чем имею дело.

Cookie-Editor:
Смотрю на cookies - есть ли HttpOnly, Secure, SameSite флаги. Часто их нет.

Retire.js:
Сканирует JS-библиотеки на известные уязвимости. Находит кучу устаревших jQuery, Bootstrap и т.д.

Что делать, если нашёл уязвимость?

Окей, ты проверил сайт и нашёл баг. Что дальше?

Если это сайт с Bug Bounty программой:

✅ Зарепорть через платформу (HackerOne, Standoff, прямую программу)
✅ Опиши подробно: шаги, скрины, impact
✅ Жди ответа и выплаты

Если Bug Bounty программы нет:

✅ Найди контакт security team (security@site.ru, abuse@site.ru)
✅ Отправь подробное описание
✅ Дай им время на фикс (30-90 дней)
✅ Не публикуй детали до исправления

Чего НЕ делать:

❌ Не эксплуатируй уязвимость дальше проверки
❌ Не трогай чужие данные
❌ Не шантажируй ("заплатите или опубликую")
❌ Не хвастайся публично до фикса

Я всегда действую по responsible disclosure. Это профессионально и легально.

Заключение (мои мысли)

Я проверил сотни сайтов за свою карьеру. От мелких интернет-магазинов до федеральных порталов. И знаешь что? Проблемы везде. Абсолютно везде.

Но это не значит, что нужно паниковать и бояться интернета. Это значит, что нужно быть бдительным:

✅ Проверяй HTTPS перед вводом данных
✅ Смотри на URL внимательно
✅ Используй менеджер паролей и 2FA
✅ Не доверяй сайту только потому, что он "известный"

Я научил тебя базовым проверкам. Это 20% знаний, которые дадут 80% защиты. Если хочешь углубиться - изучай OWASP Top 10, проходи лабы на PortSwigger Academy, читай bug bounty write-ups.

А если найдёшь свою первую уязвимость - напиши мне, расскажу, как правильно зарепортить. Буду рад помочь. 🤝

Береги себя и свои данные. Интернет - это джунгли, но с правильными знаниями ты в них не потеряешься. 🔥

9 views·1 share
9 views