Развёрнутая постановка целей и задач

Целью данной работы является разработка сервиса приватных сообщений без логирования.

Для достижения поставленной цели необходимо решить следующие задачи:

1. Проанализировать данные об утечках информации в сети;

2. Разработать сервис для отправки приватных сообщений;

3. Программно реализовать сервис, с помощью инструментальных средств;

4. Оценить общую работу программы;

Сервис должен быть написан на подходящем языке программирования, без ошибок.

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

— Защита от SQL-инъекций, путем подставления данных только через плейсхолдеры;

— Использование нестандартных директорий каталогов и служебных файлов. (Например расположение админ-панели по адресу /admin, ставит ее под легкий удар хакеров);

— Использование “сложных” паролей доступа к панели администратора, для защиты от подбора паролей с помощью программных средств хакеров (Brute Force);

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

— Индексирование директорий. Если на сайте отсутствует определенная страница , сервер отображает список директорий, что может привести к тому, что злоумышленник узнает место расположения панели администратора.

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

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

Сервис также должен иметь простой и доступный веб-интерфейс (UI), обладающий кроссплатформенной версткой.

Исходный код программы должен быть открытым, поэтому он будет размещен на веб-сервисе для хостинга IT-проектов Github, в открытом репозитории. Такая мера является хорошим тоном и указывает на «прозрачность» сервиса.

Сам сервис должен быть размещен на выделенном сервере, на котором не будут вестись логи.

Итого сервис должен обладать следующими чертами:

- Доступность – наличие полнофункционального веб-интерфейса, доступного для работы с любого устройства;

- Шифрование данных;

- Защищенность данных на сервере ;

- Наличие пароля для доступа к информации .

Обоснование проектных решений

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

Требования к структуре и функционированию

1.5.1.1 Перечень подсистем, их назначение и основные характеристики

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

1.5.1.2 Требования к способам и средствам связи для информационного обмена между компонентами системы

Обмен данными в системе должен происходить с помощью базы данных MySQL.

1.5.1.3 Требования к характеристикам взаимосвязей системы со смежными системами

Программно-технические средства реализовываемого сервиса должны соответствовать стандартам сети Интернет и поддерживать безопасный прием и передачу данных по протоколу прикладного уровня HTTP с расширением HTTPS. Сервер должен иметь поддержку языка PHP версии не ниже чем 5.4 и иметь удаленный доступ к серверу через протокол SSH. Клиентская часть должна поддерживать формат передачи данных JSON, а так же язык JavaScript.

Программное обеспечение сервиса должно быть совместимо со следующими технологиями: aдаптивная верстка, асинхронные запросы на удаленный сервер.

Технические требования к вышеперечисленным функциям будут определены на стадии технического проекта.

1.5.1.4 Требования к режимам функционирования

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

1.5.1.5 Требования к надежности

Сервис всегда должен быть доступен клиенту, за исключением технических работ, о которых администрация сервиса сообщает заранее. Кроме того система должна быть защищена от уязвимостей: SQL-инъекций, ISE, Directory Indexing. Сервис также должен уведомлять пользователя об вводе информации неверного формата.

1.5.1.6 Требования безопасности

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

1.5.1.7 Требования к эргономике и технической эстетике

Взаимодействие пользователей с системой должно осуществляться посредством визуального графического интерфейса (GUI). Ввод-вывод данных, прием управляющих команд и отображение результатов их исполнения должны выполняться в интерактивном режиме, в реальном времени. Интерфейс должен соответствовать современным эргономическим нормативам: ГОСТ 12.2.049, ГОСТ 30.001, ГОСТ 20.39.108, ГОСТ 21958 и ГОСТ 50948 (для пользователей с мониторами ЭЛТ).

Страницы пользовательского интерфейса должны разрабатываться с учетом требований унификации:

- панели навигации должны располагаться одинаково на всех страницах платформы;

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

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

Интерфейс должен обеспечивать комфортный доступ к основным функциям и операциям, выполняемым подсистемами.

Интерфейс должен быть рассчитан на пользователей стационарных устройств, однако также должен обладать адаптивностью – возможностью удобно подстраиваться под любое мобильное устройство или компьютер с нестандартной диагональю экрана. Функциональное управление системой предполагается с помощью кнопок, вкладок, лайтбоксов и вспомогательных модальных окон. Ввод и вывод данных должен осуществляться с помощью полей ввода и вывода соответственно.

1.5.1.8 Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы

Для эксплуатации разрабатываемой информационной системы необходимы следующие условия:

1) подключение к глобальной сети интернет с минимальной скоростью прередачи данных 1Mб/c.

2) со стороны пользователя выдвигаются следующие требования к браузерам: Internet Explorer версии не ниже 9.0, Google Chrome версии не раньше 12.0 , Opera версии не ниже 18.0, Firefox версии не ниже 16.0, Safari начиная с версии 6.0.

3) электропитание технических средств от сети напряжением 220 В с частотой 50 Гц с глухо–заземленной нейтралью;

4) физическая защита аппаратных компонентов системы.

1.5.1.9 Требования к защите информации от несанкционированного доступа

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

Компоненты подсистемы защиты от НСД должны обеспечивать:

— передачу данных пользователей по HTTPS и SSH;

— проверку вводимых пользователем данных;

— фильтрацию входящих и исходящих запросов;

— проверку типа информации, которою клиент передает через поле ввода;

— blowfish шифрование полученной информации для хранении в базе данных;

1.5.1.10 Требования по сохранности информации при авариях

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

Программное обеспечение серверной части системы должно автоматически восстанавливать ее функционирование после аварии.

1.5.2 Требования к функциональности системы

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

1.5.3 Требования к видам обеспечения

1.5.3.1 Требования к информационному обеспечению

База данных должна соответствовать требованиям нормализации не ниже 2 нормальной формы. Также база данных должна быть целостна и связана по ключам.

Все подсистемы связаны между собой общим набором данных находящихся в базе данных.

1.5.3.2 Требования по применению в системе языков высокого уровня

При разработке сервиса используется язык программирования – PHP, с использованием фреймворка Yii2

1.5.3.3 Требования к программному обеспечению

Разрабатываемая платформа должна базироваться на удаленных серверах со стеком LAMP(linux nginx MySql PHP). Сервер должен иметь подключение по протоколу SSH, также на сервере должна быть подключаемая библиотека Curl. Cо стороны пользователя выдвигаются следующие требования к браузерам: Internet Explorer версии не ниже 9.0, Google Chrome версии не раньше 12.0 , Opera версии не ниже 18.0, Firefox версии не ниже 16.0, Safari начиная с версии 6.0.

1.5.4 Требования к техническому обеспечению

Для нормального функционирования веб-платформы сервер должен иметь приблизительные характеристики:

- Платформа Linux, Windows;

- Операционная система: Ubuntu 16.04.2 x64;

- Процессор Intel Xeon 1 CPU ;

- Тактовая частота 2.4 Ghz;

- Оперативная память (RAM) 512Mb DDR3;

- Защита от DDOS-атак;

1.5.5 Требования к метрологическому обеспечению

Требований к метрологической совместимости технических средств системы не предъявляется.

1.5.6.Требования к организационному обеспечению

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

Глава 2. Проектная часть

Проектирование сервиса

На сегодняшний день, одной из самых актуальный проблем в области IT-технологий, является проблема безопасности информации в сети интернет. Информационная безопасность, это состояние, при котором информация является защищенной, обеспеченна безопасность ее целостности, конфиденциальности и доступности. Такое состояние можно охарактеризовать следующими пунктами:

— Аутентификация – процесс при котором пользователь будет распознан, после чего ему будут выданы определенные права.

— Целостность – состояние информации при котором сохраняется ее изначальное содержание. В частности, под этим понимают идентичность отправленных данных с принятыми.

— Секретность – защита от несанкционированного перехвата данных.

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

Шифрование данных – обратимое преобразование информации в целях её защиты от неавторизованных лиц. Шифрование данных защищает информацию и в тоже время создает условие, при котором попадание такой информации в руки злоумышленника не принесет ему никакой ценности.

Шифрование данных происходит по определенному алгоритму. В современном мире их принято разделять на три группы:

— алгоритмы симметричного шифрования;

— алгоритмы ассиметричного шифрования;

— алгоритмы хэш-функций.

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

- полное уничтожение всех статистических закономерностей;

- отстутствие линейности.

Симметричные алгоритмы разделяются на блочные и поточные.

Блочные системы разбивают данные на блоки для дальнейшего преобразования с помощью ключа.

В поточных системах шифрование происходит потоком, по мере генерации выходной гаммы.

Рисунок 4 — Пример схемы с использованием

симметричного алгоритма

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

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

Простейшим примером хэширование является PHP функция md5().

Рисунок 5 — Пример применения функции md5()

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

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

Сравнение алгоритмов шифрования приведено в таблицах 3, 4.

Таблица 3 — параметры алгоритмов шифрования

Алгоритм шифрования	Размер ключа, бит	Длина блока, бит	Число циклов	Основные операции
DES				Подстановка, перестановка, сумма.
IDEA				Умножение по модулю 216+1, сложение по модулю 216 , кольцевая сумма
Blowfish	32-448			Сложение по модулю 232, подстановка, кольцевая сумма
ГОСТ 28147-89				Сложение по модулю 232, перестановка, кольцевая сумма, циклический сдвиг.

Таблица 4 — сравнительные характеристики скорости алгоритмов шифрования на Intel Xeon 1 CPU 2.4 GHz

Алгоритм шифрования	Число циклов на раунд	Число раундов	Число циклов на зашифрованный байт	Примечания
DES				Размер ключа 56 бит
IDEA				Размер ключа 128 бит
Blowfish				Размер ключа 448 бит
ГОСТ 28147-89				Размер ключа 256 бит

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

Пароль создается с помощью функции http://php.net/manual/ru/function.password-hash.php

Пароль расшифровывается с помощью http://php.net/manual/ru/function.password-verify.php

К указанному паролю перед хешированием добавляется случайная строка (соль). Таким образом, у двух пользователей с паролем «123456» будут разные соли «соль1» и «соль2», а соответственно и хеш-функции от «123456соль1» и «123456соль2» в базе тоже будут разные.

Проектирование базы данных

В качестве СУБД была выбрана система MySQL. В базе данных будут храниться записи о данных передаваемых пользователями полученных от удаленного сервера.

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

Таблица 3 – Структура БД

Название	Назначение
uid	Уникальный ключ сообщения
password_hash	Зашифрованный пароль
body	Зашифрованный текст сообщения

Разберем на примере ссылки http://whispr.in/GIO7IqbXjjdlwi4F!A03qf5Cq.

Строка GIO7IqbXjjdlwi4F – генерируемый, уникальный ключ записи (uid). Как можно заметить ссылка делиться на две части знаком “!”, A03qf5Cq в данном случае – это пароль сгенерированный автоматически, если пользователь не ввел свой пароль. Из формы ввода текста на сайте, пользователь отправляет текст сообщения (body) на сервер, генерируется уникальный ключ записи (uid), генерируется пароль (password_hash), затем все это шифруется через функцию bcrypt(blowfish) и сохраняется в базу данных.

Основываясь на этих данных создадим диаграмму IDEF0 и диаграмму декомпозиции.

Все функциональные процессы описаны в диаграммах (6,6а).

Рисунок 6 – диаграмма IDEF0

Рисунок 6а – диаграмма декомпозиции

2.3 Построение диаграммы классов

Класс — это элемент ПО, описывающий абстрактный тип данных и его частичную или полную реализацию. Другие абстрактные типы данных — метаклассы, интерфейсы, структуры, перечисления, — характеризуются какими-то своими, другими особенностями. Наряду с понятием «объекта» класс является ключевым понятием в ООП

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

Таблица 4 — описание классов

Наименование	Описание
NoteController	Основной класс, предназначенный для создания, просмотра, и удаления сообщений
Note.php	Класс модели сообщения. В нем описаны сценарии и валидация данных
SiteController	Подключения экшна, для вывода ошибок

Для построения диаграммы классов мы воспользуемся встроенной функцией IDE Phpstorm автоматической генерации UML-диаграммы.

2.4 Построение диаграммы последовательности

Используя данные полученные из прошлого пункта мы можем построить диаграмму последовательности.

Диаграмма последовательностей относится к диаграммам взаимодействия UML, описывающим поведенческие аспекты системы, но рассматривает взаимодействие объектов во времени. Другими словами, диаграмма последовательностей отображает временные особенности передачи и приема сообщений объектами.

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

Рисунок 7 – диаграмма последовательности

2.5 Построение диаграммы прецедентов

Диаграмма прецедентов (диаграмма вариантов использования) в UML — диаграмма, отражающая отношения между актёрами и прецедентами и являющаяся составной частью модели прецедентов, позволяющей описать систему на концептуальном уровне

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

Рисунок 8 – диаграмма прецедентов (вариантов использования)

У актера «Пользователь» есть следующие варианты использования:

— Отправить сообщение;

— Удалить сообщение сейчас;

— Прочитать сообщение.