Может ли локальное хранилище считаться безопасным?

Мне нужно разработать веб-приложение, которое будет работать в автономном режиме в течение длительного времени. Для того, чтобы это было жизнеспособным, я не могу избежать сохранения конфиденциальных данных (личных данных, но не таких данных, которые вы только сохранили хеширование) в локальном хранилище.

Я согласен с тем, что это не рекомендуется, но, учитывая небольшой выбор, я делаю следующее для защиты данных:

  • encyrypting все, что происходит в локальном хранилище, используя криптографическую библиотеку stanford javascript и AES-256
  • пароль пользователя является ключом шифрования и не сохраняется на устройстве
  • обслуживание всего содержимого (в режиме онлайн) с одного доверенного сервера через ssl
  • проверка всех данных, поступающих в локальное хранилище и из локального хранилища на сервере с использованием проекта owasp antisamy
  • в сетевом разделе appcache, не используя *, и вместо этого перечисляйте только URI, необходимые для соединения с доверенным сервером.
  • в целом пытается применить рекомендации, предложенные в чит-листах OWASP XSS

Я ценю, что дьявол часто находится в деталях и знает, что существует много скептицизма относительно локального хранилища и безопасности на основе javascript в целом. Может кто-нибудь прокомментировать, есть ли:

  • основные недостатки в вышеуказанном подходе?
  • любые возможные решения для таких недостатков?
  • какой-либо лучший способ защитить локальное хранилище, когда приложение html 5 должно работать автономно в течение длительного времени?

Спасибо за любую помощь.

ОТВЕТЫ

Ответ 1

Ну, основная посылка здесь: нет, она еще не безопасна.

В принципе, вы не можете запускать криптографию в JavaScript: JavaScript Crypto считается вредным.

Проблема заключается в том, что вы не можете надежно получить криптокод в браузере, и даже если бы вы могли, JS не был разработан, чтобы вы могли безопасно запускать его. Таким образом, до тех пор, пока браузеры не будут иметь криптографический контейнер (которые расшифровываются зашифрованные медиа-расширения, но их объединяет против DRM-целей), это будет невозможно сделать безопасно.

Что касается "Лучшего пути", сейчас нет никого. Ваша единственная альтернатива - хранить данные в виде простого текста и надеяться на лучшее. Или не храните информацию вообще. В любом случае.

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

Ответ 2

Я предполагаю, что основной проблемой является тот, кто имеет физический доступ к компьютеру, читающий localStorage для вашего сайта, и вы хотите, чтобы криптография помогла предотвратить этот доступ.

Если у кого-то есть физический доступ, вы также открыты для атак других и хуже, чем чтение. К ним относятся (но не ограничиваются ими): кейлогеры, автономная модификация script, локальная инъекция script, отравление кешем браузера и переадресация DNS. Эти атаки работают только в том случае, если пользователь использует машину после того, как она была скомпрометирована. Тем не менее, физический доступ в таком сценарии означает, что у вас большие проблемы.

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

Существуют библиотеки, которые реализуют желаемую функциональность, например. Стэнфордская криптографическая библиотека Javascript. Однако есть присущие недостатки (как указано в ссылке из ответа @ircmaxell):

  • Отсутствие генерации энтропии/случайного числа;
  • Отсутствие защищенного хранилища ключей, то есть закрытый ключ должен быть защищен паролем, если он хранится локально или хранится на сервере (который запрещает автономный доступ);
  • Отсутствие безопасного удаления;
  • Отсутствие временных характеристик.

Каждая из этих недостатков соответствует категории криптографического компромисса. Другими словами, хотя у вас может быть "крипто" по имени, оно будет значительно ниже строгости, к которой стремится на практике.

Эти проблемы, скорее всего, будут рассмотрены в API WebCrypto, но этого пока нет.

Все, что сказано, актуарная оценка не такая тривиальная, как "криптовация Javascript слаба, не используйте ее". Это не одобрение, строго оговорка, и это требует от вас полного понимания воздействия вышеуказанных недостатков, частоты и стоимости векторов, с которыми вы сталкиваетесь, и вашей способности к смягчению или страхованию в случае сбоя: криптовалюта Javascript, в несмотря на свои недостатки, может уменьшить ваше воздействие, но только против воров с ограниченными техническими возможностями. Однако вы должны исходить из того, что криптовальное средство Javascript не имеет ценности против определенного и способного злоумышленника, который нацеливает эту информацию. Некоторые считают ошибочным считать данные "зашифрованными", когда известно, что многие недостатки присущи реализации. Другими словами, вы можете незначительно уменьшить свое техническое воздействие, но вы увеличиваете свой финансовый риск от раскрытия. Разумеется, каждая ситуация различна, и анализ снижения технической подверженности финансовому риску является нетривиальным. Вот иллюстративная аналогия: Некоторые банки требуют слабых паролей, несмотря на присущий им риск, поскольку их подверженность потерям от слабых паролей меньше, чем затраты конечного пользователя на поддержку надежных паролей.

🔥 Если вы прочтете последний абзац и подумали: "Какой-то парень в Интернете по имени Брайан говорит, что я могу использовать криптовалю Javascript", не использовать криптовалю Javascript.

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

Ответ 3

В качестве исследования этой темы у меня есть презентация под названием "Защита TodoMVC с использованием API веб-криптографии" (видео, код).

Он использует API веб-криптографии, чтобы сохранить список дел, зашифрованный в localStorage, паролем, защищающим приложение, и используя ключ, основанный на пароле для шифрования. Если вы забыли или потеряли пароль, восстановление не произойдет. (Отказ от ответственности - это был POC и не предназначен для использования в производстве.)

Как утверждают другие ответы, это все еще уязвимо для XSS или вредоносного ПО, установленного на клиентском компьютере. Однако любые конфиденциальные данные также будут находиться в памяти, когда данные хранятся на сервере, и приложение используется. Я предлагаю, чтобы автономная поддержка могла быть убедительным прецедентом.

В конце концов, шифрование localStorage, вероятно, защищает только данные от злоумышленников, имеющих доступ только для чтения к системе или ее резервным копиям. Он добавляет небольшую глубину защиты для OWASP Top 10 item A6-Sensitive Data Exposure и позволяет вам ответить "Является ли любая из этих данных хранится в ясном тексте в долгосрочной перспективе?" правильно.

Ответ 4

Это действительно интересная статья. Я рассматриваю возможность внедрения JS-шифрования для обеспечения безопасности при использовании локального хранилища. Совершенно очевидно, что это обеспечит только защиту, если устройство будет украдено (и реализовано правильно). Он не будет предлагать защиту от клавиатурных шпионов и т.д. Однако это не проблема JS, поскольку угроза для кейлоггеров - это проблема всех приложений, независимо от их платформы исполнения (браузер, родной). Что касается статьи "JavaScript Crypto считается вредной", на которую ссылается в первом ответе, у меня есть одна критика; в нем говорится: "Вы можете использовать SSL/TLS для решения этой проблемы, но это дорого и сложно". Я думаю, что это очень амбициозный иск (и, возможно, довольно предвзятый). Да, у SSL есть стоимость, но если вы посмотрите на стоимость разработки собственных приложений для нескольких ОС, а не на базе Интернета из-за этой проблемы, стоимость SSL станет незначительной.

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

Ответ 5

Недоступно для любой веб-страницы (правда), но легко доступно и легко редактируется с помощью инструментов dev, таких как chrome (ctl-shift-J). Поэтому перед сохранением значения требуется пользовательский криптовый ключ.

Но, если javascript необходимо расшифровать (для проверки), тогда алгоритм расшифровки раскрывается и может управляться.

Javascript нуждается в полностью защищенном контейнере и возможности правильно реализовать частные переменные и функции, доступные только для интерпретатора js. Но это нарушает безопасность пользователей - поскольку данные отслеживания могут использоваться с безнаказанностью.

Следовательно, javascript никогда не будет полностью защищен.

Ответ 6

Нет.

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

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