Руководство по безопасности

В данном руководстве приведены лучшие практики безопасности, которые следует учитывать при разработке приложения Cordova. Пожалуйста, имейте в виду, что безопасность — очень сложная тема, и поэтому это руководство не является исчерпывающим. Если вы считаете, что можете внести вклад в это руководство, пожалуйста, подайте вопрос в систему отслеживания ошибок Cordova по адресу "Документация". Данное руководство предназначено для применения к общей разработке Cordova (все платформы), но будут указаны особые платформенные соображения.

В данном руководстве рассматриваются следующие темы:

Белый список
IFrame и механизм идентификатора обратного вызова
Фиксация сертификата
Самозаверяющие сертификаты
Зашифрованное хранилище
Общие рекомендации
Рекомендованные статьи и другие ресурсы

Белый список

Прочитайте и изучите Руководство по белому списку
Белый список доменов не работает на Android API 10 и ниже, а также на WP8 для iframe и XMLHttpRequest. Это означает, что злоумышленник может загрузить любой домен в iframe, а любой скрипт на этой странице внутри iframe может напрямую получить доступ к объектам Cordova JavaScript и соответствующим объектам Java. Это следует учитывать при разработке приложений для этих платформ. На практике это означает, что необходимо использовать Android API версии выше 10 и, по возможности, не использовать iframe для загрузки внешнего контента — используйте плагин InAppBrowser или другие сторонние плагины.

IFrame и механизм идентификатора обратного вызова

Если контент отображается в iframe с домена из белого списка, этот домен получит доступ к нативному мосту Cordova. Это означает, что если вы включите в белый список стороннюю рекламную сеть и будете отображать эти объявления через iframe, то потенциально вредоносное объявление сможет выйти за пределы iframe и выполнить вредоносные действия. По этой причине в общем случае не следует использовать iframe, если вы не контролируете сервер, на котором размещается содержимое iframe. Также обратите внимание, что существуют сторонние плагины, поддерживающие рекламные сети. Обратите внимание, что это утверждение неверно для iOS, которая перехватывает все, включая соединения iframe.

Фиксация сертификата

Cordova не поддерживает истинную фиксацию сертификата. Основным препятствием является отсутствие нативных API в Android для перехвата SSL-соединений и проверки сертификата сервера. (Хотя фиксацию сертификата на Android можно выполнить на Java с помощью JSSE, веб-вью Android написан на C++, а соединения с сервером обрабатываются веб-вью, поэтому использование Java и JSSE там невозможно.) Поскольку Apache Cordova призван предоставлять согласованные API на нескольких платформах, отсутствие этой возможности на одной из основных платформ нарушает это согласование.

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

Также есть плагины, которые могут выполнить истинную фиксацию сертификатов для некоторых платформ, при условии, что ваше приложение может выполнить все сетевые запросы с помощью плагина (т.е.: без традиционных запросов XHR/AJAX и т.п.).

Самозаверяющие сертификаты

Использование самозаверяющих сертификатов на вашем сервере не рекомендуется. Если вам требуется SSL, настоятельно рекомендуется, чтобы ваш сервер имел сертификат, правильно подписанный известным центром сертификации (ЦС). Это важно из-за отсутствия истинной фиксации сертификатов.

Причина в том, что принятие самозаверяющих сертификатов обходит проверку цепочки сертификатов, что позволяет считать действительным любой сертификат сервера. Это открывает канал для атак «человек посередине». Злоумышленнику становится очень легко не только перехватить и прочитать всю коммуникацию между устройством и сервером, но и изменить эту коммуникацию. Устройство никогда не узнает об этом, потому что не проверяет, подписан ли сертификат сервера доверенным ЦС. У устройства нет доказательств того, что сервер является тем, за кого себя выдает. Из-за легкости атак «человек посередине» принятие самозаверяющих сертификатов лишь немного лучше, чем просто использование http вместо https в ненадежной сети. Да, трафик будет зашифрован, но он может быть зашифрован с ключом злоумышленника, поэтому злоумышленник может получить доступ ко всему. Таким образом, шифрование бесполезно, кроме как для пассивных наблюдателей. Пользователи доверяют SSL, как надежному протоколу, а это намеренно делает его небезопасным, что вводит в заблуждение. Если это будет использоваться в доверенной сети (например, вы полностью находитесь внутри контролируемой корпоративной сети), самозаверяющие сертификаты по-прежнему не рекомендуются. В доверенной сети двумя вариантами являются просто использование http, так как сама сеть является доверенной, или получение сертификата, подписанного доверенным ЦС (не самозаверяющего). Либо сеть доверенная, либо нет.

Приведенные здесь принципы не относятся к Apache Cordova, они применимы ко всей клиентской коммуникации с сервером.

При запуске Cordova на Android использование android:debuggable="true" в манифесте приложения позволит разрешить ошибки SSL, такие как ошибки проверки цепочки сертификатов при использовании самозаверяющих сертификатов. Таким образом, вы можете использовать самозаверяющие сертификаты в этой конфигурации, но эта конфигурация не должна использоваться в производственных приложениях. Она предназначена только для разработки приложений.

Зашифрованное хранилище

(В разработке)

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

Не используйте Android Gingerbread!

Установите минимальный уровень target-sdk выше 10. API 10 — это Gingerbread, и Gingerbread больше не поддерживается Google или производителями устройств, поэтому команда Cordova не рекомендует его.
Gingerbread показал себя небезопасным и одним из наиболее атакуемых мобильных ОС http://www.mobilemag.com/2012/11/06/andriod-2-3-gingerbread-security/.
Белый список на Android не работает с Gingerbread или более ранними версиями. Это означает, что злоумышленник может загрузить вредоносный код в iframe, который затем получит доступ ко всем API Cordova и сможет использовать этот доступ для кражи личных данных, отправки SMS-сообщений на платные номера и выполнения других вредоносных действий.

Используйте InAppBrowser для внешних ссылок

Используйте InAppBrowser при открытии ссылок на любые внешние веб-сайты. Это намного безопаснее, чем включение домена в белый список и непосредственное включение контента в ваше приложение, поскольку InAppBrowser будет использовать функции безопасности родного браузера и не предоставит веб-сайту доступ к вашей среде Cordova. Даже если вы доверяете стороннему веб-сайту и включаете его непосредственно в свое приложение, этот сторонний веб-сайт может ссылаться на вредоносный веб-контент.

Проверяйте все входные данные пользователя

Всегда проверяйте все входные данные, которые ваше приложение принимает. Это относится к логинам, паролям, датам, загружаемому медиаконтенту и т.д. Поскольку злоумышленник может манипулировать вашими HTML и JS ресурсами (либо путем декомпиляции вашего приложения, либо с помощью инструментов отладки, таких как chrome://inspect), эта проверка также должна выполняться на сервере, особенно перед передачей данных любому backend-сервису.
Другие источники, где необходимо проверять данные: пользовательские документы, контакты, push-уведомления

Не кэшируйте конфиденциальные данные

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

Не используйте eval(), если вы не понимаете, что делаете

Функция JavaScript eval() имеет долгую историю злоупотреблений. Неправильное её использование может открыть ваш код для атак с использованием внедрения кода, проблем с отладкой и снижения производительности кода.

Не предполагайте, что ваш исходный код безопасен

Поскольку приложение Cordova построено из HTML и JavaScript ресурсов, которые упаковываются в нативный контейнер, не следует считать свой код безопасным. Возможно обратное проектирование приложения Cordova.