Во время обычного найма кандидата могут попросить открыть ссылку, установить тестовую сборку, клонировать репозиторий, подключиться к API или VPN, воспользоваться тестовым аккаунтом. Для QA такие действия особенно привычны: инженеры работают с приложениями, сертификатами, proxy, Docker, staging и различными credentials.

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

Атаки через технические интервью уже стали отдельным вектором. Например, в кампании Contagious Interview (термин ввели в 2023 году, так назвали серию атак, где злоумышленники притворяются работодателями или рекрутерами, проводят фальшивые технические интервью и убеждают разработчиков запустить вредоносный код под видом тестового задания) злоумышленники воспроизводят обычный процесс найма: общаются с кандидатами, проводят интервью и выдают задания, содержащие вредоносный код. Поэтому даже профессионально выглядящее собеседование само по себе не гарантирует безопасность.

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

Например:

• установить тестовую сборку на своё устройство - нормальная практика;
• выдать приложению нужные для теста разрешения - тоже нормально;
• выйти из своего Apple Account, войти в чужой системный аккаунт или установить неизвестный профиль - уже повод остановиться и уточнить, зачем это нужно.

То же касается VPN, сертификатов и proxy. Сами по себе они не опасны - важно, какие права они дают и что меняют на вашем устройстве.

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

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

Один из сценариев, который стал встречаться в историях QA-кандидатов, выглядит примерно одинаково.

Человек проходит обычное интервью.

Обсуждает:

• опыт;
• тест-дизайн;
• мобильное тестирование;
• зарплату;
• будущий проект.

После этого ему предлагают практическую часть: «Выйдите из своего Apple Account на личном устройстве и войдите в предоставленный нами тестовый аккаунт».

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

Но здесь важно различать: «аккаунт внутри тестируемого приложения» и «системный Apple Account самого устройства». Это совершенно разные уровни доступа.

Apple использует Apple Account в том числе для Find My и Activation Lock. При определённой конфигурации устройство оказывается связано с аккаунтом, контролируемым другой стороной.

Кандидат откликнулся на junior QA-вакансию (и да, чаще всего это Junior позиции).

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

После интервью кандидат получил тестовое задание.

Для его выполнения предложили выйти из собственного Apple Account на личном iPhone и авторизоваться в аккаунте, предоставленном «работодателем». Кандидат выполнил условия. Звонок сразу же прекратился. Далее стали с других аккаунтов поступать угрозы и требования перевести за ограниченный период времени деньги.

Не авторизуйте личное устройство в системном Apple/Google-аккаунте, предоставленном неизвестной стороной в рамках собеседования.

Такое тестовое выглядит вполне обычно: кандидату присылают GitHub/GitLab-репозиторий и просят развернуть приложение локально, найти баг или автоматизировать один сценарий. Но здесь важно помнить: запуск чужого проекта может означать выполнение чужого кода на вашей машине.

Например, команда npm install не только скачивает зависимости. npm поддерживает lifecycle scripts - специальные команды, которые могут автоматически выполняться во время установки:

• preinstall;
• install;
• postinstall;
• prepare.

Это штатный механизм Node.js. Но его можно использовать и во вредоносных целях.

Microsoft описывала реальные атаки через фальшивые технические интервью: кандидатов просили клонировать и запускать проекты. После запуска вредоносного кода злоумышленники могли получить доступ к данным, хранящимся на компьютере инженера, в том числе:

• cloud credentials;
• API-токенам;
• signing keys;
• данным password manager;
• криптографическим ключам;
• .env и другим файлам с секретами.

Поэтому риск здесь не в самом GitHub-репозитории и не в команде npm install как таковой. Риск возникает в момент, когда непроверенный код получает возможность выполняться на вашей системе.

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

Сам по себе репозиторий в качестве тестового задания - нормальная практика. Важнее то, как компания предлагает с ним работать.

Перед запуском незнакомого проекта стоит посмотреть его содержимое через GitHub/GitLab. В первую очередь - package.json, .vscode/, скрипты, Dockerfile, docker-compose.yml, Makefile, а для Python - requirements.txt, pyproject.toml, setup.py.

Обратить внимание стоит на:

• install scripts;
• exec, spawn, child_process;
• загрузку файлов через curl, wget или PowerShell;
• обфусцированный код;
• обращения к неизвестным доменам;
• чтение .env, домашнего каталога и credential stores.

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

Поэтому незнакомые проекты лучше запускать, например, в отдельной виртуальной машине или на отдельном компьютере, где нет рабочих токенов, SSH-ключей, VPN, менеджеров паролей и доступов к prod.

Особенно не стоит выполнять такие задания на рабочем ноутбуке текущего работодателя.

Docker тоже не делает код автоматически безопасным: например, контейнер с доступом к $HOME, ~/.ssh, docker.sock или запущенный с --privileged получает значительно больше возможностей.

То же относится к Workspace Trust в IDE: для незнакомого проекта разумно сначала использовать Restricted Mode и только потом разрешать выполнение tasks и другой workspace-конфигурации.

Во время интервью кандидату действительно могут понадобиться:

• приложение для видеосвязи;
• VPN;
• сертификат;
• proxy;
• configuration profile;
• тестовая сборка.

Сами по себе эти инструменты не означают мошенничество. Важны источник и предоставляемые права.

Например, просьба установить Teams с официального сайта - нормальна. Предложение скачать неизвестный InterviewClient.dmg, а после блокировки macOS выполнить команду в Terminal - уже совсем другая ситуация.

Особенно внимательно стоит относиться к командам вида: curl ... | bash

Фактически они предлагают скачать код из сети и сразу его выполнить.

Аналогично с сертификатами, VPN и профилями: перед установкой стоит понять, зачем они нужны, какие права получают и можно ли выполнить задание в эмуляторе, VM или на предоставленном устройстве.

AnyDesk, TeamViewer и другие remote desktop-инструменты сами по себе легитимны.

Но на этапе собеседования работодателю почти никогда не требуется полный доступ к личному компьютеру кандидата.

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

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

Мошенникам необязательно создавать вымышленного работодателя. Проще взять настоящую компанию, реальную вакансию, имя HR и сделать похожий Telegram-аккаунт.

Поэтому проверки: «Такая компания существует» - недостаточно.

Лучше проверять всю связку: компания → вакансия → рекрутер → канал связи.

Если есть сомнения, найдите официальный сайт самостоятельно и свяжитесь с компанией через контакт, который получили не от подозрительного собеседника.

Запрос паспорта или банковских реквизитов сам по себе не является признаком мошенничества: после оффера работодателю действительно нужны данные для оформления.

Важнее: кто, когда, зачем и каким способом их запрашивает.

Есть большая разница между: «Мы сделали оффер. Заполните данные в корпоративной HR-системе» и «До технического интервью отправьте фото паспорта и селфи с ним в Telegram».

Во втором случае сначала стоит уточнить юридическое лицо, цель обработки данных и почему документы понадобились именно на этом этапе.

Не каждое неудобное или странное тестовое - мошенничество. Большое неоплачиваемое задание, например, может быть просто плохим процессом найма.

Но есть действия, которые на обычном собеседовании практически невозможно обосновать.

Кандидата не должны просить:

• передавать личные пароли и 2FA-коды;
• входить на личном устройстве в чужой системный Apple Account;
• предоставлять полный remote access к своему компьютеру;
• переводить или принимать деньги;
• подключать настоящий криптокошелёк;
• отключать защиту ОС только потому, что «иначе тестовое не работает»;
• запускать неизвестный код с административными правами без понятного объяснения.

Дополнительный красный флаг - давление: «Все остальные сделали», «Это стандартная процедура», «Если не доверяете - вы нам не подходите».

Мошенническое интервью может выглядеть вполне профессионально: настоящая компания, нормальные вопросы по QA, адекватная зарплата и техническое задание.

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

Чем больше доступа требует задание, тем убедительнее должно быть объяснение, зачем он нужен.

Обсудить статью можно в канале «Тестировщики нужны» — в Telegram, MAX и Сетке. А также в канале QA Jobs.