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

Question

[nezzard]

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

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

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

Answer 1

[Андрей Унгер]

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

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

Comments

[nezzard]

Я это понимаю, но если вдруг кто то смог попасть в бд, как правильно организовать таблицу чтобы он не смог накрутить счетчик баланса

Answer 2

[Алексей Скахин]

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

Comments

[nezzard]

Если я уберу прямой доступ select, update, insert, delete то сможет ли скрипт добавлять, обновлять данные? И стоит ли делать повторную проверку после получения Yes от вебмани?

[Алексей Скахин]

Скрипт будет работать через view и процедуру, к этим сущностям пользователю нужно дать права (А этим вью и процедуре надо дать права на таблицу) Т.е. у скрипта не останется вариантов, кроме как работать через них, т.к. прямого доступа к таблице не будет. Естественно все эти операции надо проводить под пользователем со всеми правами, но пароль от этого супер пользователя уже не будет хранится в приложении. П.с. я вам описываю ситуацию со стороны Oracle, надеюсь MySql это все поддерживает.

[nezzard]

Хм, почитаю. Спасибо за наводку

Answer 3

[Kane]

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

Comments

[nezzard]

Боюсь что кто то в ручную введет данные в balance

[nezzard]

Вот думаю как защитить balance от ввода вручную

[Kane]

При подтверждении платежа, ты должен проверить, его при помощи АПИ вебмани http://wiki.webmoney.ru/projects/webmoney/wiki/Web_Merchant_Interface#11

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

Answer 4

[ksusha]

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

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

Comments

[nezzard]

Я правильно понял? Нужно хранить транзакции с кодом в отдельной таблице, и каждый раз когда пользователь работает с балансом, создавать новое поле и опять с кодом. А общий баланс выводить как? Просчитывать все строки и суммировать ?

[ksusha]

Мне показалось, что у вас транзакции отдельно, а баланс - отдельно, в разных таблицах. И грубо говоря две процедуры - списание и пополнение (вставка транзакции + апдейт баланса). Я имела в виду, что у таблицы балансов можно сделать отдельное поле, скажем, signaure и подписывать текущее состояние баланса (остаток на счете) секретным ключом после проведения каждого списания и пополнения. А до проведения списания/пополнения - проверять эту подпись. Если подпись не сходится - транзакция не проводится.

[nezzard]

Допустим таблица users столбцы id, balance, signaure с первыми двумя все понятно, в signaure заношу мд5 код из таблицы tranzaktion вот только из чего генерировать код? Ведь там будет много строк, зачисления из вебмани, и снятие баланса за услуги. Все это хранить в одной таблице ? Если да то из чего конкретно генерировать ?

[nezzard]

Вот как из этого сделать то что вы описали? https://www.dropbox.com/s/nuzetvege16bszk/key.png

[ksusha]

Секретный ключ в бд не хранится, в бд хранится sha1 или md5 значимых данных, сконкатенированных с секретным ключом. Набор значимых данных вы определяете самостоятельно исходя из здравого смысла. Если вам важно, чтобы не накрутили баланс - подписываете баланс. Нужно еще что-то - добавляете эти данные к подписи.

[nezzard]

Это я понимаю, но по какому полю генерировать md5 ? Ведь их там будет много, а какой именно выбрать для md5 ?

[ksusha]

Так о том и речь - выбираете сами состав полей. Подписываете то, что для вас критично. Я не очень понимаю, где много-то) Вы подписываете текущее состояние баланса и всё, если для вас критичен именно баланс. Ещё какие-то данные - на ваше усмотрение. Баланс с ключом можно подсолить перед хешированием для надежности.

[nezzard]

@ksusha Я вас сначала не правильно понял. Я думал подпись формировать из двух таблиц

Answer 5

[afiskon]

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