Клик-ловушка: не только для пользователей, но и для анализаторов ссылок 🐭
При ручном разборе ссылок мы в PT ESC , как правило, задаем себе лишь один вопрос — «безопасна ли она?» ✔❌
Перенести подобный подход в потоковую среду для анализа нельзя: действия, инициируемые переходом по ссылке, могут привести к возникновению новых проблем. Так, приглашения из почтовых сообщений могут автоматически приниматься или отклоняться, производиться автоматическая отписка и/или подписка на корреспонденцию и так далее. В случае если подобное действие вызывает на сервисе отправку нового письма с подобными ссылками, то автоматический переход по ним вызовет непрекращающуюся «лавину» сообщений, что может привести к снижению производительности защитных решений или просто к раздражению пользователей.
🫵 Для решения этой проблемы можно предложить подход, логически схожий с процессом выбора ссылок при ручном анализе: какие-то ссылки нам кажутся крайне подозрительными или однозначно требующими дополнительного контекста для анализа, а какие-то — точно безопасными или, как в предыдущей ситуации, вызывающими определенные действия на сервисах (или вообще одноразовыми). Подход, где система определяет набор признаков «точно нужно переходить» и набор признаков «точно не нужно переходить», называется принятием решений на основе правил (rule-based decision system). Какие признаки можно предложить для реализации подобной системы?
В наборе условий, предотвращающих переход по ссылке, можно рассмотреть:
наличие паттернов в URL-пути, семантически указывающих на возможное действие при активации, например, /(un)subscribe/, /login/, /exit/, /action/, /track/ и т.д.;
наличие параметров запроса token, key, uid со значениями, по формату совпадающими с UUID или JWT;
наличие параметров запроса ts или expires, указывающих на время жизни ссылки;
если ссылка пришла из почтового сообщения, можно проверить ее наличие в отдельных заголовках подписки/отписки от корреспонденции — List-(Un)Subscribe:;
при наличии поставки потоков данных с набором «белых» доменов можно рассмотреть отключение анализа содержащих их URL-ссылок. С подобной опцией нужно быть осторожнее, поскольку даже самые популярные и известные сервисы и домены могут использоваться в сценариях с перенаправлением контента.
В наборе условий, вызывающих переход по ссылке, можно рассмотреть:
ссылки с явным указанием IP-адреса и/или нестандартного порта;
ссылки с недавно зарегистрированным доменом;
при наличии категоризатора web-ресурсов с подобной классификацией — ссылки на сервисы-shortener'ы. В случае отсутствия можно рассмотреть условие с короткой длиной URL-ссылки;
ссылки с указанием в URL-пути файлов с конкретными статическими расширениями, например, .pdf, .exe и т.д.;
ссылки на сервисы объектных хранилищ, например на S3- или IPFS-хранилища.
🧐 Что остается делать со ссылками из анализируемого объекта, которые не попали ни под один из перечней? Здесь можно опираться на реальную картину, которая получается после работы подобного алгоритма: если позволяет производительность системы или время анализа не превышает допустимый SLA на обработку объектов, можно отправлять все «серые» ссылки на получение контента. Либо же ввести ограничение на количество одновременно анализируемых ссылок у одного объекта.
Также для URL-ссылок, не прокатегоризированных системой принятия решений, можно предусмотреть «осторожный» алгоритм получения дополнительного контекста для анализа: переходить по ссылке методом HEAD без получения контента. Таким образом можно получить дополнительную информацию из HTTP-заголовков, применимую как внутри вышеописанного алгоритма, так и в целом для принятия решения о вредоносности ссылки.
Источник: https://t.me/ptescalator
