Знакомая схема защиты от подмены. Сервер кладёт клиенту cookie user=guest&role=reader и рядом — подпись sha256(secret + данные), чтобы клиент не переписал reader на admin. Секрет знает только сервер, поэтому пересчитать подпись под изменённые данные клиент вроде бы не может.

Поломается не сама SHA-256, а конструкция вокруг неё: к данным можно дописать хвост &role=admin и предъявить к нему валидную подпись, не зная секрета вообще. Атака называется length extension, и в статье мы её проделаем на своём же сервере.

Ситуация из практики любой компании: сотрудник уволился, ноутбук сдал, пароль от гостевой и рабочей сети остался прежним. Формально сотрудник его не знает — вводил один раз при подключении, полгода назад, наизусть не помнит.

На самом деле пароль он унёс: если ноутбук уехал с ним, а иногда и просто потому, что пароль можно было посмотреть в системе одной командой в любой момент.

Разговор, который у меня повторяется примерно раз в квартал. Интеграция ходит к партнёрскому API, партнёр её режет. Разработчик ставит в запрос User-Agent от Chrome. Не помогает. Дальше идут версии про адрес, про частоту, про капчу — и все мимо.

Сервер понял, что это не браузер, ещё до того, как увидел хоть один HTTP-заголовок. User-Agent он в тот момент не читал, потому что читать было нечего: HTTP начинается после установления TLS, а решение принимается по первому же пакету рукопожатия.

За годы в SOC и на пентестах я привык к неприятному распределению: самый дорогой периметр обходится не через уязвимость в коде, а через того, кто за этим периметром сидит. Файрвол не устаёт, не хочет помочь и не боится начальства. Человек устаёт, хочет и боится.

Эта статья не про конкретные схемы «как разводят» — их пересказывают в каждой новости. Она про механику: что именно происходит с человеком в момент атаки, почему инструктаж почти не помогает и что работает вместо него.

Разбор, на который меня зовут регулярно, и заканчивается он почти всегда одинаково. База клиентов всплывает в продаже. Выгрузку за последний год получали десятки контрагентов — интеграторы, колл-центр, маркетинговое агентство, аудиторы. У всех был законный доступ. Файл у всех был один и тот же.

Дальше начинается разговор в жанре «это не мы», и закончить его нечем: копии побайтово одинаковые, доказать причастность нельзя ни к кому.

Чинится это не после инцидента, а до него — и стоит недорого. Каждый получатель должен получать копию, отличающуюся от остальных так, чтобы отличие не мешало работе и переживало пересохранение файла.

Характеристика, которую пишут в описании правила детектирования и произносят на защите архитектуры: обнаруживает 99% атак при доле ошибок в 1%. Звучит как хороший результат, и принимают её обычно без вопросов.

А вопрос тут есть, и он арифметический. При таких характеристиках почти каждое сработавшее правило окажется ложным — не потому, что правило плохое, а потому что атака редкая.

Заявка была скучная: клиент не проходит проверку по списку разрешённых адресов. Адрес его я вижу, адрес в списке есть, файрвол пакет пропускает. Приложение отвечает «доступ запрещён».

В логе стояло ::ffff:192.0.2.5, в конфиге — 192.0.2.5. Что строки разные, видно сразу. Но выглядит это как разное написание одного адреса: справа те же четыре октета, слева приписка, которую принимаешь за особенность формата. Поэтому проверять я пошёл конфиг, а не сравнение.

Строчка, которая встречается в скриптах повсеместно:

mysql -u admin -pSecretPass123 -e "select 1"

Пока команда выполняется, этот пароль видит каждый, у кого есть доступ к устройству — обычный, непривилегированный. Достаточно посмотреть список процессов.

Формулировка встречается в политиках конфиденциальности постоянно и звучит успокаивающе. На деле она означает одно из двух: либо в компании действительно шифруют пароли — и это плохо, — либо там не различают шифрование и хеширование, что тоже не добавляет уверенности.

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

Ситуация обычная: пришёл запрос на удаление персональных данных, разработчик выполнил DELETE FROM clients WHERE id = ..., отчитался. Формально всё правильно — строки в таблице нет, приложение её не видит, выгрузка не содержит.

А в файле базы она есть. Целиком, вместе с именем и номером карты, и достаётся обычным grep.

Обычная логика такая: не хочу, чтобы меня узнавали — открываю приватное окно, и всё, я новый посетитель. Логика была верной примерно до середины десятых годов.

Сейчас узнавание держится не на cookie, а на наборе свойств самого браузера. Их не надо никуда сохранять — они просто есть, и по их сочетанию посетитель определяется с высокой надёжностью. Очистка хранилища на это не влияет никак: удалять там нечего.

Регулярно слышу этот вопрос в разных формулировках. Индикатор сети мигает, когда ничего не открыто. Антивирус молчит, но кажется, что молчит зря. Или человек увидел в диспетчере задач незнакомое имя процесса и теперь не знает, что с этим делать.

Ответ на такой вопрос получается за десять минут стандартными средствами системы, без специальных программ и без переустановки. Показываю порядок действий и то, как отличать нормальное от ненормального — потому что вторая часть обычно оказывается сложнее первой.

Про публичный Wi-Fi принято говорить одно из двух. Либо «там воруют пароли, не подключайтесь», либо «сейчас везде HTTPS, всё в порядке». Обе формулировки неточные, и обе мешают понимать, что происходит на самом деле.

Пароли при работающем HTTPS действительно не украдут — с этим всё в порядке. А вот список сайтов, куда вы ходите, виден любому, кто сидит на том же канале — владельцу точки доступа, провайдеру, соседу с ноутбуком, если сеть открытая. Причём видно его в открытом виде, никакого взлома для этого не требуется.