АРХИТЕКТУРА МНОГОУРОВНЕВОЙ ЗАЩИТЫ WEB STORAGE ДЛЯ БРАУЗЕРНЫХ ИГР

MULTI-LAYERED WEB STORAGE SECURITY ARCHITECTURE FOR BROWSER GAMES
Цитировать:
Чернецкий И.И. АРХИТЕКТУРА МНОГОУРОВНЕВОЙ ЗАЩИТЫ WEB STORAGE ДЛЯ БРАУЗЕРНЫХ ИГР // Universum: технические науки : электрон. научн. журн. 2025. 8(137). URL: https://7universum.com/ru/tech/archive/item/20666 (дата обращения: 05.12.2025).
Прочитать статью:
DOI - 10.32743/UniTech.2025.137.8.20666

 

АННОТАЦИЯ

В статье рассматриваются проблемы безопасного хранения пользовательского прогресса в браузерных играх с помощью Web Storage (localStorage и sessionStorage). Показаны ключевые уязвимости этого подхода: ручная подмена данных, повторное воспроизведение старых сохранений, внедрение вредоносного кода и утечка через XSS. Для иллюстрации каждого вектора атаки предложен и реализован ряд простых стратегий — от сериализации в чистый JSON до лёгких схем обфускации, XOR-шифрования с контрольной суммой, подписей HMAC-SHA256 и полноценного шифрования AES-GCM. Заключение статьи подчёркивает важность отказа от хранения «голых» секретов на клиенте, необходимости серверной валидации критичных операций и рекомендации по комбинированию шифрования, HMAC и временных меток для создания многоуровневой системы защиты.

ABSTRACT

This paper examines the challenges of securely storing user progress in browser‐based games using Web Storage (localStorage and sessionStorage). It highlights the primary vulnerabilities of this approach — manual data tampering, replay of outdated saves, malicious code injection, and data leakage via XSS. To demonstrate each attack vector, a range of simple strategies is proposed and implemented, from plain JSON serialization through lightweight obfuscation, XOR encryption with checksum, HMAC-SHA256 signing, up to full AES-GCM encryption.

The conclusion underscores the importance of never storing plaintext secrets on the client, enforcing server-side validation for critical operations, and combining encryption, HMAC, and timestamps to build a multi-layered defense model.

 

Ключевые слова: безопасность, Web Storage, localStorage, клиентское хранилище, AES-GCM, HMAC-SHA256, Web Crypto API.

Keywords: security, Web Storage, localStorage, client-side storage, AES-GCM, HMAC-SHA256, Web Crypto API.

 

ВВЕДЕНИЕ

Web Storage (localStorage и sessionStorage) часто используется для клиентского сохранения прогресса в браузерных играх. API простое и синхронное, однако все данные хранятся в открытом виде и доступны через DevTools, что делает их уязвимыми к ряду атак [1] [2]:

  • Manual Tampering: ручное изменение через консоль.
  • Replay Attack: повторное использование старых сохранений.
  • Debug Injection: внедрение скриптов или перехват функций.
  • Data Leak: чтение или утечка через XSS и сторонние скрипты.

Целью данного исследования является разработка архитектуры многоуровневой защиты пользовательских данных в Web Storage, предназначенной для браузерных игр. Основное внимание уделяется минимизации риска манипуляций и несанкционированного доступа к сохранённому прогрессу без привлечения сторонних библиотек.

Задачи исследования включают:

  • Анализ уязвимостей существующих подходов к хранению данных в Web Storage;
  • Реализацию и тестирование пяти стратегий защиты, включая обфускацию, XOR-шифрование, HMAC-SHA256 и AES-GCM;
  • Сравнительный анализ методов по критериям устойчивости к атакам, производительности и сложности интеграции;
  • Формулирование рекомендаций по построению многоуровневой системы безопасности.

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

МАТЕРИАЛЫ И МЕТОДЫ

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

1. Простой JSON в localStorage

Описание

Данные сериализуются в JSON и сохраняются без шифрования.

Реализация

Устойчивость к взлому

Нулевая — любой пользователь сразу видит и может изменить содержимое.

Способы обхода защиты

Неприменимо, защита отсутствует.

Преимущества

  • Минимальная сложность
  • Мгновенное сохранение и загрузка

Недостатки

  • Полная уязвимость к подменам и анализу
  • Нет защиты от Replay и Debug Injection

2. Обфускация + Base64

Описание

Сериализованный JSON дополнительно кодируется Base64 и возвращается в обратную строку [3].

Реализация

Устойчивость к взлому

Низкая — скрывает структуру, но не саму информацию.

Способы обхода защиты

  • Декодировать Base64 и обратить строку.
  • Быстрый реверсинг через DevTools.

Преимущества

  • Простая реализация
  • Затрудняет мгновенное понимание для неподготовленного пользователя

Недостатки

  • Легко дешифруется вручную
  • Не защищает от Replay и Debug Injection

3. XOR-шифр + контрольная сумма

Описание

Используется простейший XOR-шифр для шифрования и на стороне клиента хранится контрольная сумма (hash) исходного JSON [4].

Реализация

Устойчивость к взлому

Средняя — атакующий должен угадать ключ или скомпрометировать код, но контрольная сумма защитит от простых подмен.

Способы обхода защиты

  • Изучить ключ в исходниках (Debug Injection).
  • Перехватить ключ через XSS (Data Leak).
  • Провести brute-force по короткому ключу [5].

Преимущества

  • Шифрование затрудняет прямое чтение сохранений.
  • Контрольная сумма обнаружит большинство некорректных модификаций.

Недостатки

  • XOR-шифр ненадежен при коротком ключе.
  • Ключ хранится в клиентском коде.
  • Уязвим к Replay (отсутствует timestamp).

4. HMAC-SHA256 + timestamp через Web Crypto API

Описание

Используем встроенное Web Crypto API для вычисления HMAC-SHA256 от данных + timestamp. Хранится {payload, timestamp, hmac}.

Реализация

Устойчивость к взлому

Высокая — при надежном ключе атакующему сложно подделать подпись.

Способы обхода защиты

  • Кража секретного ключа из кода или XSS (Data Leak).
  • Replay старого payload (но timestamp ограничивает окно атаки) [6].

Преимущества

  • Надежная целостность и аутентичность данных.
  • Отсечение Replay через проверку возраста.

Недостатки

  • Сложнее и async API.
  • Ключ все еще хранится на клиенте.
  • Возможен Data Leak при недостаточной защите скриптов.

5. AES-GCM через Web Crypto API

Описание

Шифрование состояния AES-GCM, хранение {iv, ciphertext}. Расшифровка только с правильным ключом [7].

Реализация

Устойчивость к взлому

Очень высокая — при надежном ключе невозможно расшифровать или модифицировать данные.

Способы обхода защиты

  • Извлечение ключа через XSS или перехват кода (Data Leak).
  • Debug Injection для подмены функций до или после шифрования.

Преимущества

  • Конфиденциальность и целостность “в одном флаконе”.
  • Нет необходимости в дополнительной HMAC.

Недостатки

  • Асинхронность, более сложная логика.
  • Overhead по CPU при частых сохранениях.
  • Требует аккуратной работы с ключом.

РЕЗУЛЬТАТЫ И ОБСУЖДЕНИЕ

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

Таблица 1.

Сравнение эффективности методов

Метод

Обход защиты

Преимущества

Недостатки

Plain JSON

мгновенно

макс. простота

полная уязвимость

Obfuscation+Base64

лёгкий реверс

затрудняет casual-юзера

не даёт крипто-защиты

XOR+Checksum

brute-force ключа

минимальное шифрование + контроль целостности

слабый шифр, ключ в коде

HMAC-SHA256+Timestamp (Web Crypto)

утечка ключа, старые Replay

сильная целостность, анти-replay

async, ключ в коде

AES-GCM (Web Crypto)

утечка ключа, Debug Injection

конфиденциальность + целостность

overhead, async, сложнее реализация

 

Защита от атак

1. Manual Tampering

1.1. Шифруйте и подписывайте данные.

1.2. Проверяйте целостность при каждом запуске.

2. Replay Attack

2.1. Добавляйте временные метки (timestamp).

2.2. Ограничивайте возраст сохранений.

3. Debug Injection

3.1. Обфусцируйте критичные модули.

3.2. Минимизируйте использование глобальных функций.

4. Data Leak

4.1. Строгий Content Security Policy (CSP).

4.2. Избегайте инъекции ключей в глобальный scope.

4.3. Засекайте подозрительные XHR/WebSocket запросы [8].

Общие рекомендации

  1. Никогда не храните секретный ключ полностью в client-side без серверной валидации.
  2. При возможности синхронизируйте прогресс на сервере.
  3. Ограничивайте доверие к данным из browser storage.
  4. Используйте комбинированные методы: шифрование + HMAC + timestamp.
  5. Проводите регулярный security-аудит и pen-testing.

ЗАКЛЮЧЕНИЕ

Web Storage — удобный инструмент для сохранения игровых данных, но без дополнительных криптографических мер он полностью уязвим к подменам и различным атакам. Статья показала пять подходов «от простого к надежному», каждый из которых следует применять, учитывая требования конкретной игры и готовность инвестировать в безопасность [9]:

  • Проекты с низкими требованиями к безопасности могут обойтись JSON или лёгкой обфускацией, экономя ресурсы на разработку и производительность.
  • Для большинства браузерных игр оптимальным компромиссом станет HMAC-SHA256 с timestamp: простая в реализации проверка целостности и защита от replay с приемлемым overhead.
  • Высокобюджетные проекты с критичным хранением приватных данных требуют полного шифрования AES-GCM и, по возможности, дополнительной подписи HMAC.

Независимо от выбранного метода, рекомендуется:

  • Никогда не держать единственный секретный ключ исключительно на клиенте.
  • При возможности дублировать или проверять сохранения на стороне сервера.
  • Комбинировать методы: обфускацию, шифрование, подпись и временные метки. Для повышения уровня защиты рекомендуется комбинировать AES-GCM (конфиденциальность) с HMAC-SHA256 (аутентичность) и timestamp (анти-replay), а ключевые операции по-прежнему дублировать или проверять на сервере [10]

 

Список литературы:

  1. Маслов, А. С. Защита клиентской стороны веб-приложений: угрозы и решения / А. С. Маслов // Научный аспект. – 2024. – Т. 23, № 7. – С. 2793-2800.
  2. Dalimunthe, S. Restful API Security Using JSON Web Token (JWT) With HMAC-Sha512 Algorithm in Session Management / S. Dalimunthe, E. Hasri Putra, M. A. Fadhly Ridha // IT Journal Research and Development. – 2023. – Vol. 8, No. 1. – P. 81-94. – DOI 10.25299/itjrd.2023.12029. – EDN QOPBSR.
  3. Лесько, С. А. Модели и сценарии реализации угроз для интернет-ресурсов / С. А. Лесько // Российский технологический журнал. – 2020. – Т. 8, № 6(38). – С. 9-33. – DOI 10.32362/2500-316X-2020-8-6-9-33.
  4. Халмурадова, Й. Кибербезопасность и защита данных / Й. Халмурадова, А. Бегмедов, С. Курбангелдиев // Инновационная наука. – 2024. – Т. 1, № 11-2. – С. 37-38.
  5. Jeong, J. Ho. A Study on the Security of Web Application using Enhanced Secure Cookie / J. Ho. Jeong, Y. W. Cha // The Journal of Korean Institute of Information Technology. – 2024. – Vol. 22, No. 2. – P. 195-204. – DOI 10.14801/jkiit.2024.22.2.195. – EDN VRNJAP.
  6. Частикова, В. А. Анализ безопасности веб-приложений / В. А. Частикова, М. К. Алиев, А. А. Тесленко // Электронный сетевой политематический журнал "Научные труды КубГТУ". – 2025. – № 2. – С. 99-116. – DOI 10.26297/2312-9409.2025.2.9.
  7. Safeguard confidential web information from malicious browser extension using Encryption and Isolation techniques / M. Marimuthu, G. Mohanraj, D. Karthikeyan, D. Vidyabharathi // Journal of Intelligent and Fuzzy Systems. – 2023. – Vol. 45, No. 4. – P. 6145-6160. – DOI 10.3233/jifs-233122. – EDN QUEJQA.
  8. Шатурный, М. В. Анализ актуальных угроз и разработка подходов к защите веб - приложений / М. В. Шатурный // Инженерный вестник Дона. – 2024. – № 7(115). – С. 109-120.
  9. Москвин, А. Д. Анализ современных алгоритмов шифрования данных / А. Д. Москвин, Л. Э. Петросян // Инженерный вестник Дона. – 2023. – № 4(100). – С. 102-115.
  10. Галигузова, Е. В. Алгоритмы шифрования данных / Е. В. Галигузова, Ю. Е. Илларионова // Символ науки: международный научный журнал. – 2023. – № 1-2. – С. 11-14.
Информация об авторах

веб-разработчик, Санкт-Петербургский политехнический университет Петра Великого, РФ, г. Санкт-Петербург

Web developer, Peter the Great St.Petersburg Polytechnic University, Russia, St.Petersburg

Журнал зарегистрирован Федеральной службой по надзору в сфере связи, информационных технологий и массовых коммуникаций (Роскомнадзор), регистрационный номер ЭЛ №ФС77-54434 от 17.06.2013
Учредитель журнала - ООО «МЦНО»
Главный редактор - Звездина Марина Юрьевна.
Top