Как правильно организовать и защитить таблицу в которой будет хранится balance пользователя?

Всем привет, ребята подскажите как правильно организовать и защитить таблицу в которой будет хранится balance пользователя?

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

Вопрос в том что нужно сделать, чтобы злоумышленник не смог сам подтвердить в таблице платежей, скажем платеж считается легальным только когда у него status true. Как запретить ручной ввод данного поля? И разрешить только скрипту?

  • Вопрос задан
  • 3354 просмотра
Пригласить эксперта
Ответы на вопрос 5
Cobalt
@Cobalt
Программист - этим все сказано

Изначально не верный подход. Если кто-то может писать в таблицу - он в нее запишет. Перефраза одного из законов Мерфи.

Правильным будет вообще не допускать несанкционированный доступ к базе.

Ответ написан
@pihel
Sql, Oracle, pl/sql, BI, ETL, php, olap

Создать еще одного пользователя БД или настроить права у существующего.
Сделать, чтобы он не имел прямого доступа к таблице (select, update, insert, delete).
Сделать view для получения данных и процедуру для внесения данных (или триггер на view, если позволяет СУБД).
Это обеспечит единый вход к данным. В триггере или процедуре можно так же добавить логирование или более сложную проверку прав доступа к определенным столбцам таблицы.

Ответ написан
@Kane

Не понятно: ты боишься, кто кто-то взломает твой сервер и, получив доступ к БД начнёт вносить туда изменения, либо ты боишься, что кто-то может "прикинуться" Вебмани и дёрнуть тот скрипт, который обновляет значение баланса?

Ответ написан
ksusha
@ksusha

Зачем вам вообще хранить какой-то статус? При легальном апдейте баланса через приложение подписывайте все значащие данные в таблице баланса, передавая процедуре (или в запрос) какой-нибудь ключ. Подпись хранится в отдельном поле таблицы. Скажем, конкатенируете баланс и секретный ключ, берете sha1 от них - это подпись. При уменьшении баланса - такая же процедура: проверка подписи, если все ок - уменьшение баланса и подпись изменившихся данных. Если при попытке изменения баланса подпись не сходится, значит данные поломаны. Таким образом, не зная секретного ключа злоумышленник не сможет внести легальные изменения в таблицу балансов.
Правда, в этом случае вам надо обеспечить сохранность ключа, хранить на диске не очень секьюрно.

Кстати, тут все почему-то подумали о злобных хакерах со стороны. Не забываем, что сами сотрудники, имеющие доступ на продакшн, могут оказаться злоумышленниками. Когда речь идет о реальных деньгах нельзя полагаться на пушистость сисадминов/разработчиков.

Ответ написан
afiskon
@afiskon

Ну вообще-то при использовании нормальных фреймворков/ORM вероятность SQL Injection или например атаки с помощью XSS становится очень небольшой. Но если хочется перестраховаться, запретите прямое хождение в таблицу и работайте с ней исключительно через процедуры например, частично поможет. (Безопасность - это процесс, а не результат).

Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы