Как организовать безопасную работу MySQL + PHP для игры на Unity?

Question

[v170s]

Добрый день! Есть игра на юнити, она подключается через UnityWebRequest к PHP скрипту (использую ORM redbeanphp), далее скрипт подключается к базе данный MySQL. Теперь встал вопрос безопасности всего этого. Если злоумушленник, декомпилировав игру получит прямые ссылки к скриптам PHP, может ли он в теории чего нибудь натворить плохого? Или это все решается хорошим хостингом? Пока код пишется, использую MAMP чтобы создать сервер локально. Пароли подключения к БД очевидно будут другие, плюс разделю ответственность между пользователями БД(чтобы ни у одного не было полного доступа, а только на чтение-запись в определенную таблицу). Про MySQL инъекции знаю, поэтому использую ORM. Пароли юзеров в БД хранятся в зашифрованном виде. И вообще, достаточно ли такой способ подключения к БД безопасный? Я в информационной безопасности мало что понимаю, поэтому обращаюсь сюда. Спасибо!

WWWForm form = new WWWForm();
        form.AddField("name", nameField.text);
        form.AddField("password", passwordField.text);
        UnityWebRequest www = UnityWebRequest.Post("http://localhost/sqlconnect/register.php", form);
        yield return www.SendWebRequest();

require 'rb.php';
R::setup('mysql:host=localhost;dbname=myDB', 'root', 'root');

Answer 1

[Макс Кузнецов]

Если злоумушленник, декомпилировав игру получит прямые ссылки к скриптам PHP, может ли он в теории чего нибудь натворить плохого?

Эти скрипты PHP должны быть выполнимыми не должны быть скачиваемыми (обычно дефолтно настроенный веб-сервер так и делает). То есть при запрос скрипта, веб-сервер не отдаст его как текстовый файл, а выполнит все инструкции пхп и потом вернёт только то, что пхп выведет. Например, всё, что заключено в <?php .... ?> будет скрыто, кроме того, что выводится функциями echo, print и подобными.

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

По безопасности в целом — есть два подхода:
1) Сделать обычную регистрацию и авторизацию внутри Юнити приложения. Как я понимаю, у вас сейчас так и сделано. После регистрации Юнити получает токен и использует его для всех последующих запросов. Токен желательно делать протухающим со временем.
2) Сделать регистрацию и авторизацию на сайте, пройдя которую человек может получить доступ к странице, в которую встроено Юнити приложение. И при рендеринге приложения ему сразу же передаётся такой же токен для запросов, что и в пункте выше.

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

Comments

[v170s]

Спасибо большое! Да, весь код написан внутри <?php тега. Не подскажите где можно про использование токенов из первого подхода получить информацию? Сейчас регистрация реализована очень просто: пользователь вводит username и пароль в юнити, это все предается в БД и там сохраняется. А при логине, проверяется наличие username и совпадение пароля. Если надо скину php скрипты. По хорошему нужно спрашивать еще email, но пока думаю над этим, ибо проект не очень большой

[Макс Кузнецов]

А после логина юнити-приложение что в ответ получает? Например, если нужно будет отправить из юнити результаты, то как сервер поймёт, чьи это результаты? В браузерах для этих целей есть механизм сессий. В Юнити насколько знаю нет.

Токен — это любая случайная последовательность, какую придумаете. В двух словах они работают так:
- после регистрации или логина вы создаете такую случайную последовательность и записываете в таблицу юзера вместе с датой, когда этот токен протухнет. Этот токен посылаете в ответе на запрос регистрации/логина (удобнее всего в Authorization header-заголовке запрос)
- на последующие запросы юнити должна слать этот токен, а сервер перед обработкой запроса проверяет, что этот присланный токен есть в базе и по нему находит юзера.

Для самого простого понимания, представьте, что токен = юзернейм. Юнити приложение так представляется серверу. Но юзернейм использовать небезопасно, можно ж заменить на admin. Поэтому используют хэш-функции типа sha256 и подобные от каких-то условно случайных переменных: айди пользователя, дата и время.

Чаще всего в пхп фреймворках есть свои готовые либы для их реализации.

[v170s]

Макс Кузнецов, после логина юнити получает только username. Теперь понял, что это небезопасно. Спасибо! Я правильно понимаю механизм сессий: Пользователь при регистрации вводит username и пароль, PHP скрипт генерирует случайный токен, и отправляет его в юнити и записывает в БД рядом с именем пользователя. Юнити хранит этот токен до того момента как он не истечет, или пользователь не выйдет из аккаунта. И по этому токену пользователь однозначно определяется PHP скриптом и, следовательно БД. Т.е. грубо говоря токен - это такой же способ определения пользователя как и username, только более защищенный, и токен будет хранится только в БД и в клиенте. Такая схема регистрации и логина достаточно безопасна?

[Макс Кузнецов]

v170s, верно. Токены просто более рандомные и длинные, чтобы их перебрать нельзя было. Посмотрите в сторону jwt токенов.

В остальном вполне безопасно особенно для небольшого приложения.

[v170s]

Макс Кузнецов, спасибо огромное!