Всем привет, ребята подскажите как правильно организовать и защитить таблицу в которой будет хранится balance пользователя?
Вебмани передает ответ об успешной операции, могу занести код транзакции в таблицу платежа, чтобы злоумышленник который если попадет в нее, не смог сгенерировать данный код, и система после проверки кода на валидность активировала деньги.
Вопрос в том что нужно сделать, чтобы злоумышленник не смог сам подтвердить в таблице платежей, скажем платеж считается легальным только когда у него status true. Как запретить ручной ввод данного поля? И разрешить только скрипту?
Создать еще одного пользователя БД или настроить права у существующего.
Сделать, чтобы он не имел прямого доступа к таблице (select, update, insert, delete).
Сделать view для получения данных и процедуру для внесения данных (или триггер на view, если позволяет СУБД).
Это обеспечит единый вход к данным. В триггере или процедуре можно так же добавить логирование или более сложную проверку прав доступа к определенным столбцам таблицы.
Не понятно: ты боишься, кто кто-то взломает твой сервер и, получив доступ к БД начнёт вносить туда изменения, либо ты боишься, что кто-то может "прикинуться" Вебмани и дёрнуть тот скрипт, который обновляет значение баланса?
Зачем вам вообще хранить какой-то статус? При легальном апдейте баланса через приложение подписывайте все значащие данные в таблице баланса, передавая процедуре (или в запрос) какой-нибудь ключ. Подпись хранится в отдельном поле таблицы. Скажем, конкатенируете баланс и секретный ключ, берете sha1 от них - это подпись. При уменьшении баланса - такая же процедура: проверка подписи, если все ок - уменьшение баланса и подпись изменившихся данных. Если при попытке изменения баланса подпись не сходится, значит данные поломаны. Таким образом, не зная секретного ключа злоумышленник не сможет внести легальные изменения в таблицу балансов.
Правда, в этом случае вам надо обеспечить сохранность ключа, хранить на диске не очень секьюрно.
Кстати, тут все почему-то подумали о злобных хакерах со стороны. Не забываем, что сами сотрудники, имеющие доступ на продакшн, могут оказаться злоумышленниками. Когда речь идет о реальных деньгах нельзя полагаться на пушистость сисадминов/разработчиков.
Ну вообще-то при использовании нормальных фреймворков/ORM вероятность SQL Injection или например атаки с помощью XSS становится очень небольшой. Но если хочется перестраховаться, запретите прямое хождение в таблицу и работайте с ней исключительно через процедуры например, частично поможет. (Безопасность - это процесс, а не результат).