Де продукти залишають сліди
Види коду, які продукт залишає на сайтах своїх клієнтів, приблизно від
найнадійніших до найменш надійних. Добра сигнатура часто поєднує два-три з
них через |.
Адреса, з якої завантажується скрипт
Більшість продуктів установлюють тегом script, і скрипт надходить із власного хоста продукту - CDN або статичного піддомену. Це перше, що варто шукати.
Налаштування у вставленому фрагменті коду
Код, який вставляють клієнти, часто задає змінну або викликає функцію з назвою продукту. Вони є на сторінці навіть тоді, коли сам скрипт завантажується з іншого місця - зібраний разом із власними скриптами сайту або відданий через проксі.
Ідентифікатор облікового запису
Багато фрагментів коду містять ідентифікатор облікового запису клієнта в сталому форматі. Шукайте ту частину, яка ніколи не змінюється, а самі ідентифікатори витягуйте за допомогою snipexp:.
Ідентифікатор або клас елемента віджета
Віджет додає на сторінку власний елемент - контейнер з ідентифікатором або назвою класу продукту.
Тека плагіна чи модуля
У CMS продукт, установлений як плагін, лежить у теці зі своєю назвою, і ця тека трапляється в адресах його скриптів і таблиць стилів.
Посилання на власні сторінки продукту
Коли продукт розміщує для кожного клієнта портал, довідковий центр чи сторінку бронювання на своєму домені, сайт клієнта посилається туди - часто на власний піддомен клієнта на домені продукту.
Файли зі сховища продукту
Зображення й документи, які продукт зберігає для своїх клієнтів, завантажуються з адреси сховища продукту.
Тег generator
Конструктори сайтів і CMS часто називають себе в метатегу, іноді разом із версією.
HTTP-заголовки й cookie
Заголовки відповіді індексуються разом із кожною сторінкою, тож сервер, фреймворк чи хостинг-компанію, які встановлюють власний заголовок або cookie, теж можна знайти пошуком.
Як зрозуміти, чи слід справді належить клієнтам продукту, і як поєднати кілька слідів, описано в розділі Перевірка сигнатури.
Далі Перевірка сигнатури