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

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

Этим зазором пользуются двумя способами, и оба закрываются одной проверкой.

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

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

Совет про токен в адресе страницы кочует из статьи в статью в одной и той же формулировке: не кладите его в URL, иначе он уедет в заголовке Referer на все сторонние ресурсы, которые подключает ваша страница.

Совет правильный по выводу и неправильный по обоснованию. Через Referer он давно никуда не уезжает. А вот сам токен из URL утекает — просто в других местах, и там его обычно никто не ищет.

Знакомая схема защиты от подмены. Сервер кладёт клиенту 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 действительно не украдут — с этим всё в порядке. А вот список сайтов, куда вы ходите, виден любому, кто сидит на том же канале — владельцу точки доступа, провайдеру, соседу с ноутбуком, если сеть открытая. Причём видно его в открытом виде, никакого взлома для этого не требуется.

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

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

Человек готовит договор для внешней стороны, закрашивает в нём чёрным прямоугольником номер счёта, сохраняет в PDF, отправляет. Прямоугольник на месте, ничего не видно, всё в порядке.

Номер счёта при этом уезжает вместе с файлом. Целиком, в открытом виде — его достаёт любой инструмент, умеющий вытаскивать текст, и даже обычное выделение мышью в просмотрщике.

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

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

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

Разберу, что именно остаётся, как это найти в основных сервисах и в каком порядке всё делать.