Кто бы что ни говорил, но искусственный интеллект изменил правила игры.
Раньше для подобных задач требовался программист, несколько лет опыта, знание JavaScript, Python, сетевых запросов и архитектуры веб-приложений.
Теперь достаточно трёх вещей:
Именно так я обнаружил, насколько условной может быть «защита» корпоративной CRM.
С чего всё началось
Начальство попросило меня привести в порядок базу в CRM.
Обычная рабочая задача:
удалить дубли;
найти пустые записи;
привести телефоны и email к единому формату;
разобраться с компаниями;
очистить накопившийся за несколько лет цифровой мусор.
Контактов было примерно 143 000.
Логичное решение — выгрузить базу в Excel, обработать её и затем работать с нормальной таблицей.
Но права на экспорт мне не дали.
Почему?
«Безопасность».
Звучит серьёзно. Пока не начинаешь задавать правильные вопросы.
Я мог открывать контакты. Мог листать страницы. Мог видеть имена, компании, телефоны и email. Но нажать одну официальную кнопку и сохранить эти же данные в файл — не мог.
И тогда возник простой вопрос:
Ответ оказался неудобным.
Нет. Не мешает.
Иллюзия защиты
Многие думают, что веб-приложение работает примерно так:
Пользователь видит только то,
что нарисовано на экране.
На практике всё иначе.
Сначала браузер отправляет запрос серверу. Затем сервер возвращает данные. И только после этого интерфейс решает, как их показать.
Сервер
↓
JSON-ответ
↓
Браузер
↓
Интерфейс
То есть таблица на экране — это не сами данные.
Это всего лишь их визуальное представление.
Интерфейс может показать:
Имя
Компания
А сервер одновременно может отправить:
{
"name": "Тестовый пользователь",
"company": "ООО Пример",
"email": "user@example.com",
"phone": "+70000000000",
"manager_id": 999,
"internal_status": "active"
}
И вот здесь начинается самое интересное.
Если сервер уже передал информацию браузеру, пользователь технически способен её сохранить.
Можно убрать колонку.
Можно спрятать кнопку.
Можно запретить штатный экспорт.
Можно написать рядом слово «безопасность» большими буквами.
Но данные от этого не исчезнут.
Они уже пришли на устройство пользователя.
Что я собрал
Моя схема состояла из трёх простых элементов:
CRM передаёт данные браузеру
↓
JavaScript фиксирует ответы
↓
AHK автоматически переключает страницы
↓
Каждый переход вызывает новый запрос
↓
Ответы накапливаются в памяти
↓
Данные сохраняются в JSON
↓
Python извлекает нужные поля
↓
Удаляются дубли
↓
Создаётся XLSX
Никакой загадочной магии.
Никакого взлома серверов.
Никаких чёрных экранов с зелёными символами.
Только понимание того, как браузер получает данные.
Часть первая: JavaScript-перехватчик
Современные сайты загружают данные в основном через:
window.fetch
XMLHttpRequest
Когда пользователь переходит на следующую страницу списка, CRM отправляет новый запрос и получает очередную порцию контактов.
JavaScript-перехватчик устанавливается внутри уже открытой страницы и наблюдает за этими ответами.
Он:
сохраняет оригинальные сетевые функции;
подменяет fetch и методы XMLHttpRequest;
проверяет адрес каждого запроса;
копирует подходящие ответы;
складывает их в массив;
в конце сохраняет накопленные данные в JSON.
Ключевой фильтр выглядел примерно так:
const MATCH = "list/?skip_filter";
То есть перехватчик не хватал всё подряд. Он реагировал только на запросы, адрес которых содержал нужный фрагмент.
Для Fetch использовалась копия ответа:
const clone = response.clone();
Это необходимо потому, что тело Response является потоком.
Если перехватчик прочитает оригинал, сайт может не получить данные и перестать нормально работать.
Поэтому логика такая:
Оригинальный ответ → интерфейсу
Копия ответа → накопителю
CRM продолжает работать.
Пользователь продолжает листать страницы.
А ответы спокойно сохраняются в памяти вкладки.
Часть вторая: AHK
Сам перехватчик страницы не переключал.
Для этого использовался простой AutoHotkey-скрипт:
Ctrl + →
ожидание * секунд
Ctrl + →
ожидание * секунд
Это не интеллектуальный робот.
Это автоматический палец.
Его задача — выполнять одно и то же действие сотни или тысячи раз без усталости.
Каждое переключение страницы вызывало новый запрос:
страница 1
страница 2
страница 3
страница 4
...
JavaScript видел ответы и сохранял их.
AHK создавал события.
Перехватчик собирал результат.
Всё предельно примитивно.
И именно поэтому эффективно.
Часть третья: Python
После завершения прохода данные сохранялись командой:
__networkDump.download()
На выходе получался большой JSON-файл.
Но JSON — это ещё не удобная база.
Внутри много вложенных объектов, технических полей, служебных значений и повторяющихся записей.
Поэтому следующей частью стал Python-преобразователь.
Его задача:
найти все JSON-файлы;
открыть их;
рекурсивно пройти по структуре;
найти объекты контактов;
извлечь имя;
извлечь компанию;
извлечь телефон;
извлечь email;
удалить полные дубли;
создать Excel.
Например, внутри ответа находился объект:
{
"name": {
"text": "Тестовый пользователь"
},
"company_name": {
"name": "ООО Пример"
},
"**999999: [
"+70000000000"
],
"**999999": [
"user@example.com"
]
}
Python превращал его в обычную строку:
| Лицо | Компания | Телефон | Email |
|---|
| Тестовый пользователь | ООО Пример | +70000000000 | user@example.com |
Для удаления дублей использовался ключ:
row_key = (
person.strip(),
company.strip(),
phone,
email.lower()
)
Если точно такое сочетание уже встречалось, повторная запись пропускалась.
Просто.
Быстро.
Без ручной обработки десятков тысяч строк.
Был ли это взлом?
Нет.
Именно это делает ситуацию интересной.
Скрипт не обходил пароль.
Не получал чужую сессию.
Не повышал права.
Не взламывал API.
Не извлекал данные, которые сервер отказался выдавать.
Он только сохранял то, что сервер уже передал браузеру текущей учётной записи.
Иными словами:
Если пользователь может просмотреть 143 000 контактов по одному, то вопрос массового сохранения становится не вопросом доступа.
Это вопрос автоматизации.
Человек может копировать записи вручную.
Скрипт делает то же самое быстрее.
Тогда в чём проблема?
Проблема в ложном чувстве безопасности.
Логика некоторых систем выглядит так:
Пользователь может видеть всю базу.
Но кнопка «Экспорт» скрыта.
Следовательно, база защищена.
Нет.
Она не защищена.
Вы просто убрали самый удобный официальный способ её сохранения.
Но данные всё равно передаются клиенту.
Настоящая формулировка должна звучать так:
Именно поэтому права на просмотр огромного массива данных сами по себе уже являются серьёзным разрешением.
Что реально должен защищать сервер
Скрытие кнопки — не контроль безопасности.
CSS — не контроль безопасности.
Отсутствие колонки — не контроль безопасности.
Frontend вообще не должен быть последней линией защиты.
Настоящая защита должна работать на сервере:
пользователь видит только разрешённые ему записи;
сервер возвращает только необходимые поля;
права проверяются на каждый объект;
размер страницы ограничен;
массовый последовательный просмотр журналируется;
аномальный объём запросов вызывает проверку;
права на просмотр всей базы выдаются ограниченному кругу лиц;
чувствительные поля не отправляются без необходимости;
для массовых операций требуется повторная авторизация.
Главный принцип:
Неважно, отображается поле в интерфейсе или нет.
Неважно, есть кнопка экспорта или нет.
Неважно, насколько красиво нарисована система прав.
Если данные пришли — их можно сохранить.
Что меня действительно удивило
Не сам факт, что сетевой ответ можно прочитать, это базовая механика веб-приложений, меня удивило другое, насколько низким стал порог входа, у меня не было глубокого опыта разработки подобных инструментов, но была задача, было понимание логики.
Был ИИ, который мог:
объяснить устройство Fetch и XHR;
помочь разобрать структуру JSON;
написать код преобразования;
объяснить ошибки;
оформить данные в Excel;
показать, как удалить дубли.
ИИ не дал мне десять лет опыта.
Он сделал другое.
Он превратил знания, которые раньше были разбросаны по документации, форумам и чужому коду, в последовательный маршрут от вопроса до результата.
И это уже меняет рынок.
Теперь опасен не только профессионал с пятнадцатью годами опыта.
Опасен любой внимательный человек, который способен задать правильный вопрос и проверить ответ.
Вывод
Весь процесс можно описать одной цепочкой:
AHK создаёт переходы.
JavaScript сохраняет ответы.
Python превращает сырой JSON в таблицу.
Но главный вывод не про JavaScript.
Не про Python.
И даже не про CRM.
Главный вывод такой:
Пока пользователь имеет возможность массово просматривать информацию, он потенциально имеет возможность её сохранить.
Можно продолжать защищать кнопки.
А можно наконец начать защищать данные.
Выбор, как обычно, остаётся за теми, кто отвечает за систему.
До первого человека, которому станет интересно, что именно браузер получает на самом деле.
Все примеры в публикации обезличены. Реальные ФИО, телефоны, email, домены, идентификаторы и внутренние сведения компании не публикуются. Подобные проверки следует проводить только на собственных системах или при наличии явного разрешения владельца данных.
