Одной из ключевых особенностей SJCL является собственный генератор псевдослучайных чисел, рассчитанный на работу в среде, где отсутствует гарантированно криптографически стойкий источник энтропии. В браузере это исторически решалось сбором шумов из событий мыши, клавиатуры и таймеров.
Проблема возникает в современных условиях:
Если SJCL используется до накопления достаточной энтропии, состояние PRNG становится частично предсказуемым, что приводит к:
Особенно критично это в SPA, где шифрование может происходить сразу при загрузке приложения.
Современный браузерный API
window.crypto.getRandomValues() решает эту проблему, но
SJCL может быть настроен на fallback-режим, который значительно
слабее.
JavaScript в браузере не является изолированной средой. Любой скрипт имеет доступ к глобальному контексту страницы, что создаёт фундаментальную проблему: криптографические операции выполняются в окружении, которое может быть модифицировано.
Основные риски:
Math.random,
Array, Uint32Array)JSON.stringify для утечки ключейДаже если сама SJCL реализована корректно, её окружение может быть изменено до или после загрузки библиотеки.
В браузерной модели безопасности любая XSS-уязвимость автоматически обнуляет криптографическую защиту на уровне приложения.
При использовании SJCL типичный сценарий выглядит так:
При наличии XSS атакующий получает:
Особенность SJCL в том, что он часто применяется для клиентского шифрования сообщений, паролей или локального хранения, что делает последствия XSS эквивалентными полному компромиссу данных.
В браузере данные часто проходят через DOM-слой, что создаёт дополнительные поверхности атаки:
SJCL не контролирует, как приложение использует результат расшифровки. В результате типичная ошибка выглядит так:
Даже кратковременное присутствие секретов в памяти страницы увеличивает риск их извлечения через DevTools или вредоносные скрипты.
SJCL часто используется для шифрования данных перед сохранением в
localStorage. Однако сама модель хранения в браузере
создаёт дополнительные угрозы:
Ключевая ошибка архитектуры:
шифрование на клиенте не защищает от атак в рамках того же origin
Если ключ хранится рядом с зашифрованными данными (даже частично), устойчивость системы падает до нуля.
В сложных приложениях SJCL может использоваться в нескольких iframe,
которые обмениваются данными через postMessage.
Типовые уязвимости:
Если атакующий получает доступ к одному iframe, он может:
Хотя браузер ограничивает доступ к низкоуровневым таймингам, остаются косвенные каналы:
SJCL, как чисто JS-реализация, работает заметно медленнее WebCrypto, что увеличивает поверхность тайминговых атак в локальных сценариях.
Особенно это проявляется при:
SJCL часто подключается как внешняя библиотека через CDN или сборочные системы.
Риски:
В браузере любой изменённый файл становится частью доверенной среды выполнения, что делает supply chain одной из самых критичных угроз.
В отличие от WebCrypto API, SJCL полностью работает в JavaScript и не использует аппаратные хранилища (TPM, Secure Enclave).
Это приводит к следующим последствиям:
Даже кратковременный доступ к DevTools даёт атакующему возможность восстановить состояние криптосистемы.
Браузерные приложения часто включают:
Если SJCL используется без строгой политики логирования, возможны:
В браузере эти данные часто уходят в сторонние сервисы без контроля приложения.
Распространённая архитектура — использование SJCL как fallback при отсутствии WebCrypto.
Ошибки возникают при:
Это приводит к состояниям, где:
Такие гибридные системы часто создают ложное ощущение безопасности при фактической нестабильности криптографического слоя.
Расширения имеют расширенные права доступа к странице:
SJCL в таком окружении полностью прозрачен:
Это делает модель доверия полностью зависящей от установленных расширений пользователя.
JavaScript-объекты, содержащие криптографические данные SJCL, часто проходят через:
Ошибки возникают, когда:
Даже если SJCL корректно защищает данные на уровне алгоритма, ошибка сериализации приводит к их утечке вне криптографического контекста.