Рекомендации по обеспечению безопасности для создания приложений Магазина Windows
Одна из основных целей при создании платформы приложений для приложений Магазина Windows заключалась в следующем: пользователи должны быть уверены в своих приложениях. Мы хотим, чтобы пользователи были уверены, что их приложения будут работать ожидаемым образом, сосуществовать с другими приложениями и удаляться без проблем. Такая уверенность складывается из нескольких компонентов — от адаптации для Магазина Windows и простых процедур установки и удаления до согласия на использование веб-камеры и данных о местоположении пользователя. Важное значение также имеет использование комплекта сертификации приложений для Windows, позволяющего протестировать, удовлетворяет ли приложение критериям отправки в Магазин Windows. Уверенность пользователей не формируется благодаря какому-то одному компоненту, процессу или качеству. Она является результатом сочетания различных компонентов, формирующих у пользователя уверенность во всем процессе в целом. Мы подробно описали наш подход в записи блога, посвященной созданию надежных и заслуживающих доверия приложений.
А сейчас мы хотим подробнее поговорить о безопасных приложениях и о том, как сделать так, чтобы пользователи были уверены в вашем приложении. Современные приложения зачастую хранят важные сведения о пользователях, от финансовых данных до уникальных личных фотографий. Для многих пользователей такие данные жизненно важны, и они ожидают, что эта информация будет безопасно храниться в ваших приложениях. Даже в случае приложений, использующих минимальный объем данных, пользователи ожидают, что эти приложения будут работать должным образом и не будут мешать работе других приложений.
Реализация рекомендаций по безопасности в вашем приложении играет важную роль для формирования у пользователей чувства уверенности. Это также гарантирует, что со временем пользователи не разочаруются в вашем приложении. К счастью, общие рекомендации по обеспечению безопасности достаточно просты, и добавить средства обеспечения безопасности в приложение несложно. Кроме того, приложения выполняются в контексте уникального контейнера приложения, который помогает изолировать само приложение и его данные от других приложений. Контейнеры приложений предоставляют приложению выделенную среду, включая отдельное хранилище для данных и параметров.
Windows 8 и Visual Studio 2012 предоставляют набор API, элементов управления и инструментов для минимизации числа возможных уязвимостей в приложениях и смягчения распространенных проблем безопасности. Нет абсолютно совершенной платформы, но мы уверены, что сочетание элементов позволит вам создавать отличные приложения и что данная платформа будет и в дальнейшем улучшаться. В этой записи блога мы приведем различные советы и рекомендации по улучшению ваших приложений, чтобы вы могли предлагать своим клиентам более безопасные возможности.
Итак, давайте начнем.
Совет №1. Выполняйте компиляцию с использованием Visual Studio
Начиная с Windows 8, мы по умолчанию реализовали множество существующих рекомендаций по обеспечению безопасности. Вам ничего не нужно делать, просто скомпилируйте свое приложение с помощью Visual Studio 2012. При компиляции с использованием Visual Studio 2012 технологии обеспечения безопасности (/GS, ASLR, DEP и SeHOP), защищающие приложения от распространенных атак, по умолчанию реализуются для собственного кода вашего приложения.
Совет №2. Минимизируйте число возможностей вашего приложения
Каждое приложение может объявлять возможности, определяющие, как оно может взаимодействовать с разными ресурсами и устройствами. Важно задать минимальный набор возможностей, необходимых приложению, чтобы оно выполнялось с минимальными необходимыми привилегиями. Использование минимального набора возможностей делает ваше приложение менее уязвимым для атак.
Например, возможность Для домашних или рабочих сетей позволяетприложению получать доступ к компьютерам в локальной сети, например для игр в одноранговых сетях. Эта возможность может также быть полезна для тестирования перед выпуском с использованием локальной службы. Но обычно данная возможность не нужна и потенциально может быть использована для атак из ненадежной локальной сети, например через точку беспроводного доступа в кафе или аэропорту. Возможно, стоит убрать эту возможность и выполнять тестирование с использованием удаленного сервера, обладающего дополнительным преимуществом репликации реальных условий для вашего приложения. Если вы все же используете возможность Для домашних или рабочих сетей, не забудьте удалить ее перед отправкой приложения на сертификацию для Магазина.
Приложение с минимальным набором возможностей — только доступ к Интернету
Обратите внимание, что возможности Корпоративная аутентификация, Общие сертификаты пользователей и Библиотека документов предназначены для корпоративного доступа и внедренных документов (например, для открытия одного документа требуется открыть в нем другой документ), и для отправки приложения с этими возможностями в Магазин Windows необходима учетная запись компании. Эти возможности обычно не нужны для большинства приложений, но могут понадобиться для корпоративных приложений, которым необходим доступ к корпоративным ресурсам. В случае использования таких возможностей применяются повышенные ограничения, а также проводится дополнительная проверка специалистами Магазина Windows.
Совет №3. Используйте средство выбора файлов вместо возможностей библиотек
Следуя совету №2 о минимальном наборе возможностей, во многих случаях вы можете совсем удалить и возможности, связанные с файлами. Если вашему приложению требуется доступ только к небольшому числу файлов, разрешите пользователю выбирать файлы с помощью средства выбора файлов. Средство выбора файлов упрощает код приложения и позволяет пользователям обращаться именно к тем файлам, которые им нужны, для чего не требуются дополнительные возможности приложения. Поскольку средство выбора файлов одинаково работает во всех приложениях, пользователи сразу же ознакомятся с этим диалоговым окном при первом использовании вашего приложения и они смогут быстро вернуться в ваше приложения после выбора нужного файла.
Средство выбора файлов, в котором показана библиотека изображений
На JavaScript
var picker = new Windows.Storage.Pickers.FileOpenPicker(); openPicker.viewMode = Windows.Storage.Pickers.PickerViewMode.thumbnail; picker.fileTypeFilter.replaceAll([".png", ".jpg", ".jpeg"]); picker.suggestedStartLocation = Windows.Storage.Pickers.PickerLocationId.picturesLibrary;
На C#
using Windows.Storage; using Windows.Storage.Pickers; FileOpenPicker openPicker = new FileOpenPicker(); openPicker.ViewMode = PickerViewMode.Thumbnail; openPicker.SuggestedStartLocation = PickerLocationId.PicturesLibrary; openPicker.FileTypeFilter.Add(".png"); openPicker.FileTypeFilter.Add(".jpg"); openPicker.FileTypeFilter.Add(".jpeg");
Вот пример правильного использования возможностей: если ваше приложение позволяет пользователю выбрать изображение, следует использовать средство выбора файлов, а не возможность "Библиотека изображений". Если вашему приложению требуется полный программируемый доступ к библиотеке, например для музыкального проигрывателя, воспроизводящего файлы из музыкальной библиотеки, имеет смысл осуществлять доступ к ней с помощью данной возможности. Если вашему приложению необходим доступ к документам, всегда следует использовать средство выбора файлов.
Совет №4. Не доверяйте данным из удаленных источников
Для приложений, написанных на JavaScript, критически важно проверять и с осторожностью обрабатывать ненадежный веб-контент. HTML-страницы, входящие в состав приложения, обычно выполняются в локальном контексте приложения, что дает им доступ к среде выполнения Windows. Удаленные страницы, отображаемые внутри рамки IFrame, выполняются в веб-контексте приложения и не имеют доступа к среде выполнения Windows. Необходимо знать, кто вызывает среду выполнения Windows из вашего приложения — в конце концов, вы же не хотите, чтобы неизвестный интернет-сайт управлял вашим приложением, не так ли? (Ответ: да, это плохая идея.) Избегайте в своем приложении вызова API-интерфейсов, исполняющих такой скрипт, как eval(), setTimeout() и setInterval(), если вы не уверены, что источником входных данных для этого API является пакет вашего приложения. Если вам требуется использовать эти API, помните о том, что они могут выполнять скрипт, и поэтому вы должны точно знать, как этот скрипт сконструирован, если передаете данные этим API.
Если вы работаете с данными JSON, используйте JSON.parse вместо eval(), что гораздо безопаснее и не подвергает ваше приложение риску внедрения сценария.
На JavaScript
var jsontext = '{"firstname":"Aaren","surname":"Ekelund"}'; var contact = JSON.parse(jsontext); console.log(contact.surname + ", " + contact.firstname); // Output: Ekelund, Aaren
И наконец, неизвестный веб-контент, используемый в приложении, также должен быть "дезинфицирован", чтобы удалить используемый контент. Для этого используется innerText или toStaticHTML. Этот процесс "дезинфекции" удаляет или отключает скрипт для отображения веб-контента в вашем приложении.
На JavaScript
div.innerHTML = window.toStaticHTML(data); div.innerText = data;
Эти функции помогают гарантировать невозможность запуска в вашем приложении любого ненадежного скрипта или опасного контента. В первом случае скрипт будет удален, а во втором — преобразован в неисполняемый текст. Хотя большинство приложений будут обращаться к удаленному веб-контенту через поля ввода внутри приложения и традиционные API, такие как объект XMLHttpRequest, не забывайте, что веб-контент может проникать и через другие каналы, например через чудо-кнопку "Поделиться".
Совет №5. Не допускайте веб-доступ к WinRT
По умолчанию Windows 8 разрешает получать доступ к среде выполнения Windows (WinRT) только контенту из вашего пакета приложения. Если ваше приложение принимает входные данные из Интернета, не позволяйте этим данным управлять использованием каких-либо API-интерфейсов WinRT. Ваши клиенты должны быть уверены, что приложение работает должным образом. Они рассчитывают, что вы не оправдаете их доверие. Если вы работаете с веб-сайтом, рекомендуется отображать его в изолированных рамках iframe. Это позволяет предотвратить запуск скрипта, отправки формы, а также выполнения другого контента в вашем приложении.
Если ваше приложение исполняет контент из Интернета, этот контент может получать доступ к параметрам и данным вашего приложения или файлам, доступным вашему приложению. Это имеет критическое значение для приложений, написанных на JavaScript, где гораздо проще запустить скрипт на ходу. Например, если у вас есть приложение, написанное на JavaScript и использующее postMessage для передачи данных API-интерфейсу WinRT или упакованному коду, не забудьте проверить источник этих данных, чтобы гарантировать, что они получены из источника, которому вы доверяете.
На JavaScript
window.attachEvent('onmessage',function(e) { if (e.origin == 'https://www.contoso.com/') { … } });
Для получения дополнительной информации о добавлении веб-контента в приложение, написанное на JavaScript, ознакомьтесь с примером приложения для интеграции контента и элементов управления из веб-служб.
Совет №6. Получите доказательства: проверяйте подлинность вашего приложения и пользователей
Облачные приложения, в которых часть приложения обращается в службам, расположенным в облаке, очень эффективны. Однако они должны проявлять осторожность и выполнять проверку подлинности с использованием облачных служб, чтобы предотвратить возможные нарушения. Облачные службы, принимающие вводимые пользователем данные, всегда должны проверять подлинность как пользователей, так и приложений. Проверяя подлинность приложения и пользователя с помощью надежной облачной службы, вы знаете, что некто использует вашу службу законным образом и с помощью именно того приложения, которое вы и предполагали. Дополнительное преимущество знания личности пользователя заключается в том, что в случае злонамеренных действий вы можете легко определить и удалить весь контент, размещенный этим пользователем.
Вы можете проверять подлинность приложения с помощью GetAppReceiptAsync, чтобы убедиться, что приложение было получено из Магазина и имеет допустимый чек Магазина. Если у вас есть внутренний сервер, вы можете выполнять дальнейшую проверку подлинности с использованием этого чека, чтобы подтвердить общий сертификат для подписи чека путем подключения к следующему URL-адресу, где <CertificateId> — это CertificateId , предоставляемый вместе с чеком.
https://go.microsoft.com/fwlink/p/?LinkId=246509&cid=<CertificateId>
WinRT предоставляет облачной службе ряд удобных способов для проверки клиентскими приложениями подлинности пользователя, включая посредник веб-проверки подлинности (для проверки подлинности в стиле OAuth), хранилище учетных данных (для хранения паролей и небольших зашифрованных значений), а также общие хранилища сертификатов (для проверки подлинности сертификатов клиента). Все эти возможности позволяют сформировать у пользователей уверенность в способах выполнения проверки подлинности и обработки их учетных данных.
Совет №7. Проверяйте файлы, протоколы и импортированные данные
Многие приложения создают и загружают файлы, разрешают активацию через протокол или предоставляют средства для импорта данных. Как и удаленный веб-контент, описанный выше, эти данные могут быть неверно сформированы или же предоставляться из ненадежных источников. Поэтому их следует рассматривать как ненадежные. Приложения, открывающие файлы, импортирующие данные или принимающие общий контент, должны действовать с осторожностью и проверять этот контент, прежде чем использовать его в работе.
Проверка зависит от типа вводимых данных и особенностей их использования в приложении, поэтому она может быть как простой, так и достаточно сложной. Например, вводимые данные, используемые запросом базы данных, должны проверяться, чтобы предотвратить атаку путем внедрения кода SQL, поскольку базы данных обычно выполняют все получаемые ими допустимые запросы и могут раскрывать, изменять или даже удалять данные в случае ввода вредоносного контента.
Файлы, протоколы, импортированные данные и общий контент могут включать ненадежный контент, не соответствующий данным, которые ожидалось получить для приложения. Файлы и протоколы являются наиболее распространенной формой ненадежного ввода. Однако следует проявлять осторожность и в отношении содержимого буфера обмена, а также контента, принимаемого из чудо-кнопки "Поделиться", так как пользователи могут занести ненадежный контент из веб-браузера, даже не подозревая об этом. В приложениях, работающих с конфиденциальными данными, например в приложениях, предназначенных для ведения личных финансов, необходимо проявлять предельную осторожность по отношению к ненадежному контенту, поскольку эти приложения имеют доступ к информации, которая представляет для пользователей максимальную ценность.
Совет №8. Используйте HTTPS-соединения
Если есть сомнения, применяйте шифрование. HTTPS-соединения предоставляют проверку подлинности для удаленного сервера. Настоятельно рекомендуем использовать их для смягчения последствий атак типа "злоумышленник в середине". Атаки такого рода не представляют особой проблемы при работе в домашней сети. Однако за ее пределами по-прежнему имеется большое число беспроводных сетей, не использующих шифрование, где стандартные подключения HTTP не являются безопасными.
Для использования стандартного HTTPS-соединения требуется, чтобы удаленный веб-сайт имел сертификат, предоставленный центром сертификации, а также был настроен таким образом, чтобы разрешалось подключение HTTP. Начиная с Windows 8, приложение может применять преимущества SSL-соединений, используя самозаверяющий сертификат для выполнения безопасной проверки подлинности для внутреннего сервера. Это означает, что вы можете использовать безопасное HTTPS-соединение, даже не имея сертификата, предоставленного центром сертификации. Если вы не стали использовать HTTPS, желая снизить затраты на разработку, это не может служить оправданием для поставки приложения, передающего данные по небезопасным подключениям HTTP.
Чтобы использовать самозаверяющий сертификат, можно просто добавить объявление сертификата в ваше приложение с помощью конструктора манифестов в Visual Studio 2012 или же непосредственно в XML-текст манифеста приложения. Необходимо также настроить ваш внутренний сервер на использование этого же сертификата; для служб IIS имеется простой процесс создания и настройки веб-сайта. Ваше приложение затем автоматически использует этот упакованный сертификат для проверки подлинности подключения к вашему веб-серверу.
Наконец, если ваше приложение написано на JavaScript, вы также можете затребовать HTTPS-соединения, используя следующий метатег в своем приложении:
<meta name="ms-https-connections-only" content="true"/>
Формирование уверенности
Мы надеемся, что вам нравится Windows 8 и вы создаете отличные приложения, которые мы вскоре увидим в Магазине Windows. Советы и рекомендации, которые мы обсуждали выше, являются важным элементом создания более безопасной среды для пользователей, чтобы они были уверены в том, что их приложения будут вести себя именно так, как ожидается. Безопасность является ожидаемым качеством для всех приложений — начиная с защиты игровых рейтингов, достигнутых с таким трудом, до секретных финансовых данных.
Windows 8 и приложения Магазина Windows разработаны так, чтобы пользователи могли чувствовать себя уверенно, пробуя и покупая эти приложения. Мы добились этого благодаря коллективным инвестициям в создание платформы приложений. Мы уверены, что платформа приложений позволяет вам создавать надежные приложения, которые понравятся людям.
Если вы хотите больше узнать о безопасности приложений, ознакомьтесь с техническим документом Разработка безопасных приложений, воспользуйтесь Начальным набором для жизненного цикла разработки безопасного ПО и просмотрите новейшую информацию в Центре разработки безопасного ПО.
Спасибо за внимание!
-- Скотт Грэхэм (Scott Graham), старший руководитель программы, Windows
-- Криспин Коуэн (Crispin Cowan), старший руководитель программы, Windows
-- Дэвид Росс (David Ross), ведущий инженер по программным средствам обеспечения безопасности, Trustworthy Computing Security