Изолированное хранилище
Если речь идет о классических приложениях, изолированное хранилище — это механизм хранения данных, обеспечивающий изоляцию и безопасность путем определения стандартизованных способов сопоставления кода с сохраненными данными. Стандартизация также имеет и другие преимущества. Администраторы могут использовать инструменты управления изолированным хранением для конфигурирования пространства хранения файлов, установки политики безопасности и удаления неиспользуемых данных. При изолированном хранении нет необходимости указывать уникальные пути для безопасного размещения кода в файловой системе, и данные защищены от других приложений, имеющих доступ только к изолированному хранению. Нет необходимости в аппаратно закодированной информации, указывающей место размещения области хранения данных приложения.
Внимание
Изолированное хранилище недоступно для приложений Магазина Windows 8.x. Вместо этого используйте классы данных приложений в пространствах имен Windows.Storage
, включенных в API среды выполнения Windows для хранения локальных данных и файлов. Дополнительные сведения см. в статье Доступ к данным приложения в Центре разработки для Windows.
Секции данных и хранилища
Когда приложение сохраняет данные в файле, выбирать имя файла и место его хранения следует так, чтобы минимизировать вероятность того, что место хранения данных будет доступно другим приложениям и, следовательно, станет уязвимым к повреждению. В отсутствие стандартной системы для решения подобных проблем импровизированная разработка средств минимизации конфликтов хранения может стать чрезмерно сложной, а ее результаты — ненадежными.
В изолированном хранилище данные всегда изолированы по пользователю или сборке. Сборка идентифицируется учетными данными, такими как источник или строгое имя. Данные также могут быть изолированы по домену приложения при помощи подобных учетных данных.
В изолированном хранилище приложение сохраняет данные в уникальной ячейке данных, привязанной к одному из аспектов, идентифицирующих код, например к издателю или подписи. Ячейка данных — это абстракция, а не определенное место хранения. Она состоит из одного или нескольких файлов для изолированного хранения, называемых хранилищами, которые содержат действительные адреса каталогов, в которых хранятся данные. Например, приложение может иметь связанную с ним ячейку данных, а действительное хранение данных для этого приложения может осуществляться в каталоге файловой системы. Данные, сохраняемые в хранилище, могут быть любого типа, от информации о пользовательских настройках до состояния приложения. Для разработчика расположение ячейки данных является прозрачным. Хранилища обычно находятся на клиенте, но серверное приложение может использовать изолированные хранилища для информации путем олицетворения пользователя, от лица которого оно действует. В изолированном хранилище информация также может храниться на сервере с перемещаемым профилем пользователя, что обеспечивает ее перемещение вместе с пользователем.
Квоты для изолированного хранилища
Квота — это ограничение доступного для использования объема изолированного хранилища. Квота учитывает байты файлового пространства, а также служебные данные, связанные с каталогом и другой информацией в хранилище. Изолированное хранилище использует квоты разрешения, которые представляют собой допустимые пределы хранения, устанавливаемые посредством объектов IsolatedStoragePermission . При попытке записать данные в превышение квоты возникает исключение IsolatedStorageException . Какие разрешения даются коду, определяет политика безопасности, которую можно менять с помощью средства настройки .NET Framework (Mscorcfg.msc). Для кода, которому предоставлено разрешение IsolatedStoragePermission , выделяется хранилище, максимальный размер которого определяется свойством UserQuota . Тем не менее, поскольку код может обходить квоты разрешения, используя различные удостоверения пользователя, эти квоты в большей степени имеют характер рекомендаций по работе кода, нежели выступают в роли строгих ограничений.
К перемещаемым хранилищам квоты не применяются. По этой причине для их использования код должен располагать разрешениями несколько более высокого уровня. Значения перечисления AssemblyIsolationByRoamingUser и DomainIsolationByRoamingUser определяют разрешение на использование изолированного хранилища для перемещаемого профиля пользователя.
безопасный доступ
Использование изолированного хранения позволяет частично доверенным приложениям сохранять данные под контролем политики безопасности компьютера. Это особенно удобно при работе с загружаемыми компонентами, которые не вызывают у пользователя полного доверия. Политика безопасности редко предоставляет такому коду право доступа к файловой системе с использованием стандартных механизмов ввода-вывода. Однако по умолчанию код, запускаемый с локального компьютера, из локальной или глобальной сети получает право на использование изолированного хранилища.
Администраторы могут ограничивать размеры изолированного хранилища, доступного приложению или пользователю, в зависимости от соответствующего уровня доверия. Кроме того, администраторы могут удалить все хранящиеся данные. Чтобы создать изолированное хранилище или получить доступ к нему, коду необходимо предоставить соответствующее разрешение IsolatedStorageFilePermission .
Для доступа к изолированному хранилищу коду должны быть назначены все необходимые права операционной системы собственной платформы. Должны быть выполнены требования списков управления доступом, которые определяют, какие пользователи имеют права на пользование файловой системой. Приложения .NET по умолчанию имеют права доступа к изолированному хранилищу на уровне операционной системы, если только они не выполняют олицетворение (специфическое для платформы). В таком случае ответственность за обеспечение наличия у олицетворяемого пользователя прав, необходимых для доступа к изолированному хранилищу, несет приложение. Такой доступ позволяет коду, запускаемому или загружаемому через Интернет, выполнять чтение и запись в области хранения, относящейся к конкретному пользователю.
Для управления доступом к изолированному хранилищу среда CLR использует объекты IsolatedStorageFilePermission . Каждый объект имеет свойства, которые определяют следующие значения:
Разрешенное использование, которое указывает тип разрешенного доступа. Значения являются членами перечисления IsolatedStorageContainment . Дополнительные сведения об этих значениях см. в таблице в следующем разделе.
Квота хранилища, описанная в предыдущем разделе.
Среда выполнения требует разрешения IsolatedStorageFilePermission при первой попытке открыть хранилище. Решение о предоставлении этого разрешения определяется с учетом надежности кода. Если разрешение выдается, значения квоты использования и хранилища определяются политикой безопасности и запросом кода на получение разрешения IsolatedStorageFilePermission. Политика безопасности задается с помощью средства настройки .NET Framework (Mscorcfg.msc). Все вызывающие программы в стеке вызовов проверяются на наличие по меньшей мере одного соответствующего разрешения на использования. Среда выполнения также проверяет наличие квоты у кода, открывшего или создавшего хранилище, в которое записывается файл. Если все эти условия выполнены, то выдается разрешение. Квота проверяется каждый раз при записи файла в хранилище.
Коду приложения не нужно запрашивать разрешение, поскольку среда CLR выдаст соответствующее разрешение IsolatedStorageFilePermission , исходя из политики безопасности. Однако имеет смысл запрашивать определенные разрешения для своего приложения, включая IsolatedStorageFilePermission.
Разрешенное использование и угрозы безопасности
Разрешенное использование, заданное при помощи IsolatedStorageFilePermission , определяет степень, в которой коду разрешено создавать и использовать изолированное хранилище. В следующей таблице приведено соответствие между разрешенным использованием и типами изоляции, а также кратко описаны риски безопасности, связанные с каждым из видов разрешенного использования.
Разрешенное использование | Типы изоляции | Риски безопасности |
---|---|---|
None | Нет разрешения на изолированное хранилище. | Влияния на безопасность нет. |
DomainIsolationByUser | Изоляция по пользователям, доменам и сборкам. Каждая сборка имеет отдельное вложенное хранилище внутри домена. Хранилища, использующие это разрешение, также неявно изолируются компьютером. | Этот уровень разрешения оставляет возможность несанкционированного чрезмерного использования ресурсов, хотя применение квот делает это затруднительным. Этот процесс называется атакой типа "отказ в обслуживании". |
DomainIsolationByRoamingUser | То же, что и DomainIsolationByUser , однако хранилище сохраняется в перемещаемое расположение, если применяются перемещаемые профили пользователей и не применяются квоты. |
Поскольку квоты приходится отключать, то ресурсы хранения более уязвимы к атаке типа "отказ в обслуживании". |
AssemblyIsolationByUser | Изоляция по пользователям и сборкам. Хранилища, использующие это разрешение, также неявно изолируются компьютером. | На этом уровне применяются квоты для предотвращения атак типа "отказ в обслуживании". Та же сборка в другом домене может иметь доступ к хранилищу, что может привести к утечке информации между приложениями. |
AssemblyIsolationByRoamingUser | То же, что и AssemblyIsolationByUser , однако хранилище сохраняется в перемещаемое расположение, если применяются перемещаемые профили пользователей и не применяются квоты. |
То же, что и AssemblyIsolationByUser , но без квот; риск атак типа "отказ в обслуживании" возрастает. |
AdministerIsolatedStorageByUser | Изоляция по пользователям. Обычно этот уровень разрешения используют только средства администрирования или отладки. | Доступ с этим уровнем разрешения позволяет коду просматривать или удалять любые файлы и каталоги изолированного хранилища пользователя (независимо от изоляции сборки). Риски, помимо прочего, включают утечку информации и потерю данных. |
UnrestrictedIsolatedStorage | Изоляция по всем пользователям, доменам и сборкам. Обычно этот уровень разрешения используют только средства администрирования или отладки. | Это разрешение может привести к потере защищенной информации всех изолированных хранилищ для всех пользователей. |
Безопасность компонентов изолированного хранилища по отношению к ненадежным данным
Этот раздел применяется к следующим платформам.
- .NET Framework (все версии)
- .NET Core 2.1+
- .NET 5.+
.NET Framework и .NET Core предлагают изолированное хранилище в качестве механизма сохранения данных для пользователя, приложения или компонента. Это устаревший компонент, изначально разрабатывавшийся для сценариев управления доступом для кода, которые сейчас объявлены нерекомендуемыми.
Для считывания данных через границы доверия можно использовать различные средства и интерфейсы API изолированного хранилища. Например, считывание данных из области на уровне компьютера может агрегировать данные из других, возможно, менее доверенных учетных записей пользователей на компьютере. Компоненты или приложения, которые считывают данные из областей изолированного хранилища на уровне компьютера, должны быть осведомлены о последствиях такого считывания.
Чувствительные к безопасности API, которые могут считывать данные из области на уровне компьютера
Компоненты или приложения, вызывающие любой из следующих интерфейсов API, считывают данные из области на уровне компьютера.
- IsolatedStorageFile.GetEnumerator с передачей области, включающей флаг IsolatedStorageScope.Machine
- IsolatedStorageFile.GetMachineStoreForApplication
- IsolatedStorageFile.GetMachineStoreForAssembly
- IsolatedStorageFile.GetMachineStoreForDomain
- IsolatedStorageFile.GetStore с передачей области, включающей флаг IsolatedStorageScope.Machine
- IsolatedStorageFile.Remove с передачей области, включающей флаг
IsolatedStorageScope.Machine
Средство изолированного хранилища storeadm.exe
используется при вызове с параметром /machine
, как показано в следующем коде.
storeadm.exe /machine [any-other-switches]
Это средство изолированного хранилища предоставляется в составе Visual Studio и пакета SDK для .NET Framework.
Если приложение не связано с вызовами предыдущих API или если рабочий процесс не подразумевает вызов storeadm.exe
подобным образом, этот документ не применяется.
Влияние в многопользовательских средах
Как упоминалось ранее, влияние этих API на безопасность связано с тем, что данные, записанные из одной среды доверия, считываются из другой среды доверия. Изолированное хранилище обычно использует для чтения и записи данных одно из трех расположений.
%LOCALAPPDATA%\IsolatedStorage\
: например,C:\Users\<username>\AppData\Local\IsolatedStorage\
дляUser
области.%APPDATA%\IsolatedStorage\
: например,C:\Users\<username>\AppData\Roaming\IsolatedStorage\
дляUser|Roaming
области.%PROGRAMDATA%\IsolatedStorage\
: например,C:\ProgramData\IsolatedStorage\
дляMachine
области.
Два первых расположения изолированы для каждого пользователя. Windows гарантирует, что разные учетные записи пользователей на одном компьютере не смогут получить доступ к папкам профиля других пользователей. Две разные учетные записи пользователей, использующие хранилища User
или User|Roaming
, не будут видеть данные друг друга и не смогут повлиять на них.
Третье расположение является общим для всех учетных записей пользователей на компьютере. Различные учетные записи могут считывать данные из этого расположения и записывать их в него, а также просматривать данные друг друга.
Указанные выше пути могут отличаться в зависимости от используемой версии Windows.
Теперь давайте рассмотрим многопользовательскую систему с двумя зарегистрированными пользователями — Мэллори и Бобом. Мэллори имеет доступ к своему каталогу профиля пользователя C:\Users\Mallory\
и может получить доступ к общему расположению хранилища на уровне компьютера C:\ProgramData\IsolatedStorage\
. Она не может получить доступ к каталогу профиля пользователя Боба C:\Users\Bob\
.
Если Мэллори захочет атаковать Боба, она может записать данные в расположение хранилища на уровне компьютера, а затем попытаться вынудить Боба выполнить чтение из этого хранилища. Когда Боб запускает считанное из этого хранилища приложение, оно будет работать с данными, помещенными туда Мэллори, но в контексте учетной записи пользователя Боба. В оставшейся части этого документа описаны различные векторы атаки, а также действия, которые приложения могут предпринимать для снижения риска таких атак.
Примечание.
Чтобы произвести подобную атаку, Мэллори потребуется следующее.
- Учетная запись пользователя на компьютере.
- Возможность поместить файл в известное расположение в файловой системе.
- Знание того, что в определенный момент Боб запустит приложение, которое попытается считать эти данные.
Это не те векторы угроз, которые применяются к стандартным настольным системам с одним пользователем, таким как домашние компьютеры или однопользовательские корпоративные рабочие станции.
Несанкционированное получение привилегий
Атака, основанная на повышении привилегий, происходит, когда приложение Боба считывает файл Мэллори и автоматически пытается предпринять определенные действия на основе содержимого этих полезных данных. Представьте себе приложение, которое считывает содержимое сценария запуска из хранилища на уровне компьютера и передает эти данные в Process.Start
. Если Мэллори может поместить вредоносный сценарий в хранилище на уровне компьютера, то при запуске Бобом его приложения происходит следующее.
- Его приложение анализирует и запускает вредоносный сценарий Мэллори в контексте профиля пользователя Боба.
- Мэллори получает доступ к учетной записи Боба на локальном компьютере.
Отказ в обслуживании
Атака типа отказ в обслуживании происходит, когда приложение Боба считывает файл Мэллори и аварийно завершает работу либо перестает работать правильно. Снова представьте себе приложение, упомянутое ранее, которое пытается проанализировать сценарий запуска из хранилища на уровне компьютера. Если Мэллори может поместить файл с некорректным содержимым в хранилище на уровне компьютера, она может:
- заставить приложение Боба вызывать исключение на раннем этапе процедуры запуска;
- предотвратить успешный запуск приложения из-за этого исключения.
Таким образом, она помешала Бобу запустить приложение под его учетной записью пользователя.
Раскрытие информации
Атака, основанная на раскрытии информации, происходит, когда Мэллори может вынудить Боба раскрыть содержимое файла, к которому у Мэллори в общем случае нет доступа. Представьте себе, что Боб имеет секретный файл C:\Users\Bob\secret.txt, который Мэллори хочет прочитать. Она знает путь к этому файлу, но не может прочитать его, так как Windows не позволяет ей получить доступ к каталогу профиля пользователя Боба.
Вместо этого Мэллори помещает в хранилище на уровне компьютера жесткую связь. Это особый тип файла, который не имеет содержимого, а указывает на другой файл на диске. Попытка считать такой файл с жесткой связью приведет к считыванию содержимого файла, на который эта связь ссылается. После создания жесткой связи Мэллори по-прежнему не может прочитать содержимое файла, так как у нее нет доступа к целевому объекту (C:\Users\Bob\secret.txt
) этой связи. Однако у Боба такой доступ есть.
Когда приложение Боба считывает данные из хранилища на уровне компьютера, оно непреднамеренно считывает содержимое его файла secret.txt
, как если бы этот файл находился в хранилище на уровне компьютера. Когда приложение Боба завершает работу, если он пытается повторно сохранить файл в хранилище на уровне компьютера, он в конечном итоге помещает фактическую копию файла в каталог *C:\ProgramData\IsolatedStorage*. Так как этот каталог доступен для чтения любым пользователем на компьютере, Мэллори может читать содержимое файла.
Рекомендации по защите от подобных атак
Важно. Если в вашей среде несколько взаимонадежных пользователей, не вызывайте API IsolatedStorageFile.GetEnumerator(IsolatedStorageScope.Machine)
или не вызывайте средствоstoreadm.exe /machine /list
. Оба этих компонента предполагают работу с надежными данными. Если злоумышленник может поместить вредоносные данные в хранилище на уровне компьютера, они могут использоваться для атаки с повышением привилегий в контексте того пользователя, который выполняет эти команды.
При работе в многопользовательской среде рекомендуется рассмотреть возможность использования функций изолированного хранилища, предназначенных для области Компьютер. Если приложение должно считывать данные из расположения на уровне компьютера, рекомендуется считывать данные из такого расположения, которое доступно для записи только учетным записям администратора. Каталог %PROGRAMFILES%
и куст реестра HKLM
являются примерами расположений, которые доступны для записи только администраторам, а для чтения — всем пользователям. Поэтому данные, считанные из этих расположений, считаются надежными.
Если приложение должно использовать область Компьютер в многопользовательской среде, проверяйте содержимое любого файла, считываемого из хранилища на уровне компьютера. Если приложение десериализует графы объектов из таких файлов, рекомендуется использовать более безопасные сериализаторы, такие как XmlSerializer
, вместо опасных, таких как BinaryFormatter
или NetDataContractSerializer
. Соблюдайте осторожность при работе с глубоко вложенными графами объектов или графами объектов, выделяющими ресурсы на основе содержимого файла.
Расположения изолированных хранилищ
В некоторых случаях рекомендуется проверять изменения в изолированном хранилище, используя файловую систему операционной системы. Могут потребоваться сведения о размещении файлов изолированного хранилища. Место их размещения зависит от операционной системы. Ниже в таблице приведены корневые адреса файлов изолированного хранилища для некоторых распространенных операционных систем. В корневых адресах см. каталоги Microsoft\IsolatedStorage. Для того чтобы отобразить изолированное хранилище в файловой системе, нужно изменить настройки папки, установив для нее отображение скрытых файлов и папок.
Операционная система | Местоположение в файловой системе |
---|---|
Windows 2000, Windows XP, Windows Server 2003 (обновление Windows NT 4.0) | Перемещаемые хранилища = <SYSTEMROOT>\Profiles\<user>\Application Data Неперемещаемые хранилища = <SYSTEMROOT>\Profiles\<user>\Local Settings\Application Data |
Windows 2000 — чистая установка (и обновление с Windows 98 и Windows NT 3.51) | Перемещаемые хранилища = <SYSTEMDRIVE>\Documents and Settings\<user>\Application Data Неперемещаемые хранилища = <SYSTEMDRIVE>\Documents and Settings\<user>\Local Settings\Application Data |
Windows XP, Windows Server 2003 — чистая установка (или обновление с Windows 2000 и Windows 98) | Перемещаемые хранилища = <SYSTEMDRIVE>\Documents and Settings\<user>\Application Data Неперемещаемые хранилища = <SYSTEMDRIVE>\Documents and Settings\<user>\Local Settings\Application Data |
Windows 8, Windows 7, Windows Server 2008, Windows Vista | Перемещаемые хранилища = <SYSTEMDRIVE>\Users\<user>\AppData\Roaming Неперемещаемые хранилища = <SYSTEMDRIVE>\Users\<user>\AppData\Local |
Создание, перечисление и удаление изолированного хранилища
В составе .NET есть три класса в пространстве имен System.IO.IsolatedStorage, которые помогают выполнять задачи, включающие изолированное хранилище.
КлассIsolatedStorageFile, производный от класса System.IO.IsolatedStorage.IsolatedStorage , обеспечивает базовую функциональность для управления хранимыми сборками и файлами приложений. Экземпляр класса IsolatedStorageFile служит для представления единичного хранилища, расположенного в файловой системе.
КлассIsolatedStorageFileStream , производный от класса System.IO.FileStream , предоставляет доступ к файлам, расположенным в хранилище.
КлассIsolatedStorageScope — это перечисление, позволяющее создавать и выбирать хранилища с необходимым типом изоляции.
Классы, предназначенные для работы с изолированными хранилищами, позволяют создавать, перечислять и удалять изолированные хранилища. Доступ к методам, используемым для выполнения этих действий, осуществляется с помощью объекта IsolatedStorageFile . Для выполнения некоторых операций необходимо разрешение IsolatedStorageFilePermission , обеспечивающее право администрирования изолированного хранилища. Для доступа к некоторым файлам и каталогам также могут потребоваться права операционной системы.
Несколько примеров распространенных задач, связанных с изолированным хранилищем, см. в практических руководствах, перечисленных в разделе Связанные разделы.
Сценарии изолированного хранилища
Изолированное хранилище может оказаться полезным во многих случаях, в том числе в следующих четырех ситуациях:
Загружаемые элементы управления. Элементам управления, загружаемым через Интернет, не разрешено записывать данные на жесткий диск посредством обычных классов ввода-вывода, но они могут использовать изолированное хранилище для хранения параметров пользователя и состояний приложения.
Хранение общих компонентов. Компоненты, общие для нескольких приложений, могут использовать изолированное хранилище для обеспечения управляемого доступа к хранилищам данных.
Хранение на сервере. Серверные приложения могут использовать изолированные хранилища для представления отдельных хранилищ большому числу пользователей, обращающихся с запросами к приложению. Так как изолированное хранилище всегда выделяется пользователем, сервер должен выполнять роль пользователя, создающего запрос. В этом случае данные изолируются на основе идентификатора субъекта, который является тем же идентификатором, который используется приложением для того, чтобы различать пользователей.
Перемещение. Приложения могут также использовать изолированное хранилище с перемещаемыми профилями пользователей. Это позволяет изолированным данным пользователя перемещаться вслед за его профилем.
Изолированное хранилище не следует использовать в следующих ситуациях:
Для хранения важных конфиденциальных данных, таких как незашифрованные ключи или пароли, поскольку изолированное хранилище не защищено от высоконадежного кода, от неуправляемого кода и от доверенных пользователей компьютера.
Для хранения кода.
Для хранения параметров конфигурации и развертывания, которые контролируются администраторами. (настройки пользователя не считаются параметрами конфигурации, т.к. они не управляются администраторами).
Многие приложения используют базы данных для хранения и изолирования данных, в которых одна или несколько строк могут представлять хранилище для определенного пользователя. Применение изолированное хранилища вместо базы данных как правило выбирается в тех случаях, когда число пользователей невелико, когда использование базы данных влечет значительные потери производительности или когда отсутствуют средства для поддержания баз данных. Изолированное хранилище также представляет вполне реальную альтернативу в тех случаях, когда приложению требуется более гибкое и сложное хранилище, чем строка в базе данных.
Связанные статьи
Заголовок | Description |
---|---|
Типы изоляции | Описание различных типов изоляции. |
Практическое руководство. Получение хранилищ для изолированного хранения | Пример использования класса IsolatedStorageFile для получения хранилища, изолированного по пользователю и сборке. |
Практическое руководство. Перечисление хранилищ для изолированного хранилища | Пример использования метода IsolatedStorageFile.GetEnumerator для вычисления общего размера всех изолированных хранилищ пользователя. |
Практическое руководство. Удаление хранилищ из области изолированного хранения | Пример использования метода IsolatedStorageFile.Remove для удаления изолированных хранилищ двумя разными способами. |
Практическое руководство. Предупреждение о нехватке места при изолированном хранении | Пример измерения оставшегося свободного места в изолированном хранилище. |
Практическое руководство. Создание файлов и каталогов в изолированном хранилище | Ряд примеров создания файлов и каталогов в изолированном хранилище. |
Практическое руководство. Поиск существующих файлов и каталогов в изолированном хранилище | Пример считывания структуры каталогов и файлов в изолированном хранилище. |
Практическое руководство. Считывание из файлов и запись в файлы в изолированном хранилище | Содержит пример записи строки в файл изолированного хранилища и его чтения. |
Практическое руководство. Удаление файлов и каталогов из изолированного хранилища | Пример удаления файлов и каталогов в изолированном хранилище. |
Файловый и потоковый ввод-вывод | Описание способов выполнения синхронного и асинхронного доступа к файлам и доступа к данным потока. |