Как безопасно использовать обработчики URL и OpenURL в приложении Unity

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

Сегодня мы запускаем постоянную серию блогов о безопасной разработке с помощью Unity. В этой серии будет представлен контент, который разработчики Unity смогут применять непосредственно в своих играх и приложениях. Мы надеемся охватить широкий спектр тем, от базовых до продвинутых, уделив особое внимание передовому опыту использования продуктов и сервисов Unity . Если есть тема, о которой вы хотели бы почитать, дайте нам знать. Мы с нетерпением ждем ваших отзывов. Основное внимание в этом блоге уделяется обзору обработчиков URL-адресов.

URL-адреса и обработчики файлов связывают типы файлов с установленной программой, которая может открыть указанный файл, но это сопряжено с рисками. Например, когда вы находитесь на локальном компьютере и дважды щелкаете, чтобы открыть PDF-файл с локального диска, ваша операционная система обращается к своему списку обработчиков файлов и выбирает программу, назначенную для этого типа файла, поэтому ваш PDF-файл открывается программой, которая может правильно его отобразить. Обработчики файлов обычно используют расширение файла (например, .pdf — суффикс в конце имени файла), чтобы решить, как обрабатывать файл.

Похожий механизм, обработчик URL-адресов, решает, как открывать URL-адреса, на основе префикса пути. Примером этого может служить вездесущий протокол https://, который открывает ваш браузер по умолчанию. Другим примером распространенной схемы URL-адресов может быть file://c:/windows/system32/drivers/gmreadme.txt; ввод этого URL-адреса в диалоговом окне «Выполнить» заставит Windows открыть этот файл лицензии в Блокноте.

Обработчики URL-адресов — полезная функция операционной системы, которая экономит время пользователей при запуске приложений. Однако этот удобный механизм иногда может быть небезопасным.

Редактор Unity и среда выполнения Unity поддерживают программное использование обработчиков URL-адресов как посредством использования .NET Framework, так и посредством специального API сценариев Unity , а именно Application.OpenURL. Разработчики игр часто используют OpenUrl, чтобы при нажатии игроком ссылки в игре запускался веб-браузер локальной системы. Однако если разработчик игры не обеспечивает надлежащую очистку данных, передаваемых в Application.OpenURL, его игрок может оказаться под угрозой.

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

Ненадежные входные данные — это любые данные, которые не поступают из надежного источника. Итак, что же такое надежный источник? В контексте данной статьи доверенными следует считать только те конечные точки, на которых включен строгий протокол HTTPS .

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

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

Хотя эти обработчики очень удобны для пользователей, они несут в себе определенные риски. Вот пример небезопасного использования Application.OpenURL:

с использованием UnityEngine;
с использованием Collections;

открытый класс VulnerableBrowserClass: MonoBehaviour {
// Передайте URL-адрес из ссылки, по которой игрок кликнул на наших игровых форумах
void OpenBrowser(строка url_from_chat) {
Application.OpenURL(url_from_chat); // ←- Здесь что-то не так; значение не очищено
}
}

Рисунок 1. Пример небезопасного использования Application.OpenURL

В этом примере внутриигровая система комментирования позволяет пользователям делиться ссылками; когда пользователь нажимает на ссылку, вызывается функция VulnerableBrowserClass.OpenBrowser.

Рисунок 2. Пример сценария с потенциально опасной ссылкой

Вы видите, насколько легко отправить ничего не подозревающему пользователю ссылку на потенциально опасное приложение (рисунок 2). Если этот URL-адрес передается непосредственно в Application.OpenURL, как показано на рисунке 1, компьютер жертвы немедленно запустит приложение по этой ссылке, что потенциально позволяет злоумышленнику получить контроль над системой жертвы.

На изображении выше злоумышленник может отформатировать ссылку выше так, чтобы она отображалась в окне чата как https://SuperLeetCheats.com/VulnTheGame, но фактическая ссылка ведет на его вредоносное ПО по адресу: file://leethaxorz.net/super_malware.exe. Проблема здесь не в том, что пользователи могут отправлять друг другу ссылки; проблема заключается в том, что ссылки, отправленные пользователем (потенциальным злоумышленником), передаются напрямую в Application.OpenURL без какой-либо проверки или очистки, как показано в примере кода выше (рисунок 1). Без такой очистки нажатие на ссылку выше приведет к тому, что редактор Unity напрямую передаст файл в ОС целевого игрока, что, скорее всего, приведет к запуску вредоносного ПО злоумышленника.

Самый безопасный способ использования Application.OpenURL — никогда не использовать его с ненадежными данными. Используйте его только для открытия URL-адресов, поступающих от ваших разработчиков или серверов, и через доверенный транспорт (например, HTTPS).

Если вы используете удаленные конфигурации (например, размещаете список URL-адресов контента для новых обновлений), то убедитесь, что эти данные извлекаются только по протоколу HTTPS, со строгим соблюдением требований. Всегда извлекайте удаленный контент таким образом.

Примечание: HTTPS не устранит уязвимости в вашем приложении, вызванные ненадежными/непроверенными входными данными, как описано в атаке выше. Однако это гарантирует, что данные, которые вы отправляете на свой плеер, не будут подделаны во время передачи.

Если вы решили, что вам абсолютно необходимо использовать OpenUrl с данными из ненадежных источников, то вы должны сделать все возможное, чтобы очистить входные данные, которые вы получаете из ненадежного источника. Есть несколько способов сделать это, например, с помощью сопоставления шаблонов регулярных выражений, создания URL-адресов с помощью библиотек .Net или использования внешних библиотек очистки. Однако ни одно из этих мер не будет работать в 100% случаев, и независимо от того, какое решение вы выберете, существует некоторый потенциальный риск, если Application.OpenUrl (и аналогичные функции) используются с ненадежными данными.

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

Разработчики очень часто используют OpenURL и обработчики файлов, особенно в приложениях с богатым мультимедиа и функциях социальных сетей, таких как внутриигровой чат, обзоры и комментарии, где пользователи обычно хотят делиться контентом, который находится за пределами игры в Интернете. Кроме того, существуют распространенные сценарии повышения производительности, такие как редактирование файла конфигурации, где вам может потребоваться передать ссылку в ОС, открывающую предпочитаемое пользователем приложение для редактирования кода для удобства пользователя. Application.OpenURL — это платформенно-независимый API для поддержки обработчиков файлов, избавляющий разработчиков Unity от необходимости писать собственные обработчики для каждой платформы.

Нет. Как описано выше, это обычная функция в большинстве операционных систем, поддерживаемая многими языками и фреймворками. Будьте внимательны при использовании API Windows Windows.System.LauchURIAsync (для приложений универсальной платформы Windows [UWP]) или ужасного System.Diagnostics.Process.Start; обе эти собственные библиотеки .Net предоставляют ту же функциональность, что и Application.OpenURL. LaunchURIAsync позволяет запускать приложения из защищенной изолированной программной среды Windows, а Process.Start можно использовать для запуска любого исполняемого файла в локальной системе. Более того, некоторые собственные вызовы ОС предоставляют ту же функциональность, например , open(_:options:completionHandler:)от Apple. Все эти типы API могут быть легко использованы не по назначению, если в эти API будут передаваться непроверенные, непроверенные входные данные.

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

Есть ли тема безопасности, о которой вы хотели бы узнать больше в будущей статье? Напишите нам!

Узнайте больше о Unity Security, включая рекомендации по безопасности.