Спуфинг (spoofing) — это подмена пользователя, отправителя сообщения или другого участника обмена данными, при которой нарушитель выдаёт себя за подлинную сторону. В финтехе такую подмену учитывают при защите входа, смены контактов и платёжных реквизитов.
Кратко: главное о спуфинге
- В первой редакции проекта ГОСТ об угрозах идентификации и аутентификации спуфинг обозначен кодом ИА-7: «Выдача себя за другого».
- Для входа от чужого имени нарушитель может использовать похищенный пароль, аутентификатор или копию биометрического признака.
- Команда безопасности проверяет смену телефона и платёжных реквизитов отдельно от факта успешного входа.
- При проверке живости программа анализирует признаки присутствия живого человека; сходство лица с эталоном проверяют отдельно.
- Проверка использования телефонного номера физлицом оценивает связь физического лица с номером по шкале от 0 до 5. Результат не удостоверяет личность собеседника во входящем звонке.
Разбираем ИА-7 и связанные уязвимости по ГОСТу Р 70262.3-2026, утверждённому приказом Росстандарта от 14 сентября 2026 года № 1136-ст. Стандарт вступит в действие 1 декабря 2026 года.
Что такое спуфинг ИА-7 в проекте ГОСТа
Чтобы пройти аутентификацию от чужого имени, нарушитель может предъявить чужой пароль, похищенный аутентификатор или копию биометрического признака.
В таблице Б.2 проекта перечислены типовые угрозы вторичной идентификации и аутентификации. Строка ИА-7 называется «Спуфинг», её краткое описание: «Выдача себя за другого». Авторы проекта описывают способ реализации угрозы так:
«Нарушитель имитирует другую сущность, чтобы получить возможность осуществления действий, которые иначе он не мог бы осуществить. При этом нарушитель использует подлинную аутентификационную информацию легального зарегистрированного субъекта доступа, либо иным образом притворяется легальной сущностью».
Авторы проекта выделяют доказывающую, проверяющую и доверяющую стороны. Доказывающая сторона предъявляет сведения, чтобы подтвердить, за кого себя выдаёт. Проверяющая сторона проверяет эти сведения, а доверяющая использует результат. При анализе подмены специалисту нужно установить, кого имитирует нарушитель и почему остальные участники принимают его за подлинную сторону. Поэтому проверка только событий входа недостаточна.
Карточка угрозы
|
Параметр |
Содержание строки ИА-7 в проекте |
|---|---|
|
Название |
Спуфинг |
|
Краткое описание |
Выдача себя за другого |
|
Объект воздействия |
Доказывающая, проверяющая и/или доверяющая сторона |
|
Используемые уязвимости |
АФЗ-2, АФВ, АФБ |
|
Подверженная информация |
Аутентификационная информация, используемая при простой и усиленной аутентификации |
|
Нарушаемое свойство |
Конфиденциальность |
|
Последствие, краткий пересказ |
Несанкционированный доступ с использованием перехваченных сообщений протокола аутентификации или подлинной аутентификационной информации зарегистрированного субъекта |
В таблице мы пересказываем строку ИА-7 из проекта. Получив доступ, нарушитель может, например, изменить платёжные реквизиты в аккаунте. Специалисты, которые расследуют инцидент, анализируют такие действия отдельно.
Специалисты по безопасности описывают возможную подмену и выбирают меры защиты ещё до атаки. Если инцидент уже произошёл, они сопоставляют события аутентификации, сведения о сеансах, результаты проверок и другие доступные материалы. По одной записи об успешном входе нельзя установить, кто использовал пароль.
Какие уязвимости связаны со спуфингом
В таблице А.2 проекта перечислены уязвимости факторов аутентификации. С угрозой ИА-7 связаны АФЗ-2, АФВ и АФБ.
|
Код |
Название в проекте |
Значение для защиты |
|---|---|---|
|
АФЗ-2 |
«Невозможность однозначного установления факта хищения секрета» |
Нарушитель может пользоваться похищенным паролем, пока специалисты не обнаружили компрометацию и пароль остаётся действующим |
|
АФВ |
«Низкая стойкость предмета (устройства) к хищению или повреждению» |
Авторы проекта относят к этой уязвимости потерю, повреждение и хищение устройства, а также клонирование информации в нём |
|
АФБ |
«Низкая стойкость биометрической характеристики к копированию (дублированию)» |
Нарушитель может получить или создать копию признака и попытаться применить её при проверке |
При уязвимости АФЗ-2 специалистам трудно однозначно установить, что секрет похищен. Например, при фишинге нарушитель сначала получает пароль, затем использует его для входа. Команде безопасности нужно предотвращать раскрытие пароля, выявлять входы с похищенными данными и прекращать доступ после обнаружения компрометации.
По техническому профилю устройства специалист может определить, насколько обращение отличается от обычных действий клиента. Однако этих данных недостаточно, чтобы подтвердить владение аутентификатором. При проверке живости сервис анализирует признаки присутствия живого человека. Защиту пароля и контроль устройства команда безопасности организует отдельно.
Какие виды спуфинга встречаются
Нарушитель может подменить данные пользователя, отправителя письма, номер звонящего или сетевой адрес. Специалист относит такую подмену к ИА-7 с учётом того, как участники используют эти данные при идентификации и аутентификации.
|
Сценарий |
Что происходит |
Что устанавливают специалисты при расследовании |
|---|---|---|
|
Выдача себя за владельца аккаунта |
Нарушитель предъявляет чужие действующие данные |
Какие данные предъявил нарушитель, имел ли он право доступа и что сделал после входа |
|
Биометрическая подмена |
Нарушитель имитирует человека с помощью фото, записи, маски или подставленного видеопотока |
Как программа получила образец, какие проверки выполнила и приняла ли его |
|
Email-спуфинг |
Нарушитель подменяет отображаемые сведения об отправителе |
Какие реквизиты подделал нарушитель и как письмо связано с последующими действиями |
|
Caller ID-спуфинг |
Получатель видит подменённый номер |
Кто на самом деле звонил и с какой целью; по номеру на экране установить это нельзя |
|
IP- или ARP-спуфинг |
Нарушитель подменяет сетевые атрибуты или соответствия адресов |
Как нарушитель повлиял на передачу данных и почему участники соединения приняли подменённые сведения |
|
GPS-спуфинг |
Нарушитель передаёт ложные сведения о геопозиции |
Использует ли сервис геопозицию как сигнал риска и с какими другими данными её можно сопоставить |
Нарушитель может отправить поддельное письмо, не получив доступа к аккаунту. Он также может подменить номер звонящего, но по одному номеру нельзя установить, раскрыл ли клиент пароль или перевёл деньги. При расследовании специалисты изучают содержание сообщения или звонка и последующие действия участников.
Как спуфинг проявляется в финтехе
Клиент вводит пароль на поддельной странице после фишингового письма. Нарушитель использует пароль для входа с другого устройства, затем запрашивает смену номера для кодов подтверждения. Получение секрета соответствует механике фишинга; использование чужого пароля может соответствовать ИА-7. Перед сменой контакта сервису нужна дополнительная проверка: нарушитель уже мог войти с похищенным паролем.
В кабинете продавца на маркетплейсе нарушитель может попытаться изменить реквизиты выплат или получить доступ к учётным записям сотрудников. Команда безопасности проверяет последовательность действий: вход, смену контакта, добавление пользователя, изменение реквизитов. Клиент мог законно сменить устройство, поэтому специалисты оценивают новый профиль вместе с другими признаками и решают, нужна ли дополнительная проверка.
При подделке лица нарушитель может показать камере запись владельца аккаунта или программно подставить видеопоток. В первом случае специалисты проверяют защиту от атак предъявления. Во втором они проверяют, может ли нарушитель вмешаться в получение или передачу образца. В NIST SP 800-63A-4 авторы отдельно описывают атаки предъявления и инъекцию медиа. Мы используем документ как технический источник. Общей обязанности следовать ему у российских организаций нет.
Клиент может сам войти в банк и перевести деньги под влиянием обмана. Тогда нарушитель не обязательно подменяет пользователя при входе. При этом оператор по переводу денежных средств проверяет признаки перевода без добровольного согласия клиента по статье 8 Закона № 161-ФЗ. К таким переводам относятся и операции с согласия, полученного под влиянием обмана или злоупотребления доверием.
Как снизить риск спуфинга
Команда безопасности выбирает меры под конкретный сценарий: хищение секрета, вход с чужими данными, смену контакта или перевод денег. Эти рекомендации не составляют обязательного набора мер из проекта ГОСТа.
- Защитите почтовый домен. Администратор настраивает SPF, DKIM и DMARC, чтобы почтовые системы проверяли происхождение сообщений и применяли политику домена. Затем он контролирует отчёты и проверяет, какие источники законно отправляют почту от имени организации. По результату DMARC нельзя удостоверить личность человека, указанного в подписи письма.
- Выберите подходящий метод аутентификации. С независимым дополнительным фактором нарушителю сложнее войти по одному похищенному паролю. При выборе многофакторной аутентификации (MFA) команда безопасности отдельно проверяет устойчивость метода к фишингу: нарушитель может выманить передаваемый код. Наличие MFA ещё не гарантирует защиту от подмены проверяющей стороны. Технические требования к методам аутентификации приведены в NIST SP 800-63B-4.
- Проверяйте действия с высоким риском. При смене телефона, восстановлении доступа и изменении реквизитов команда безопасности учитывает историю сеанса. Правила дополнительной проверки и ограничения доступа она выбирает с учётом риска действия и применимых требований.
- Разделяйте биометрические проверки. При сопоставлении лица программа оценивает сходство с эталоном. С помощью PAD (presentation attack detection) программы биометрической проверки обнаруживают атаки предъявления. Проверка живости относится к методам PAD. Защиту от программной подстановки медиа команда безопасности проверяет отдельно.
- Прекращайте доступ с похищенными данными. При компрометации команда безопасности действует по регламенту: ограничивает доступ, завершает затронутые сеансы, заменяет пароль или отзывает скомпрометированный аутентификатор. Для расследования специалисты сохраняют необходимые сведения, устанавливают сроки хранения и ограничивают доступ к ним.
Какие нормы учитывать при защите от спуфинга
При выборе мер защиты организация учитывает свою роль, состав данных и действия, которые она выполняет. Код ИА-7 обозначает техническую угрозу. Чтобы определить применимые обязанности и возможное правонарушение, организации нужен отдельный правовой анализ.
Защита информации и персональных данных
По статье 16 Закона № 149-ФЗ защита информации включает правовые, организационные и технические меры. В предусмотренных законодательством случаях обладатель информации и оператор системы должны предотвращать и обнаруживать несанкционированный доступ, а также выполнять другие установленные меры. Подключение антифрод-сервиса не освобождает организацию от остальных мер защиты.
Оператор персональных данных определяет цели и основания обработки, необходимый состав сведений и сроки хранения. По статье 5 Закона № 152-ФЗ он хранит данные не дольше, чем необходимо для целей обработки, если иной срок не установлен законом или предусмотренным нормой договором. То же ограничение действует для журналов событий с персональными данными.
Когда подрядчик обрабатывает персональные данные по поручению оператора, стороны определяют условия поручения и свои обязанности по статье 6 Закона № 152-ФЗ. Технологический поставщик также соблюдает применимые к нему требования. После передачи проверки подрядчику каждая сторона сохраняет собственные обязанности.
Биометрия и автоматические решения
Если оператор использует физиологические или биологические характеристики для установления личности, он должен учитывать статью 11 Закона № 152-ФЗ. По общему правилу ему нужно письменное согласие человека на обработку таких данных; в законе предусмотрены исключения. При идентификации и аутентификации по биометрическим персональным данным оператор также проверяет применимость Закона № 572-ФЗ. Правовой режим зависит от обработки данных, а название технологии liveness само по себе его не определяет.
Организация отдельно проверяет, вправе ли она требовать биометрию и отказывать в обслуживании без неё. Если закон запрещает ставить обслуживание в зависимость от предоставления биометрии, организация предусматривает допустимый альтернативный способ проверки.
Статью 16 Закона № 152-ФЗ оператор учитывает, если принимает решение исключительно на основании автоматизированной обработки персональных данных и такое решение порождает юридические последствия для человека либо иным образом затрагивает его права и законные интересы. Оператору нужны предусмотренные законом основания для такого решения и порядок рассмотрения возражений. Наличие антифрод-сигналов само по себе не подтверждает законность решения.
Платежи, идентификация и подписание
Операторы по переводу денежных средств проверяют признаки перевода без добровольного согласия клиента по статье 8 Закона № 161-ФЗ, в том числе после успешной аутентификации. Перечень признаков приведён в приложении к приказу Банка России от 05.11.2025 № ОД-2506.
Организации, указанные в статье 7 Закона № 115-ФЗ, обязаны идентифицировать клиентов с учётом предусмотренных законом исключений. При входе, проверке живости или связи человека с номером организация проверяет отдельные сведения. Чтобы выполнить процедуру идентификации целиком, она должна соблюсти применимые требования закона.
Если организация использует код для подписания электронного документа, она учитывает статью 6 и статью 9 Закона № 63-ФЗ «Об электронной подписи». Код входа не становится электронной подписью автоматически. Для признания документа подписанным имеют значение назначение кода, правила системы и условия такого признания.
Организации и системы, которые подпадают под регулирование критической информационной инфраструктуры (КИИ), должны учитывать Закон № 187-ФЗ. Одного обозначения «финтех-сервис» недостаточно, чтобы определить, применимы ли требования КИИ.
Ответственность и права человека
При использовании чужих данных возможна ответственность за неправомерный доступ по статье 272 УК РФ. За незаконные действия с компьютерной информацией, содержащей персональные данные, ответственность предусмотрена по статье 272.1 УК РФ; за хищение посредством вмешательства в компьютерную информацию — по статье 159.6 УК РФ. Для квалификации следствию и суду нужно установить все признаки соответствующего состава. В частности, для применения статьи 159.6 следствию и суду нужно установить предусмотренный ею способ хищения. Самого факта обмана в интернете недостаточно.
При создании поддельного профиля или видеозаписи нарушитель может затронуть право человека на изображение. Обнародование и дальнейшее использование изображения регулирует статья 152.1 ГК РФ. Если нарушитель распространяет ложные порочащие сведения, при правовой оценке нужно также учитывать статью 152 ГК РФ. Публикация фотографии в интернете сама по себе не даёт другим лицам права использовать её любым способом.
Какие признаки подмены проверяют с помощью IDX
Сервис IDX Liveness анализирует признаки присутствия живого человека при видеопроверке. Чтобы оценить сходство с владельцем аккаунта, заказчику нужно отдельно сопоставить лицо с эталоном. Одного успешного результата проверки живости для подтверждения личности недостаточно.
С помощью проверки использования телефонного номера физлицом заказчик получает оценку связи физического лица с телефонным номером по шкале от 0 до 5. Он может использовать результат как дополнительный сигнал риска.
По техническому профилю устройства команда безопасности оценивает обращение вместе с другими событиями. Клиент мог законно сменить телефон, поэтому специалисты назначают дополнительную проверку с учётом совокупности данных и последствий запрашиваемого действия.
IDX предоставляет технологические проверки. Заказчик устанавливает правила доступа и реагирования с учётом обязательных требований к своей деятельности. Для вывода об инциденте его специалистам нужно сопоставить результаты проверок с другими материалами. Заказчик и IDX сохраняют собственные обязанности по обработке и защите данных.
Чем спуфинг отличается от фишинга и фарминга
При фишинге нарушитель обманом получает аутентификационные данные. При фарминге он перенаправляет пользователя на свой ресурс с помощью манипуляций с параметрами канала. При спуфинге он выдаёт себя за другую сторону. В одном инциденте нарушитель может сочетать несколько таких способов.
|
Код проекта |
Механизм |
|---|---|
|
ИА-1 «Фишинг» |
Нарушитель вовлекает доказывающую сторону во взаимодействие с ложной проверяющей или доверяющей стороной. Так он получает аутентификационную информацию либо данные для последующей подмены |
|
ИА-2 «Фарминг» |
Доказывающая сторона пытается установить сеанс с подлинной стороной. Нарушитель манипулирует параметрами канала и перенаправляет её на свой ресурс |
|
ИА-7 «Спуфинг» |
Нарушитель имитирует другую сущность, используя подлинные чужие аутентификационные данные либо иной способ выдать себя за неё |
Например, пользователь переходит по ссылке из фишингового письма и вводит пароль на поддельной странице. Затем нарушитель применяет пароль для входа. При фарминге пользователь пытается обратиться к подлинному сервису, но попадает на ресурс нарушителя из-за технического перенаправления. При расследовании специалисты фиксируют получение секрета и его последующее использование как отдельные события.
Приёмы воздействия на пользователя мы разбираем в статье о социальной инженерии.
Проверьте, принадлежит ли новый номер клиенту, прежде чем привязать его к аккаунту
