Поделиться через


Советы и рекомендации по разработке игр

В этой статье рассматриваются рекомендации по использованию в разработке игр.

Введение

Все больше людей играют в онлайн-игры и игры с пользовательским содержимым. Это, в сочетании с повышением безопасности операционной системы Microsoft Windows, означает, что игры являются растущей и более заманчивой целью для злоумышленников для использования. Разработчики игр должны уделять особое внимание тому, чтобы игры, которые они выпускали, не создают новые дыры безопасности для злоумышленников для использования. Разработчики игр несут ответственность и заинтересованы в том, чтобы помочь предотвратить взломать компьютеры своих клиентов вредоносными сетевыми данными, изменениями пользователей или изменениями пользователей. Если уязвимость эксплуатируется, это может привести к потере клиентов и (или) денег. В этой статье описываются и объясняются некоторые распространенные методы и инструменты для повышения безопасности кода без чрезмерного увеличения времени разработки.

Три наиболее распространенных ошибки, сделанные командой разработчиков при выпуске продукта:

  • Требование прав администратора. Игры не должны требовать прав администратора. Дополнительные сведения см. в разделе "Управление учетными записями пользователей для разработчиков игр".
  • Не используется автоматическая защита. Разработчики обычно не используют /GS, /SAFESEH или /NX. Использование этих флагов компиляции и связывания может обнаружить или исключить множество основных отверстий безопасности, не увеличивая рабочую нагрузку. Эти флаги рассматриваются далее в этой статье.
  • Использование запрещенных API. Существует множество API (strcpy, strncpy и т. д.), которые подвержены ошибкам программиста и легко создают дыры безопасности. Разработчики должны заменить эти API безопасными версиями. Visual Studio 2005 поставляется с средством анализа двоичных файлов, которые могут автоматически проверять файлы объектов для ссылок на небезопасные API. Дополнительные сведения о том, что делать с информацией, созданной с помощью этого средства, см. в статье "Отклонить атаки на код" с помощью библиотек Безопасного C и C++ Visual Studio 2005 по Мартину Лавллу. Кроме того, вы можете получить файл заголовка, который поможет удалить запрещенные banned.h функции из кода (см. раздел "Бесплатные средства безопасности Майкрософт" — запрещено.h).

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

Примеры небезопасного кода

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

void GetPlayerName(char *pDatafromNet)
{
    char playername[256]; 
    strncpy(playername, pDatafromNet, strlen(pDatafromNet));

    // ...
}

На поверхности этот код выглядит нормально— он вызывает безопасную функцию, в конце концов. Данные из сети копируются в буфер размером 256 байт. Функция strncpy использует поиск конца NULL в исходной строке или ограничен предоставленным числом буферов. Проблема заключается в том, что размер буфера неверный. Если данные из сети не проверены или размер буфера неправильный (как и в этом примере), злоумышленник может просто предоставить большой буфер для перезаписи данных стека, после окончания буфера с любыми данными в сетевом пакете. Это позволит злоумышленнику выполнить произвольный код, перезаписав указатель инструкции и изменив возвращаемый адрес. Самый простой урок этого примера заключается в том, чтобы никогда не доверять входным данным до тех пор, пока он не был проверен.

Даже если данные не приходят из сети изначально, по-прежнему существует потенциальный риск. Для разработки современных игр требуется множество людей, разрабатывающих и тестируя одну и ту же базу кода. В будущем не существует способа узнать, как будет вызываться функция. Всегда спрашивайте себя, откуда пришли данные, и что может контролировать злоумышленник? Хотя сетевые атаки являются наиболее распространенными, они не являются единственными методами создания отверстий безопасности. Может ли злоумышленник создать мод или изменить сохраненный файл таким образом, чтобы открыть отверстие безопасности? Что такое предоставленные пользователем изображения и звуковые файлы? Вредоносные версии этих файлов могут быть размещены в Интернете и создавать опасные риски безопасности для ваших клиентов.

В качестве боковой заметки используйте strsafe.h или Safe CRT вместо strncpy , чтобы исправить пример. Safe CRT — это полный ремонт системы безопасности среды выполнения C и входит в состав Visual Studio 2005. Дополнительные сведения о безопасной CRT можно найти в разделе "Улучшения безопасности" в CRT МайклОм Ховардом.

Способы повышения безопасности

Существует несколько способов повышения безопасности в цикле разработки. Ниже приведены некоторые из лучших способов:

Чтение о безопасности

Книга, написание защищенного кода, второй выпуск Майкла Говарда и Дэвида LeBlanc, предоставляет подробное и четкое объяснение стратегий и методов предотвращения атак и устранения эксплойтов. Начиная с методов разработки безопасности в выпуске методов защиты сетевых приложений, книга охватывает все аспекты, которые разработчик игры должен помочь защитить себя, свои продукты и своих клиентов от злоумышленников. Книгу можно использовать для создания культуры безопасности в студии разработки. Не просто думайте о безопасности кода как о проблеме разработчика или проблеме тестировщика. Думайте о безопасности как о том, что вся команда — от руководителя программы до дизайнера до разработчика до тестировщика — должна думать о том, когда они работают над проектом. Чем больше глаз, которые являются частью процесса обзора, тем больше шансов поймать отверстие безопасности до выпуска.

Написание защищенного кода, второй выпуск можно найти в Microsoft Press Store и более общие сведения о безопасности можно найти в Fending Off Future Attacks путем уменьшения поверхности атаки Майклом Ховардом.

Майкл Ховард, Дэвид LeBlanc и Джон Viega написали еще одну книгу по теме, которая охватывает все общие операционные системы и языки программирования, имеющие право, 19 Смертельных грехов программной безопасности.

Презентации безопасности, ориентированные на игры, можно найти на странице скачивания презентаций разработчиков Microsoft XNA.

Анализ моделирования угроз

Анализ моделирования угроз — это хороший способ оценки безопасности системы, а не на определенном языке или с помощью инструмента, но в широком комплексном методе, который можно выполнить в нескольких собраниях. При правильной реализации модель потоков может определить все сильные и слабые стороны системы, не добавляя значительный рабочий нагрузку или время собрания в проект. Метод моделирования угроз также подчеркивает идею оценки безопасности системы до и во время процесса разработки, чтобы помочь обеспечить комплексную оценку при фокусе на наиболее рискованных функциях. Его можно рассматривать как профилировщик безопасности. Не основываясь на определенном языке или опираясь на определенное средство, моделирование угроз можно использовать в любой студии разработки, работающей над любым проектом в любом жанре. Моделирование угроз также является отличным способом укрепления идеи о том, что безопасность является ответственностью всех, а не проблемой другого человека.

При моделировании угроз обратите особое внимание на:

  • Источники данных UDP
  • Источники данных, которые не требуют проверки подлинности
  • Источники данных, которые часто и обычно пробуются в рамках масштабируемого сбора информации
  • Любая возможность клиента напрямую отправлять данные другим клиентам

Это области, которые имеют хороший потенциал для слабых мест безопасности.

Дополнительные сведения об моделировании угроз можно найти в разделе "Моделирование угроз" и в книге "Моделирование угроз " Фрэнка Swiderski и Window Snyder.

Предотвращение выполнения данных (/NX)

Последнее средство для устранения нескольких эксплойтов — это предотвращение выполнения данных (DEP). Если включить параметр /NX в команду сборки, Visual Studio помечает страницы памяти флагами, которые указывают, имеет ли код право выполнить или нет. Любая программа, пытающаяся выполнить на странице памяти, не помеченной разрешением EXECUTE, приведет к принудительному прекращению программы. Предотвращение применяется на уровне процессора и повлияет на разработчиков, использующих самостоятельно изменяющий код или собственные компиляторы языка JIT. В настоящее время только процессоры Athlon64 и Opteron и Intel Itanium и последние процессоры Intel 4 поддерживают предотвращение выполнения, но ожидается, что все 32-разрядные и 64-разрядные процессоры будут поддерживать предотвращение выполнения в будущем. (Схема защиты копирования, используемая разработчиком, может повлиять на предотвращение выполнения, но корпорация Майкрософт работала с поставщиками защиты копирования, чтобы свести к минимуму влияние.) Рекомендуется использовать DEP.

Дополнительные сведения о DEP см. в разделе "Предотвращение выполнения данных".

Проверка безопасности буфера (/GS) и образ имеют безопасные обработчики исключений (/SAFESEH)

Проверка безопасности буфера, указанная флагом компилятора /GS, и образ содержит обработчики безопасных исключений, указанные флагом компоновщика /SAFESEH (впервые реализованной в Visual Studio .NET 2003), могут упростить работу разработчика по защите кода.

При использовании флага /GS компилятор создает проверку некоторых форм переполнения буфера на основе стека, которые можно использовать для перезаписи возвращаемого адреса функции. Использование /GS не будет обнаруживать все потенциальные переполнения буфера и не следует рассматривать как перехват всех, но хорошую технологию глубины обороны.

При использовании флага /SAFESEH компоновщик будет указывать компоновщику только создать исполняемый файл или библиотеку DLL, если он также может создать таблицу надежных обработчиков исключений исполняемого файла или библиотеки DLL. Безопасная обработка структурированных исключений (SafeSEH) устраняет обработку исключений в качестве целевого объекта атак переполнения буфера, гарантируя, что перед отправкой исключения обработчик исключений регистрируется в таблице функций, расположенной в файле изображения. Эти преимущества защиты включены в Windows XP с пакетом обновления 2 (SP2), Windows Server 2003, Windows Vista и Windows 7. Кроме того, для правильной работы /SAFESEH он должен использоваться в методе all-or-nothing. Все библиотеки, содержащие код, привязанный к исполняемому файлу или библиотеке DLL, должны быть скомпилированы с помощью /SAFESEH или таблица не будет создана.

Дополнительные сведения см. в разделе "Проверка безопасности буфера" (/GS) и образ с безопасными обработчиками исключений (/SAFESEH).

См. также сведения о флаге /SDL в Microsoft Visual Studio 2012 и улучшениях флага /GS в Visual Studio 2012.

PREfast

PREfast — это бесплатное средство, предлагаемое корпорацией Майкрософт, которое анализирует пути выполнения в скомпилированном C или C++ для поиска ошибок во время выполнения. PREfast работает путем работы со всеми путями выполнения во всех функциях и оценкой каждого пути для проблем. Первоначально используется для разработки драйверов и другого кода ядра, это средство может помочь разработчикам игр сэкономить время, устраняя некоторые ошибки, которые трудно найти или игнорируются компилятором. Использование PREfast является отличным способом снижения рабочей нагрузки и фокусировки усилий как команды разработчиков, так и тестовой команды. PREfast доступен в Visual Studio Team Suite и Visual Studio Team Edition для разработчиков программного обеспечения в качестве анализа кода, включенного параметром компилятора /analysis. (Этот параметр также доступен в бесплатной версии компилятора, который поставляется с пакетом средств разработки программного обеспечения Windows.)

Примечание.

Visual Studio 2012 поддерживает /анализ во всех выпусках. Дополнительные сведения о доступности анализа кода во всех выпусках Visual Studio см. в статье "Новые возможности анализа кода".

 

Используя заметку заголовка (особенно для аргументов указателя буфера), PREfast может предоставлять дополнительные проблемы, такие как ошибки перезаписи памяти, распространенный источник сбоев и потенциальных уязвимостей безопасности. Это делается с помощью стандартного языка заметки (SAL), который является формой разметки для прототипов функций C/C++, которые предоставляют дополнительные сведения о семантике аргумента указателя и корреляции с параметрами длины, объявленными размерами буфера и т. д. Все заголовки операционных систем Windows аннотируются и добавляют разметку SAL в общедоступные заголовки API в собственных библиотеках, что позволяет PREfast выполнять более подробные и агрессивные проверки в клиентском коде для таких API. Общие сведения о SAL и ссылки на дополнительные сведения см. в записи блога Майкла Ховарда "Краткое введение в стандартный язык заметки (SAL)".

Средство проверки приложений Windows

Средство проверки приложений Windows или AppVerifier может помочь тестировщикам, предоставляя несколько функций в одном средстве. AppVerifier — это средство, которое было разработано, чтобы сделать распространенные ошибки программирования более тестируемыми. AppVerifier может проверять параметры, передаваемые вызовам API, вводить ошибочные входные данные для проверки способности обработки ошибок, а также регистрировать изменения в реестре и файловой системе. AppVerifier также может обнаружить переполнение буфера в куче, проверить правильность определения списка контроль доступа (ACL) и обеспечить безопасное использование API сокетов. Хотя и не исчерпывающим, AppVerifier может быть одним из инструментов тестировщика, чтобы помочь студии разработки освободить качественный продукт.

Дополнительные сведения о средстве проверки приложений см. в разделе "Проверка приложений" и "Использование средства проверки приложений" в рамках жизненного цикла разработки программного обеспечения.

Нечеткое тестирование

Нечеткое тестирование — это полуавтоматизующий метод тестирования , который может улучшить текущие методики тестирования. Центральная идея за нечетким тестированием заключается в том, чтобы сделать полную оценку всех входных данных путем ввода случайных данных, чтобы увидеть, какие разрывы; сюда входят все сетевые данные, моды и сохраненные игры и т. д. Нечеткое тестирование довольно легко сделать. Просто изменяйте хорошо сформированные файлы или сетевые данные, вставляя случайные байты, переворачивая смежные байты или отрицая числовые значения. 0xff, 0xffff, 0xffffffff, 0x00, 0x0000, 0x00000000 и 0x80000000 — это значения, которые хорошо предоставляют дыры безопасности во время нечеткого тестирования. Вы можете наблюдать за результирующей комбинацией взаимодействия с помощью AppVerifier. Хотя нечеткое не является исчерпывающим, легко реализовать и автоматизировать, и он может поймать более неуловимые и непредсказуемые ошибки.

Дополнительные сведения о нечетком тестировании см. в презентации Gamefest 2007 практические шаги в игровой безопасности.

Подписывание Authenticode

Authenticode — это метод обеспечения того, чтобы исполняемые файлы, dll-файлы и пакеты установщика Windows (.msi файлы), полученные пользователем, не были освобождены от выпуска разработчика. Используя сочетание принципов шифрования, доверенных сущностей и отраслевых стандартов, Authenticode проверяет целостность исполняемого содержимого. Корпорация Майкрософт предоставляет криптографический API, CryptoAPI, который можно использовать для автоматического обнаружения изменения подписанного кода. Если после выпуска возникает утечка безопасности, сертификат может быть отозван и весь код, подписанный этим сертификатом, перестанет выполнять проверку подлинности. Отмена сертификата отменит проверку всех заголовков, подписанных этим сертификатом. Windows была разработана для работы с подписыванием Authenticode и оповещает пользователя о неподписанном коде в определенных ситуациях, которые могут предоставить компьютеру пользователя для атаки.

Authenticode не следует рассматривать как метод устранения проблем безопасности, но метод обнаружения изменения после выпуска исполняемого файла. Исполняемый файл или БИБЛИОТЕКА DLL, содержащий проблему безопасности с эксплойтами, может быть подписана и проверена с помощью Authenticode, но она по-прежнему введет проблему безопасности в новую систему. Только после проверки безопасности продукта или обновления следует подписать код, чтобы убедить пользователей, что у них есть выпуск, который не был изменен.

Даже если разработчик чувствует, что их выпуски не изменяются, другие технологии и службы полагаются на Authenticode. Подписывание кода легко интегрировать и автоматизировать; Разработчики не подписали свои выпуски.

Дополнительные сведения о подписи Authenticode см. в разделе "Подписывание Authenticode для разработчиков игр".

Минимизация привилегий

В целом процессы должны выполняться с минимальным набором привилегий, необходимых для работы. В Windows Vista и Windows 7 это достигается с помощью управления учетными записями пользователей, что позволяет игре работать как стандартный пользователь, а не администратор. Для Windows XP обычно игры выполняются от имени администратора. Даже в Windows Vista и Windows 7 иногда необходимо повысить права администратора для некоторых конкретных операций.

В тех случаях, когда процесс выполняется с полными правами администратора, обычно требуются только несколько прав, кроме стандартных пользователей. Административный доступ включает множество прав, которые не требуются законным кодом, но могут использоваться злоумышленником с помощью некоторых слабых мест в процессе. Примерами таких прав являются SE_TAKE_OWNERSHIP, SE_DEBUG, SE_CREATE_TOKEN, SE_ASSIGNPRIMARYTOKEN, SE_TCB, SE_SECURITY, SE_LOAD_DRIVER, SE_SYSTEMTIME, SE_BACKUP, SE_RESTORE, SE_SHUTDOWN и SE_AUDIT (см . константы Priviledge).

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

Использование функций Безопасность Windows

Windows Vista и Windows 7 включают ряд новых функций, которые повышают безопасность кода. Контроль учетных записей пользователей, безусловно, является самым важным, чтобы понять и принять, но есть и другие функции. Помимо технологий Windows XP с пакетом обновления 2 (SP2), таких как брандмауэр Windows, предотвращение выполнения данных, проверка безопасности буфера и обработчики безопасных исключений, которые также доступны в Windows Vista и Windows 7, существуют три новых функции безопасности, которые следует рассмотреть:

  • Функция случайной выборки макета адресного пространства. Это включено путем связывания с параметром /DYNAMICBASE в Visual Studio 2005 с пакетом обновления 1 или Visual Studio 2008. Это приводит к тому, что система случайным образом распределяет позиции многих ключевых системных библиотек DLL в пространстве обработки, что делает его гораздо сложнее писать программы атак, которые широко распространяются по всему Интернету. Этот флаг компоновщика игнорируется Windows XP и более ранними версиями Windows.
  • Повреждение кучи может привести ко всему классу эксплойтов безопасности, поэтому система памяти Windows Vista и Windows 7 теперь поддерживает режим, который завершает процесс при обнаружении повреждения кучи. Вызов HeapSetInformation с HeapEnableTermianteOnCorruption будет использовать это поведение. Этот вызов завершается ошибкой в Windows XP и более старой версии Windows.
  • При написании служб их можно настроить с помощью новой функции, чтобы указать, какие привилегии действительно необходимы, а также ограничить доступ к ресурсам определенному идентификатору безопасности. Это делается с помощью ChangeSeviceConfig2 с помощью SERVICE_CONFIG_REQUIRED_PRIVILEGES_INFO и SERVICE_CONFIG_SERVICE_SID_INFO.

Итоги

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

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