Чигилейчик_Диплом

1
Оглавление
Оглавление .......................................................................................................................................... 2
1. Введение.......................................................................................................................................... 3
2. Операционная система Android .................................................................................................... 4
2.1 Уровень Linux .......................................................................................................................... 4
2.2 Уровень инфраструктуры приложения.................................................................................. 5
2.3 Архитектурные стили и шаблоны.......................................................................................... 7
2.4 Архитектура Android-приложения ......................................................................................... 8
2.4.1 Java-классы ....................................................................................................................... 8
2.4.2 Файл манифеста ............................................................................................................. 10
2.4.3 Файлы ............................................................................................................................. 11
3. Эволюция защиты программного обеспечения ........................................................................ 12
4. Разработка приложения ............................................................................................................... 16
4.1 Историко-экономическое обоснование ............................................................................... 16
4.2 Описание приложения. ......................................................................................................... 18
4.3 Модель угроз и анализ рисков.............................................................................................. 20
4.3.1 Определение области применения ............................................................................... 20
4.3.2 Модель угроз .................................................................................................................. 20
4.3.2 Нарушители .................................................................................................................... 23
4.3.3 Анализ рисков ................................................................................................................ 23
4.3.4 Последствия реализации уроз ...................................................................................... 25
4.4 Защита приложения............................................................................................................... 25
4.4.1 Защита клиента приложения. ....................................................................................... 25
4.4.2 Защита сервера приложений......................................................................................... 29
4.4.3 Защита базы данных ...................................................................................................... 33
2
5. Заключение ................................................................................................................................... 35
6. Список ресурсов ........................................................................................................................... 36
3
1. Введение
В последнее время с невероятной скоростью развивается рынок
мобильных приложений. Не последнюю роль в этом сыграло появление
операционной системы от компании Google — Android. С каждым днем
появляются десятки приложений для этой платформы.
Каждый разработчик заинтересован в том, чтоб его приложение
приносило доход в том числе и после непосредственной покупки самого
приложения. Сначала широко использовалась система дополнений. С
распространением сервиса интернет-услуг, позволила свести намного
увеличить прибыль от приложения и дополнительных модулей, сводя затраты
на распространение к минимуму.
Однако, всегда остро стоял вопрос о защите ресурсов приложения и его
отдельных частей от незаконного копирования. Помимо отдельных
дополнительных частей, разработчики стали часто включать дополнительное
содержимое, которое должно быть доступным только после оплаты,
непосредственно в само приложение[10]. Связи с этим, к вопросу о защите от
распространения прибавилась проблема защиты от несанкционированного
доступа к защищенным ресурсам.
Поэтому, проблема о защите приложения является чрезвычайно
актуальной. К тому же, с развитием технологий, появляются все новые угрозы.
Цель: разработать и защитить приложение с интегрированными
дополнительными модулями.
Задачи:
1. Рассмотреть структуру операционной системы Android
2. Разобрать структуру приложения для операционной системы Android
3. Рассмотреть известные способы защиты приложений
4. Составить модель угроз
5. Разработать приложение с учетом выявленных рисков
4
2. Операционная система Android
Android (Андроид) — операционная система для планшетных
компьютеров,
коммуникаторов,
мобильных
телефонов,
цифровых
проигрывателей и других устройств, основанная на ядре Linux. Изначально
система разрабатывалась компанией Android Inc, которую вскоре купила
компания Google[11]. Сейчас поддержкой и дальнейшим развитием системы
занимается альянс Open Handset Alliance (OHA), создание которого
инициировала компания Google.[12] Android позволяет создавать Javaприложения, управляющие устройством через библиотеки, разработанные
Google. Так же, с помощью Android Native Development Kit (NDK) можно
создавать приложения на других языках, например — Си.[28]
Android является преобладающей системой на рынке коммуникаторов —
в третьем квартале 2012 года на 75% смартфонов была установлена эта
операционная система[9].
В основе системы, как уже было сказано ранее, лежит ядро Linux.
Над уровнем Linux находится уровень инфраструктуры приложения,
содержащий жизненно важные компоненты системы, такие как базу данных
SQLite, виртуальную машину Dalvik, Java API и некоторые инфраструктурные
части.
Последним, третьим уровнем является уровень Android-приложений,
написанных в Google.[13] Говоря обобщенно, эти приложения являются
расширением уровня инфраструктуры, так как эти приложения могут
использоваться при разработке собственных приложений.
Рассмотрим эти слои более подробно.
2.1 Уровень Linux
При разработке системы (как и какого либо приложения) существует два
способа: начать абсолютно с нуля или же использовать уже существующую
операционную систему, адаптировав под свои цели (как, например, создалась и
развивается система Linux).
В подобной ситуации компания Apple решила создать свою систему Mac
OS на основе Free BSD.[14] Компания Android Inc. как основу для своей системы
Android решила использовать Linux. Исходники этих систем (как Linux, так и
Free BSD) находятся в свободном доступе, и представляют хорошую основу для
разработок.
Сейчас на мобильном устройстве без особых проблем можно запустить
стандартный Linux. Но на время начала разработки Android это было не так.
Процессоры портативных устройств были на порядок медленнее
компьютерных, энергонезависимой и оперативной памяти было слишком мало.
5
Таким образом, разработчики Android решили минимизировать системные
требования Linux.
На высоком уровне, Linux является комбинацией ядра (без которого
обойтись невозможно) и множества различных не обязательных частей. Даже
можно запустить только одно ядро, без каких бы то ни было дополнительных
частей. Так, ядро системы необходимо использовать как часть системы на ее
основе. Так же, разработчики Android пересмотрели дополнительными
компоненты. Среди них было выбрано лишь самое необходимое. В результате,
например, в систему были добавлены оболочка Ash и сетевой фаервол IPTables.
Занятно, что была выбрана именно Ash, а не Bash. Скорее всего, это решение
было основано на меньшей требовательности Ash к ресурсам.[15]
Кроме того, разработчикам пришлось модифицировать ядро Linux,
добавляя поддержку железа, которое (по большей части) не доступно на
компьютерах, но широко распространено в мобильных устройствах.
По сути, сборка Android не сильно отличается от процесса сборки Linux.
Выбор Linux в качестве основы для операционной системы оказал
огромное влияние на многие системы операционной системы Android.
2.2 Уровень инфраструктуры приложения
Хоть операционные системы Apple iOS и Android внешне достаточно
похожи, архитектурные решения на инфраструктурном уровне разнятся
значительно.[29]
Так, в качестве среды выполнения приложения и языка
программирования в Apple iOS используется Objective-C. Такое решение
выглядит довольно естественным для операционной системы, учитывая, что в
основе iOS лежит Free BSD. То есть, приложения iOS написаны на в некоторой
мере том же языке, что и стоящая за ним операционная система.
В этом смысле приложения Android сильно отличаются, ведь одни
написаны на Java, а это кардинально другая технология, нежели C++ (хоть Java
и унаследовала синтаксис).
Это архитектурное решение оказалось критически важным. Оно
поставило операционную систему Android в стороне от всех других систем для
мобильных устройств на основе Linux, представленных в настоящее время. Ни
у одной из них нет совместимости двоичного кода на уровне приложений.
Например, рассмотрим MeeGo. Эти система использует связку языка C++ и
фреймворка Qt.[16] Не смотря на то, что фреймворк является
кроссплатформенным, необходимость создавать множество сборок для
различных плаформ никуда не пропадает. Выбрав же Java, можно не заботиться
о создании бесконечных сборок для Android приложения.
Следующим шагом нужно было выбрать виртуальную Java машину
6
(JVM) для использования в операционной системе. Использовать стандартную
JVM из-за ограниченности в ресурсах весьма проблематично. Единственным
выходом оставалось использования виртуальной машины, разработанной для
мобильных устройств, Java ME JVM. Было принято решение разработки
собственной виртуальной машины. В результате появилась Dalvik VM.
Отличия Dalvik VM от других виртуальных Java-машин заключаются в
следующем: [13]
 Для хранения двоичных кодов, в отличии от стандартных Java-машин,
использующих форматы JAR и Pack200, Dalvik VM использует
специальный формат DEX. Согласно заявлению Google, бинарные файлы
в DEX формате меньше, чем JAR.
 Dalvik VM оптимизирована для одновременного выполнения нескольких
процессов.
 Вместо стековой архитектуры других виртуальных Java-машин, Dalvik
VM использует архитектуру, основанную на регистрах; это позволяет
увеличить скорость выполнения приложения и уменьшить размер
бинарного файла.
 Dalvik VM не использует байт-код стандартных JVM; у нее собственный
набор инструкций.
 При необходимости можно запустить несколько независимых друг от
друга приложений в одном процессе.
 Изначально, Dalvik VM не поддерживала JIT-копиляцию, из-за чего
сильно пострадала производительность. Однако, начиная с версии
Android 2.2 этот недочет был устранен и скорость выполнения часто
используемых приложений заметно возросла.
 Выполнение приложение может «естественным образом» охватывать
несколько процессов Dalvik VM; этом способствовало добавление
следующего:
◦ Для сериализации объектов был создан специальный механизм на
основе классов Parcel и Parcelable. Функционально, они служат для
выполнения тех же целей, что и Java Serializable. Однако благодаря
этим изменениям передаваемые данные имеют меньший объем и
терпимее относятся к версионным изменениям классов.
◦ Для выполнения межпроцессорных вызовов (Inter Process Calls, IPC),
разработан особый способ, на основе Android Interface Definition
Language (AIDL)
Помимо этого, разработчики Android пересмотрели стандартные пакеты
Java API. Некоторые из них были убраны за ненадобностью (так, например,
7
было удалено все, что имело отношение к swing), а так же добавили несколько
своих наработок (по большей части расположенных в пакете android).
Еще были добавлены некоторые свободно распространяемые пакеты с
открытым исходным кодом. В их число вошли HTTPClient с поддержкой
разделения HTTP/HTTPS на стороне клиента, а так же Bouncy Castle Crypto
API.
Кроме того в уровень инфраструктуры приложения Google решили
добавить веб-браузер. Этот браузер может использоваться для интегрирования в
свои приложения.
2.3 Архитектурные стили и шаблоны
В противовес наиболее часто встречающейся вольной архитектуре (freestyle), архитектура Android — фреймворк-ориентированная.
Не смотря на то, что такой подход сильно ограничивает свободу
разработчиков (приложение нельзя запустить вне фреймворка, а разработчка
сводится к расширению уже существующих в фреймворке классов или
реализации интерфейсов), это позволяет избавиться от большего количества
повторяющихся участков кода, а так же предписывает разработчикам следовать
строгим правила проектирования.
Хотя для Java уже существует достаточно большое количество
фреймворков, разработчики Android решили создать свой собственный. Скорее
всего, причиной этого была необходимость поддержки уникальной системы
управления памятью.
Если рассматривать классическую Java VM, то объекты остаются в
памяти до тех пор, пока до них не доберется сборщик мусора и не решит, что
объект не используется. А это случится только тогда, когда на этот объект нет
ни одной ссылки от еще «живых» объектов.
В Android все устроено иначе. Если пользовательский интерфейс не
отображается, то нельзя с уверенностью сказать, находится ли он все еще в
памяти устройства, не смотря на то, собирается ли приложение, использующее
этот интерфейс, использовать его в дальнейшем или нет. Если операционная
система считает, что свободной памяти достаточно, то объекты могут
оставаться в памяти, однако, как только система решит, что памяти осталось
слишком мало, сборщик мусора может в любой момент уничтожить эти
объекты. То же самое можно сказать и о процессах. Если процесс на момент
сборки мусора не отображает никакого графического интерфейса, то сборщик
может в любой момент избавиться от него (однако существует исключение —
сервисы).
Для управления памятью также в операционной системе присутствует
стек приложений. Текущий видимый интерфейс помещается на верхушку этого
8
стека, сдвигая все остальные. При нажатии кнопки «назад» текущий интерфейс
удаляется с верхушки и отображается следующий за ним интерфейс. В
документации этот стек называют «activity stack» (иногда его еще называют,
«back stack»).[28]
Таким образом, в плане обработки взаимодействий между интерфейсом
и логикой приложения Android следует архитектурному шаблону «Model-ViewViewModel» (MVVM). На настоящий момент такая архитектура считается
лучшей из существующих архитектур GUI-приложений.[17]
MVVM создавалась с целью разделения работы программиста и
дизайнера интерфеса. В классических случаях это не возможно, например при
работе с Java-Swing. Архитектура MVVM четко разграничивает
ответственность:
 интерфейс разрабатывается дизайнером с помощью технологий, в
достаточной степени естественных для такой работы (например,
использование XML)
 разработчик реализует
ViewModel компонента
логику
пользовательского
интерфейса
как
 функциональные связи реализуются через так называемые биндинги, по
своей сути являющимися правилами рода «при нажатии кнопки
"BUTTON" на интерфейсе, вызвать функцию onButtonClick() из
ViewModel»; Android использует биндинги определенные декларативным
путем, или же записанные в коде.
MVVM используется в многих современных технологиях в том или
ином виде: Oracle JavaFX, AJAX, Microsoft WPF, Microsoft Silverlight, Adobe
Flex.[18]
2.4 Архитектура Android-приложения
Рассматривая Android-приложения, можно выделить, что в общем случае
приложение состоит из:
 Java-классы, которые являются подклассами основных классов из Android
SDK или оставшихся классов из классической Java SDK
 файл манифеста приложения
 ресурсы (строки, изображения и т. д.)
 файлы
2.4.1 Java-классы
На диаграмме ниже представлены основные классы, с которыми
9
приходится иметь дело разработчику приложений для операционной системы
Android:
рис. 1 Иерархия основных классов Android
View – базовый класс для графических виджетов. Все элементы
интерфейса являются наследниками этого класса. Пользовательский интерфейс
определяется с использованием XML файлов слоев. Во время исполнения эти
файлы динамически транслируются (разработчики Android используют термин
inflate) в дерево соответствующих объектов.
Activity – класс, содержащий логику логику, лежащую за
пользовательским интерфейсом. Класс является компонентом ViewModel в
архитектурном шаблоне Model-View-ViewModel. Обычно, отношение между
классом\подклассом Activity и интерфейсом — один к одному.
Activity в течении своего жизненного цикла может находиться в одном
из следующих трех состояний:
 активно и выполняется — интерфейс пользователя отображается,
приложение считается выполняющимся
 приостановлено — пользовательский интерфейс не отображается, но все
10
еще доступен для фокуса, код не выполняется
 завершено — интерфейс пользователя не отображается, недоступен для
фокуса.
Код Activity выполняется только при условии, что отображается и имеет
фокус соответствующий этому экземпляру интерфейс. Как уже говорилось
ранее, когда Activity приостановлено, нет гарантии, что соответствующие
объекты находятся в памяти.[28]
ContentProvider – класс, являющийся по сути уровнем Model в
архитектуре View-Model-ViewModel. Технически же, этот класс является
оберткой над базой данных SQLite, с довольно необычным способом доступа на
основе URI. Однако, теоретически, разработчик может создать ContentProvider
на основе чего-либо другого.[28]
В случае, когда необходимо выполнять некоторые операции при не
отображаемом интерфейсе (или пользовательский интерфейс вообще
отсутствует), используется класс Service.
2.4.2 Файл манифеста
Файл манифеста Android-приложения — важная часть приложения для
операционной системы Android. Эта идея была взята из манифестов плагинов
для Eclipse IDE.
Файл манифеста представляет собой XML-файл и выполняет следующие
функции:
 определяет имя пакета приложения, который, напомним, является
уникальным идентификатором приложения
 описывает компоненты приложения — Activity, Service, BroadcastReciver,
ContentProvider; описываются имена классов, которые реализуют каждый
из компонентов, и их возможности; это позволяет системе знать, какие
компоненты при каких условиях могут быть запущены
 объявляет разрешения, необходимые приложению для доступа к
защищенным частям API, а так же для взаимодействия с различными
другими приложениями
 объявляет минимальный уровень Android API, необходимый для работы
приложения
 перечисляет библиотеки, с которыми работает приложение.
Ресурсы
11
Каждое современное приложение с графическим интерфейсом
использует различные ресурсы. Разумеется, приложения для операционной
системы Android не исключение. Разработчики Android выделили следующие
типы ресурсов:
 изображения
 XML-файлы меню
 XML-файлы слоев интерфейса
 текстовые строки
Способ связывания ресурсов и приложения довольно необычен.
Обычно, например в классической Java SE ресурсы идентифицируются
строками. Эти строки содержат, например, ID необходимой строки или путь к
графическому файлу. Однако, возникает проблема невозможности обнаружения
ошибок ссылок при трансляции кода.
Команда разработчиков Android нашла весьма экстравагантный способ
решения этой проблемы. При сборке приложения создается специальный класс
R (всего одна буква). Этот класс содержит множество static final указателей
ссылок на ресурсы. Каждая ошибка в ссылке на ресурс проявит себя в процессе
компиляции.
2.4.3 Файлы
В общем случае приложение для операционной системы Android
использует следующие типы файлов:
 файлы базы данных
 зекешированные файлы
 файлы Opaque Binary Blob
 файлы «общего назначения»
Разумеется, в итоге — это всего лишь обычные Linux-файлы. Выделять
их следует только в смысле обработки различными средствами API и
отдельного хранения.
12
3. Эволюция защиты программного обеспечения
Защита программного обеспечения образовалась с появлением первых
коммерческих программных продуктов. Под защитой программного
обеспечения понимают комплекс мер для защиты от несанкционированного: [1]
 использования,
 модифицирования,
 приобретения,
 распространения.
Одной из первых появилась проблема незаконного копирования
программного обеспечения. Она появилась еще задолго до появления
цифровых, аналоговых устройств воспроизведения. С популяризацией пианол
(механического пианино) компании-производители переводили нотные записи в
перфоленты, используемые пианолами без уплаты гонораров издателям и
композиторам. В результате, несмотря на требования последних, выпуск пианол
не был запрещен, однако производители перфолент были обязаны выплачивать
за каждую выпущенную запись определенные денежные отчисления авторам.[2]
С переходом в цифровую эру ситуация только усугубилась.
Рассматривая эпоху персональных компьютеров, одной из первых
попыток защиты от нелегального копирования было распространение
защищаемого продукта на т. н. ключевой дискете.
Метод заключался в создании особых меток на дискете. Существовало
следующие четыре способа их создания:
 Считывание конкретного сектора дискеты. Для доступа к данным
использовалась привязка к определенным секторам дискеты. При точной
копии дискеты («дорожка-в-дорожку») копия дискеты создавалась и была
работоспособна.
 Запоминание сбойных секторов дискеты. Перед записью информации на
дискета царапалась или прожигалась лазером. В этом случае, проверка
подлинности происходила попыткой записи в эти сектора какой-либо
информации и последующего считывания.
 Нестандартное форматирование дискеты.
 «Плавающий бит». Способ заключался в том, что один их битов
записывался так, что в некоторых случаях он считывался как «0», а в
некоторых как «1». Для проверки подлинности, проводилось
многократное считывание дискеты, и в результатах должны
присутствовать как нули так и единицы.
В
дальнейшем
был
разработан
способ
защиты
путем
записи
13
некопируемых меток на жестком диске. Например, известно, что при записи
одного байта, он будет занимать на диске один кластер (не менее 512 байт в
операционной системе DOS). Тем самым, в оставшиеся 511 байт можно
записать некоторые данные. Однако, из-за большого риска потери данных этот
способ практически не используется.
Помимо привязок к каким-либо цифровым данным, защищаемое
программное обеспечение могло привязываться к физическим объектам. Эта
практика какое-то время использовалась среди разработчиков игр например:
 Серия игр Space Quest и Metal Gear[19] содержала в руководстве важную
информацию, без которой пройти игру было невозможно. Однако, с
распространение копировальной техники, свело такую практику на нет.
 Игра Pool of Radiance[20] распространялась с «кодовым колесом». При
запуске игры требовалось ввести «перевод» одной из надписей, который
можно было прочесть с помощью этого колеса.
С появлением компакт-дисков, разработчики стали использовать их для
защиты своего программного обеспечения — программа может требовать
наличия оригинального компакт-диска в дисководе.[3] Почти всегда, этот способ
применяется для защиты программы, распространяемой на этом диске, которые
так же является ключевым.
Большая часть методов защиты перекочевала с дискет:
 проверка расположения и содержимого «битых» секторов диска
 проверка скорости чтения отдельных секторов
 проверка возможности записи на диск
 запись информации в неиспользуемых секторах.
Как правило используется комбинация этих методов, однако, благодаря
современным технологиям создания образов, копирования и эмуляции эти
средства защиты почти бесполезны. Возможно даже скрыть тип диска. Однако в
драйвер защиты такие как (StarForce, SecuROM и т. д.) может быть встроена
проверка на наличие в системе эмуляции.[4]
При развитии сетевых технологий и выхода программного обеспечения в
сеть появляются и новые способы проверки. Так, например, программа может
сканировать локальную сеть, исключая одновременный запуск двух
экземпляров защищаемого программного обеспечения. Увы, благодаря другим
средствам защиты — брандбауэр — можно сделать так, чтоб пакеты,
принадлежащие этой программе не пропускались в локальную сеть. Но, как бы
то ни было, настройка брандмауэра требует определенных навыков
пользователя. К тому же может ограничиваться функционал программного
обеспечения (как, например, возможность сетевой игры).
14
При работе с централизованным сервером, программа может передавать
свой серийный номер. При некорректном номере сервер отказывает в услуге.
Но и здесь есть свои недостатки — существует возможность создать свой
собственный сервер для приложения, но который такой проверки не делает. Так,
например, существовал сервер battle.da, аналогичный по функция серверу
battle.net компании Blizzard, но без проверки лицензионной информации.
Микротехнологии тоже не стоят на месте. С уменьшением размера плат
и их составляющих, размеры оборудования становятся все меньше, а их
возможности все больше. Это привело к созданию защиты с помощью
электронных ключей (донглов). Донгл содержит ключевые данные, которые и
составляют лицензионные данные. Защита основывается на том, что только
разработчику известен алгоритм работы ключа. Выделяют три типа ключевых
данных:[21]
 информация для чтения\записи (почти что не используется в данный
момент, так как после считывания ключ в достаточной степени легко
может быть сэмулирован)
 ключи аппаратных криптографических алгоритмов
 алгоритмы или созданные разработчиком программы
Преимущества защиты с помощью электронного ключа достаточно
очевидны:
 ключ может вставляться в любое оборудование, где необходимо
использовать программу
 ключ не требует наличия дисковода
 электронный ключ может выполнять криптографические преобразования
 электронный ключ может выполнять произвольный код, помещенный в
него разработчиком защиты
 ключевая информация защиты не покидает ключа в процессе работы с
ним
Но и здесь не обошлось без недостатков:
 донгл, обычно, приобретается отдельно и стоит 15-30 USD за штуку
 необходимо доставить донгл конечному пользователю.
Раньше, к недостаткам еще приписывали не достаточное высокое
быстродействие ключа (по сравнению с процессором компьютера). Но уже
современные ключи достигают скорости 1,25 DMIPS. К тому же техника
защиты не предполагает постоянный обмен ключом.
Так же устранена проблема с установкой ключа на определенные
аппаратные платформы. Но в настоящий момент эта проблема тоже решена —
15
при помощи сетевых технологий и аппаратных и программных средств
«проброса» USB-устройств по сети.
16
4. Разработка приложения
4.1 Историко-экономическое обоснование
Индустрия интерактивных развлечений входи в тройку самых крупных
индустрий по денежным оборотам. К примеру на разработку Heavy Rain было
затрачено 16,7 миллионов евро, дополнительно на дистрибуцию и
маркетинговую компанию фирмой Sony было потрачено 23,3 миллиона евро,
однако, чистая прибыль с продажи составила 100 миллионов евро.[6] В 2012
году продажи видеоигр составили 16.6 миллиарда долларов[5], а с учетом
околигровых продаж (оборудование, аксессуары и т. п.) цифа достигает отметки
в 24.75 миллиарда долларов[5]. В нынешнее время почти любой разработчик
может влиться в эту индустрию благодаря сервисам вроде Steam, Kickstarter.
Для разработчиков для операционной системы Android Google
предоставляет свой собственный сервис для распространения приложений
Google Play. К тому же, с помощью поощрений и партнерских программ,
компания обеспечила быстрое развитие рынка мобильных приложений. Таким
образом, Android не смотря на свой сравнительно юный возраст развивается
невероятно быстро. В ноябре 2012 года ежедневная выручка в Google play
составляет 3,5 миллиона долларов[7].
Сейчас это огромный бизнес, а следовательно, как и любое дело
нуждается в серьезной защите. А с каждым новым годом у разработчиков
появляются все новые идеи, которые добавляют новые уязвимости. На
сегодняшний день индустрия игровых развлечений является одной из самых
прогрессирующих и постоянно меняющейся сферой бизнеса так как в какой-то
мере включает в себя многие другие сферы, изменения которых мгновенно
отзываются на индустрии электронных развлечений.
В свое время, когда вычислительные возможности, и доступное дисковое
пространство были невероятно малы, графическое оформление могли
позволить себе далеко не все игры. Да и многие из них состояли из статических
элементов, и анимацией (если таковая вообще имелась), состоящей из двух трех
кадров. В эти уже далекие времена получили широкое распространение так
называемые интерактивные текстовые игры (Interactive fiction).
Сначала интерактивные текстовые игры представляли из себя простую
книгу с возможностью выбора действий.[23] После, они модифицировались в так
называемые «текстовые квесты», в которых нужно было вводя специальные
текстовые команды управлять персонажем. Каждое действие и место подробно
описывалось в меру таланта автора сценария игры.
Последней вехой развития интерактивных новелл на западном игровом
рынке стал жанр текстовых ролевых игр (CRPG). Эти программы так же
17
управлялись текстовыми командами, но здесь они использовались, помимо
перемещения персонажа, для боя в случайных или запланированных схватках с
противниками. Статистика боя, персонажа и противника выводилась в
текстовом виде.
Далее, в игры эти стали добавлять немного графики. Изображения
отображали места действия и персонажей. Начали появляться простые звуковые
эффекты и, иногда, фоновая музыка. Когда появилась возможность
интерактивного управления, перестали использовать текстовые команды. И со
временем эти игры перевоплотились в совершенно другие жанры (квесты,
ролевые игры и т. д.), а на западном рынке об этих играх совершенно забыли
(хотя и осталось не малое количество фанатов).
Вклад в индустрию развлечений этого жанра был крайне важен —
именно благодаря этому жанру многие начали видеть в виртуальных
развлечениях не бессмысленный способ «убивания времени», но и часть
культурного слоя человечества наравне с музыкой и литературными
произведениями.
Казалось, жанр пал жертвой прогресса. Но на родине компаний
Nintendo, Sega и Sony (тоже оказавших не маловажный вклад в развитие
игровой индустрии) этот жанр получил второе рождение.
Япония всегда славилась умением принимать и изменять под действием
своей культуры многие западные идеи. Так и жанр интерактивной текстовой
игры изменился почти до неузнаваемости.
В Японии на протяжении многого времени были распространены
произведения в формате ранобэ — рассказ (часто небольшого фомата),
снабженный небольшими иллюстрациями, зачастую от автора самого
произведения. За счет достаточно простой технологии разработки
интерактивных новелл, создать программу достаточно легко, а поскольку
графика намного продвинулась вперед, добавление качественных (по тем
временам) изображений места действия и персонажей давало совершенно
другой эффект. Так появился жанр визуальных новелл (visual novel).[24]
В Японии это жанр получил огромное распространение. Частично, из-за
того, что эти игры все еще оставались книгами со всем своим уже
существующим многообразием жанров, в которых авторы самовыражали себя,
экспериментировали, частично из-за того, что большая часть графики была в
невероятно популярном стиле аниме. Игры были в разной степени
разветвленными, использовали элементы ролевых игр и квестов, звуковые
эффекты и музыка становились все более сложными, стали добавлять озвучку
персонажей, но в основе оставались все тем же виртуальными книгами.
Эффект поучил обратное развитие — то, что сначала пришло в с запада
на восток, стало возвращаться обратно на запад. Жанр получил признание среди
18
многих игроков. Появилось несколько студий, занимающихся импортом и
переводом визуальных новелл (сначала на основе энтузиазма, а после — и в
качестве официального партнера).[25] Некоторые японские продукты,
импортируемые на западный рынок стали содержать элементы визуальной
новеллы, например недавняя серия файтингов BlazBlue. По состоянию на
ноябрь 2012 больше 85% (более 20 тыс. выпусков) указанных игр этого жанра
— на японском языке, ещё около 10% (более 2 тыс.) — переводы с японского (в
т.ч. больше 850 — на английский, больше 100 — на русский), около 5% (более 1
тыс.) — игры, созданные на других языках (в т.ч. больше 700 — на английском,
менее 50 — на русском)[8].
Так же популяризации визуальных новелл на западном рынке
способствует создание произведений в более популярном формате по этим
играм так, например, огромное признание получила серия “Higurashi no naku
Koro Ni” (“Когда плачут цикады”), серия игр “Tsukihime”, игры “Air”, “School
Days”, “Steins;Gate” “Clanad” и т. д. благодаря выпуску аниме-сериалов по этим
играм.
Однако, у Японии сильно центрированный рынок, большая часть
продукции не покидает территории страны, не говоря уже о заботах о переводе
программного обеспечения на другие языки, а также особенностях локали в
операционных системах этой страны. Тем самым, большая часть жанра
существует на западе благодаря стараниям фанатов, разрабатывающих патчи с
переводом. Тем не менее, такая ситуация оставляет нишу на западном рынке.
Жанр визуальной новеллы почти идеально подходит для портативных
устройств. На данный момент в официальном магазине Google Play существует
лишь несколько визуальных новелл на неяпонском языке, да и те созданные
фанатами жанра — Wintertale (русский, английский; разработчик — DreamTale,
Россия), и Moonlight Walks (английский; разработчик — PGS4A & Ren'Py
Projects).
Таким образом, можно сделать вывод, что визуальная новелла,
разработанная для операционной системы Android, будет иметь спрос и может
принести существенный доход.
Так же набирает обороты тенденция к созданию ремейков (пересоздание
старых игр на основе современных технологий) многих знаменитых игр. За
последние несколько лет уже вышли (Ico, Shadow of the Colossus, Black Mesa
(Half-life), Streets of Rage: Remake) и разрабатываются (Kingdom Hearts,
Shadowrun, Wasteland) многие проекты. Выпуск старой игры на новых
технологиях может поспособствовать успешному старту продукта.
4.2 Описание приложения.
Разработанное приложение является ремейком игры в жанре visual novel
“True Love”. Эта игра, разработанная студией CD BROS, вышла в 1995 году на
19
платформе PC-95. Она завоевала сравнительную известность на западном
рынке благодаря тому, что она была одной из первых игр жанра визуальных
новелл, переведенных на английский язык.
Игра разрабатывалась на языке программирования java с
использованием собственного скриптового языка на основе синтаксиса
скриптового языка Ren'Py (который в свою очередь основан на синтаксисе
языка Python).
Для распространения программного обеспечения была выбрана схема
свободного распространения с платными модулями. В приложении
присутствует электронный магазин для приобретения дополнительных модулей,
улучшающих исходную игру. Сложность такой схемы выбранной схемы
распространения состоит в том, что необходимо защитить платные модули от
несанкционированного доступа, в то время как доверенный пользователь мог
использовать доступный ему контент.
Опыт многочисленных компаний показал (например компания Blizzard),
что перенос приложения в онлайн намного повышает показатели
защищенности.
Таким образом, перенеся часть логики и контента приложения на сервер
мы защищаем часть логики приложения. Система реализовывалась по
стандарту Java EE 6 с использованием технологий Enterprise JavaBeans и JPA
2.0. В качестве сервера приложения был выбран сервер JBoss AS 7.1. База
данных для хранения пользовательских данных – PostgreSQL 9.2.
Схема классической трехзвенной реализации по стандарту Java EE 6 [27]
4.3 Модель угроз и анализ рисков
4.3.1 Определение области применения
Составление модели угроз является неотъемлемой частью комплексного
обеспечения безопасности системы.
Приложение разработано по трехзвенной архитектуре и состоит из:
 клиентское приложение
 сервер приложения JBoss Application Server 7.1
 сервер базы данных PostgreSQL 9.2
Клиентское приложение разработано для операционной системы
Android и находится на устройстве покупателя.
Сервер приложений служит для выполнения бизнес-логики для клиента
и находится под управлением операционной системы Fedora Linux 18.
20
Сервер базы данных служит для хранения данных клиентов находится
под управлением той же системы, что и сервер приложений.
4.3.2 Модель угроз
Модель угроз составлялась экспертной комиссией
разработчиков программного обеспечения. Экспертная комиссия:
из
числа
 Чигилейчик Дмитрий Сергеевич — ведущий разработчик, геймдизайнер,
администратор сервера приложений
 Соколов Артем Дмитриевич — художник
 Солина Дарья Анатольевна — администратор базы данных, разработчик
базы данных
Для оценки степени угроз решено было использовать следующую шкалу
оценки:
Оценка
Описание
0
Угроза отсутствует
1-2
Угроза является несущественной, можно пренебречь
3-4
Угроза не несет существенной опасности, но нуждается в
устранении
4-6
Угроза является существенной, необходимо устранить при первой
же возможности
7-8
Угроза является важной, устранить в кратчайшие сроки
9-10
Угроза является критической, приостановить все бизнес-процессы
до устранения
В ходе первого раунда составлен и оценен список угроз:
Оцениваемая
угроза
Чигилейчик Д. С. Соколов А. Д.
Солина Д. А.
Угрозы клиентского приложения
Взлом ресурсов
6
8
5
Копирование
скриптовых
команд
7
5
5
Модификация
пользовательских
данных
8
5
5
Модификация
7
6
5
21
исходных кодов
приложения
Авторские
претензии
6
8
4
Угрозы сервера приложений
Перехват трафика
8
5
6
Подключение к
API бизнес-логики
7
6
7
Подключение к
административной
консоли
управления
сервером
8
4
6
Захват
операционной
системы сервера
8
6
7
Угрозы сервера базы данных
Подключение к
серверу базы
данных
8
6
8
SQL-инъекции
7
5
8
Захват
операционной
системы
8
6
9
Для улучшения качества составления модели угроз был проведен второй
раунд оценки угроз:
Оцениваемая
угроза
Чигилейчик Д. С. Соколов А. Д.
Солина Д. А.
Угрозы клиентского приложения
Взлом ресурсов
7
8
8
Копирование
скриптовых
команд
7
7
7
Модификация
8
6
7
22
пользовательских
данных
Модификация
исходных кодов
приложения
7
7
6
Авторские
претензии
7
8
6
Угрозы сервера приложений
Перехват трафика
8
7
6
Подключение к
API бизнес-логики
7
6
7
Подключение к
административной
консоли
управления
сервером
8
5
7
Захват
операционной
системы сервера
8
7
7
Угрозы сервера базы данных
Подключение к
серверу базы
данных
8
6
8
SQL-инъекции
8
5
8
Захват
8
6
8
операционной
системы
Поскольку, на момент составления модели приложение находилось на
ранней стадии разработки, критически риски отсутствовали, однако большая
часть угроз отмечена как важные, большую часть которых необходимо было
устранить на этапе проектировки.
4.3.2 Нарушители
Составлен список нарушителей и их возможные мотивы,
представляющих потенциальную опасность:
 Конкурирующие организации и структуры — достижение денежной
выгоды
 Взломщики программных продуктов ИТ — хулиганство и любопытство,
23
профессиональное самоутверждение
 Нечестные пользователи — хулиганство и любопытство.
4.3.3 Анализ рисков
На момент составления модели угроз и анализа рисков приложение
находилось в ранней стадии разработки. Поэтому анализ рисков проводился на
основании вероятности использования неустраненной угрозы.
Для оценки риска использована следующая матрица риска: [30]
Качественная Частота Серьезность последствия
характеристи события Катастрофи Значительн Серьезное Незначител
ка
частоты в год
ческое
ое
ьное
события
Частое
>1
В
В
В
С
Вероятное
1—10-1
В
В
С
М
Случайное
10-1 — 10-2
В
В
М
М
Маловероятное 10-2 — 10-4
В
В
М
М
Неправдоподоб 10-4 — 10-6
ное
В
С
Н
Н
Невероятное
С
С
Н
Н
< 10-6
Классификация риска:
 В — высокая величина риска
 С — средняя величина риска
 М — малая величина риска
 Н — незначительная величина риска
Классификация серьезности последствий:
 Катастрофическое — практически полная потеря анализируемого объекта
 Значительное — крупный ущерб
 Серьезное — существенный ущерб системе
 Незначительное — незначительное повержение системе
Для оценки вероятности возникновения использовался статистический
метод. В результате анализа составлены следующие соотношения угроз и
рисков:
Оцениваемая угроза
Оценка риска
Угрозы клиентского приложения
Взлом ресурсов
Копирование скриптовых команд
Высокая
Серьезная
24
Модификация пользовательских
данных
Высокая
Модификация исходных кодов
приложения
Высокая
Авторские претензии
Серьезная
Угрозы сервера приложений
Перехват трафика
Серьезная
Подключение к API бизнеслогики
Малая
Подключение к
административной консоли
управления сервером
Высокая
Захват операционной системы
сервера
Высокая
Угрозы сервера базы данных
Подключение к серверу базы
данных
Высокая
SQL-инъекции
Высокая
Захват операционной системы
Высокая
4.3.4 Последствия реализации уроз
Последствия для конфиденциальности:
 Снижение имиджа
 Ответственность перед законом
 Финансовые потери




Последствия для целостности:
Прерывание коммерческих операций
Снижение имиджа
Финансовые потери
Ответственность перед законом
Последствия для доступности:
 Снижение имиджа
 Финансовые потери
 Прерывание коммерческих операций
25
4.4 Защита приложения
4.4.1 Защита клиента приложения.
Угрозы для клиента приложения:
 взлом ресурсов
 копирование скриптовых команд
 модификация пользовательских данных
 модификация исходных кодов приложения
 авторские претензии
В клиенте присутствуют следующие логические действия:
 загрузить изображение,
 воспроизвести звуковой файл,
 вывести текст,
 изменить характеристики персонажа.
Из-за сравнительно большого объема файлов графики и звукового
сопровождения хранение их на сервере является заведомо плохой идеей.
Потому, их необходимо включить в пакет с программой. Несмотря на то, доступ
в приложении к ним осуществляется только по команде с сервера, локальный
доступ к ним тоже необходимо ограничить.
Прежде всего, необходимо защищенная упаковка ресурсов с высокой
скоростью декомпрессии. Упаковка на основе уникального ключа значительно
усилит защищенность контента. Для этого защищаемый пакет генерируется на
сервере на основе сгенерированного уникального ключа для пользователя.
Ключ генерируется на основе уникальной информации пользователя —
используемого устройства, пользовательских данных и случайного секретного
числа, созданного при регистрации пользователя. Для шифрования ресурсов
используется алгоритм AES. Загрузка дополнительного контента приложения
осуществляется через сервер:
1. Приложение посылает запрос на загрузку пакета и техническую
информацию об устройстве.
2. На основе полученной информации, данных пользователя (к
которым относится случайно сгенерированное при регистрации пользователя
число) составляется ключ.
3.
Пакет для отправки шифруется ключом и передается пользователю.
При необходимости доступа к ресурсам передается часть ключа,
составленная из данных пользователя. На клиенте на основе полученной части
26
ключа и технической информации об устройстве составляется ключ
расшифровки, с помощью которого осуществляется расшифровка и доступ к
необходимому ресурсу.
Игра использует собственный скриптовый язык (на основе скриптовго
языка Ren'Py). Директивами скриптового языка выполняются команды игровой
логики.
#Установить фоновое изображение.
scene bg college_gates
#Отобразить изображение
show "mikae fuku normal" at right
#Вывести реплику персонажа
mikae "[pname]! Good moooooooooorning!!\"" #[pname] – переменная, хранящая
имя игрока
Суммарный объем скриптов составляет меньше одного мегабайта. При
современных интерет-скоростях этот объем является ничтожно малым, а за
один запрос можно передавать одну строчку (в терминологии скрипта одна
строчка — одна операция), что распределяет передачу скрипта по времени.
Следовательно, всю скриптовую логику можно хранить на сервере.
Таким образом, логика в игре следующая:
1. Запрос
строчки
скрипта.
27
// Сторона сервера
/**
* Возвратить скриптовую команду
* @return
*/
public String getNextScript(String... args){
if(args.length == 0){
return script.nextElement();
} else {
return findNext(script.currentElement(), args);
}
}
2. Выполнение строчки скрипта.
3. Вернуться на шаг 1.
В результате, даже получив доступ к недоступным игровым ресурсам,
игрок не сможет использовать их в игре т. к. для их отображения необходима
соответствующая директива от сервера.
Так же на сервере находится вся логика, касающаяся характеристик
персонажа и прогресса. Нечестный игрок не может вмешаться локально в
игровые параметры, облегчив себе прохождение.
Все данные хранятся в базе данных PostgreSQL. База данных находится
в той же защищенной сети, что и сервер приложений. Доступ к данным
осуществляется по стандарту Java Persistence API (JPA) 2.0 (стандартизация
технологии ORM для Java EE). В приложении используется реализация JPA 2.0
EclipseLink.
Библиотека EclipseLink загружается на сервер приложений в качестве
исполняемого модуля и не находится в EJB-контейнере.
28
@Entity
@NamedQuery(name="Player.findById", query="SELECT p FROM Player p where
p.id = :id")
@NamedQuery(name="Player.findByUser", query="SELECT p FROM Player p
where p.user_id = :user")
public class Player implements Serializable {
private static final long serialVersionUID = 1L;
private Integer id;
private User user;
@Enumerated(EnumType.STRING)
private PlayerType type;
private Integer passion;
private Integer apprentice;
private Integer fatigue;
private Integer scholarship;
private Integer strength;
private Integer art;
public Player() {
}
@Id
@SequenceGenerator(name="PLAYER_ID_GENERATOR",
sequenceName="PLAYER_SEQ")
@GeneratedValue(strategy=GenerationType.SEQUENCE,
generator="PLAYER_ID_GENERATOR")
public Integer getId() {
return this.id;
}
public Integer getPassion() {
return this.passion ;
}
public void incPassion() {
this.passion += type.getRnd.incPassion();
}
public Integer getAppearance() {
return this.apprentice ;
}
public void incAppearance() {
this.apprentice += type.getRnd.incAppearance();
}
public Integer getFatigue() {
return this.fatigue ;
29
}
public Integer getScolarship() {
return this.scolarship ;
}
public void incScolarship() {
this.scolarship += type.getRnd.incScolarship();
this.fatigue += type.getRnd.incScolarship();
}
public Integer getStrength() {
return this.strength ;
}
public void incStrength() {
this.strength += type.getRnd.incStrength();
this.fatigue += type.getRnd.incStrength();
}
public Integer getArt() {
return this.art ;
}
public void incArt() {
this.art += type.getRnd.incArt();
this.art += type.getRnd.incArt();
}
//bi-directional many-to-one association to Catalog
@ManyToOne(cascade={CascadeType.PERSIST, CascadeType.MERGE,
CascadeType.REFRESH})
@JoinColumn(name="id")
public User getUser() {
return this.user;
}
}
Так как игра является ремейком уже существующего продукта, могут
возникнуть авторские претензии правообладателей. Однако, студия,
разработавшая оригинальную игру, в данный момент исчезла с рынка
интерактивных развлечений, официальные сайты их проектов и самой студии
не обновлялись с 2006 года. В случае возникновения инцидента по нарушению
авторских прав, в игру вносится поправка, требующая наличие оригинальных
30
файлов игры. В таком случае команда разработчиков обладает полным правом
на распространение своего исполняемого кода и своего контента.
4.4.2 Защита сервера приложений
Для сервера приложений существуют следующие угрозы:
 перехват трафика
 подключение для использования публичных функций
 подключение к административной консоли управления сервером
 загрузка собственных приложений на сервер приложений
 захват операционной системы сервера
Защита трафика осуществляется шифрованием разовым сеансовым
ключом передаваемых данных по алгоритму AES:
1. При запуске клиент запускает процедуру установки защищенного
соединения и запрашивает открытый ключ.
private void setSecureConnection(){
try {
key = getPublicKey();
…
}
2. Сервер генерирует пару RSA-ключей и передает клиенту открытый
ключ.
public PublicKey getPublicKey(){
try {
KeyPair keyPair =
KeyPairGenerator.getInstance("RSA").genKeyPair();
key = keyPair.getPrivate();
return keyPair.getPublic();
} catch (NoSuchAlgorithmException e) {
e.printStackTrace();
}
return null;
}
3. Клиент получает открытый ключ, создает сессионный ключ, шифрует
сессионный ключ открытым ключом сервера, передает зашифрованный
сессионный
ключ
серверу.
31
private void setSecureConnection(){
try {
PublicKey publicKey = sessionBean.getPublicKey();
key = KeyGenerator.getInstance("AES").generateKey();
Cipher rsa = Cipher.getInstance("RSA");
rsa.init(Cipher.ENCRYPT_MODE, publicKey);
sessionBean.setSessionKey(rsa.doFinal(key.getEncoded()));
} catch (NoSuchAlgorithmException e) {
e.printStackTrace();
} catch (NoSuchPaddingException e) {
e.printStackTrace();
} catch (InvalidKeyException e) {
e.printStackTrace();
} catch (IllegalBlockSizeException e) {
e.printStackTrace();
} catch (BadPaddingException e) {
e.printStackTrace();
}
}
4. Сервер получает зашифрованный сессионный ключ, расшифровывает
его, впоследствии, трафик будет шифроваться/расшифровываться с помощью
этого
сессионного
ключа
32
public void setSessionKey(byte[] sessionKey){
try {
cipher = Cipher.getInstance("RSA");
cipher.init(Cipher.DECRYPT_MODE, key);
key = new SecretKeySpec(cipher.doFinal(sessionKey), "AES");
} catch (NoSuchAlgorithmException e) {
e.printStackTrace();
} catch (NoSuchPaddingException e) {
e.printStackTrace();
} catch (InvalidKeyException e) {
e.printStackTrace();
} catch (IllegalBlockSizeException e) {
e.printStackTrace();
} catch (BadPaddingException e) {
e.printStackTrace();
}
}
Защита от несанкционированного доступа к функциям EJB-компонента
достигается стандартными средствами стандарта Java EE. При написании
приложения создается интерфейс, описывающий методы, находящиеся в EJBконтейнере. Доступ к контейнеру осуществляется в приложении с
использованием аннотации @EJB для объявленной переменной экземпляра
EJB-компонента и @Remote для интерфейса EJB-компонента. Таким образом,
доступ к приложению возможен только из программы, в которой присутствует и
используется интерфейс, описывающий методы компонента.
Следует заметить, что этот способ не защищает от дизассемблирования,
извлечения интерфейса и использования его в написании собственной
программы, использующей публичные функции EJB-компонента. Однако, это
затрудняет определение этих функций злоумышленником.
Разграничение
функциональности
между
различными
EJBконтейнерами так же способствует затруднению написания аналогов серверных
компонентов.
Схема контроля доступа в приложении.[26]
Как показано на изображении, за аутентификацию пользователя отвечает
один компонент, а за выполнение бизнес-логики клиента — другой. При
аутентификации, клиенту передается Mapped Name компонента логики
приложения, а так же сессионная информация. Так же сессионная информация
передается и компоненту логики. Таким способом можно достичь минимальной
уверенности, в том, что злоумышленник не сможет осуществлять вызовы
компонента логики приложения.
33
UML-диаграмма приложения
Для ограничения доступа к административной консоли управления
сервером приложений используются встроенные средства JBoss Application
Server. Доступ к консоли управления осуществляется на основе логина/пароля.
Создание учетной записи осуществляется в операционной системе, под
управлением которой находится сервер приложений. Поэтому, защита от
доступа к консоли управления есть суть доступ к операционной системе.
Защита операционной системы от несанкционированного доступа
является самой важной проблемой, так как реализация этой угрозы приводит к
реализации большинства других. Доступ осуществляется на основе
электронного ключа, наличествующий в единственном экземпляре. Доступ к
электронному ключу имеют администратор сервера приложения (Чигилейчик
Дмитрий Сергеевич) и администратор сервера базы данных (Солина Дарья
Анатольевна). Электронный ключ хранится в сейфе, код которого известен
лишь указанным сотрудникам. Для сетевой защиты используется межсетвой
экран iptables.
iptables_config.sh
# отклоняем битые и странные пакеты
iptables -A INPUT -m state --state INVALID -j DROP
iptables -A FORWARD -m state --state INVALID -j DROP
# пакеты от компьютеров-ботов
iptables -A bad_guys -d 208.180.74.193 -j DROP
iptables -A bad_guys -s 208.180.74.193 -j DROP
4.4.3 Защита базы данных
Угрозы для сервера базы данных:
 подключение злоумышленника к серверу БД
34
◦ прямым подключением
◦ через сервер приложений
 подключение злоумышленника к операционной системе машины БД
 SQL-инъекции.
База данных находится под управлением той же операционной системы,
что и сервер приложений и сконфигурирована на прием только локальных
транзакций.
pg_hba.conf
# TYPE DATABASE
local
truelovedb
host
all
USER
all
all
ADDRESS
0.0.0.0/0
METHOD
md5
reject
Таким образом, подключение к базе данных возможно только при
доступе к операционной системе, на которой она находится, о защите которой
было сказано выше.
Подключение к базе данных с сервера приложений осуществляется
посредством библиотекой Java DataBase Connectivity (JDBC), находящейся на
этом сервере. Подключение к этой библиотеке происходит по Java Naming and
Directory Interface (JNDI) API — интерфейс для обращения по именам. То есть,
для выполнения запросов через сервер приложений необходимо чтобы на
сервере приложений находился контейнер исполняемого кода, знающий JNDIимя библиотеки JDBC. Так, защитой от выполнения запросов через сервер
приложений является по сути защита от загрузки на сервер злоумышленником
собственного исполняемого кода.
Благодаря использованию технологии JPA, база полностью защищена от
SQL-инъекций. В EJB-компоненте отсутствуют функции, принимающие какиелибо SQL-запросы. Тем самым злоумышленник не может передать
вредоносный скрипт через доступные функции.
35
5. Заключение
Выбранная сфера разработанного приложения обеспечит успешный
старт для команды разработчиков. Принятые меры безопасности позволят
свести возможные финансовые потери прибыли у минимуму, а так же защитить
от доступа платный контент.
Разработанный метод защиты приложения, позволит продолжить бизнес
и расширить его на базе уже существующей структуры.
Цели работы достигнуты.
36
6. Список ресурсов
1. Защита программного обеспечения. Wikipedia.
2. Доктороу, Кори Лекция, прочитанная в Microsoft 17 июня 2004 года.
Компьютерра Online.
3. Обзор Alcohol 120 % — эмулятор CD/DVD-дисков, создание их образов
4. Новичков А. Анализ рынка средств защиты программного обеспечения от
несанкционированного копирования
5. ESA. "2012 sales, demographic and usage data"
6. Ольга Крапивенко. Игровая индустрия за неделю. 22–28 апреля 2013 года
7. Антон Веремьянин. Google Play и App Store: статистика, тренды, выручка и топиздатели. Мобильный контент.
8. The Visual Novel Database
9. IXBT.com Новость от 10.01.2013
10.Ryan Block TiVo adding downloadable content, games, internet radio, podcasting, etc.
11.Google Android – первые шаги. 3DNews.
12.Industry Leaders Announce Open Platform for Mobile Devices
13.Google Calling: Inside Android, the gPhone SDK. onlamp.com.
14.Mach kernel source code. Browsable version of the Mach Kernel source code on
the FreeBSD/Linux kernel cross reference site
15.Сравнение командных оболочек. Wikipedia.
16.MeeGo Architecture Layer View
17.Introduction to Model/View/ViewModel pattern for building WPF apps
18.Model-View-ViewModel. Wikipedia
19.Radio. Behind the Scenes. Metal Gear Wikia.
20.Wayne (October 1988). "Reviews". Computer + Video Games (84)
21.Скляров Д.В. Аппаратные ключи защиты // Искусство защиты и взлома
информации.
22.
23.Colossal Cave Adventure (c.1975)
37
24.Todome, Satoshi. A History of Eroge
25.School days HQ coming in english. Sekai Porject
26.EJB Security Configuration. Oracle Containers for J2EE Security Guide
27.Oracle. Java EE 6 APIs. The Java EE Tutorial.
28.Android Developers
29.Delivering enterprise information securely on Android, Apple iOS, and Microsoft Windows
tablets and smartphones. BYOD and Information Security
30.ГОСТ Р 51901.1-2002
38