На что обратить внимание при приёме денег на сайте?

Question

[joger]

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

Есть довольно большой опыт вебразработки, но с деньгами пока дела не имел.

Пока что в списке:
1. Трансакции наше всё
2. меня сильно пугает double spending. Хватит ли "UPDATE .... SET money=money+1", чтобы исключить эту воможность?
3. SQL injection, XSS знаем и любим, но вдруг чего забыл

Не подскажите ли ещё грабли, на которые можно наступить?

Answer 1

[_ _]

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

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

Comments

[joger]

игровую валюту можно будет вывести в реальные деньги. т.е. если зловред наманипулирует себе сто мульёнов и выведет - будет плохо

Answer 2

[Александр Кубинцев]

1. Транзакции-то в БД оно понятно, что нужны. Но нужны ещё и программные локи при начале обработки. То есть начали процедуру оплаты - пишем в таблицу локов [lock_id, time_stamp] что-то вроде [order_23423563720234, 2014-08-22 12:21:05]. Закончили - удалили запись из таблицы локов. Так вы избежите задвоений в случае каких-то ошибок при обработке транзакций. + читайте далее.
2. Как вы уже поняли, нужна не только табличка операционных транзакций, но ещё и ордеров, к которым относятся транзакции. Соответственно, локи на ордеры жизненно необходимы, чтобы в один момент времени над конкретным ордером совершалась только 1 транзакция. Почему нужна такая связь один-ко-многим? Ну допустим возникнет ситуация опротестования транзакции. Как вы будете аннулировать заказ? Нужно делать транзакцию на реверс/рефанд, чтобы сохранить историю операций.

А на счёт double-spending не в курсе

Answer 3

[kompi]

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

Comments

[joger]

у меня проблема не с ПС, а с действиями юзера на сайте. Пример: открываем 2 окна браузера, жмём "одновременно" "отправить другому пользователю 10 монет". как избежать проблем в этом случае?

[Александр Кубинцев]

@joger разве это не проблема самого юзера?

[joger]

Трансакция:
1. SELECT money as moneyA FROM user A
2. SELECT money as moneyB FROM user B
3. moneyA--;
4. moneyB++;
5. UPDATE user A SET money=moneyA
6. UPDATE user B SET money=moneyB

вроде бы всё нормально, но представьте себе, что 2 такие трансакции(а и б) идут параллельно:
1а=>1б=>2а=>3а=>4а=>5а=>6а=>2б=>3б=>4б=>5б=>6б
Почему в таком порядке? а карты так легли, этому ничто не мешает. а в итоге получаем, что у А деньги списали 1 раз, а В записали 2 раза

[Александр Кубинцев]

@joger кхм, тут подход в принципе не правильный. У вас должно создаться 2 отдельных ордера на операционные транзакции. Транзакция описывает сумму операции, тип (списание/возврат), связь с ордером, успешность и прочее. Баланс пользователя высчитывается как результат суммирования сумм по ордерам (после записи транзакции пересчитывается сумма для ордера).
Таким образом, в вашей ситуации будет две независимые операции, как и ожидается.

[joger]

если взять тот же пример с "юзер А переводит юзеру Б 10 монет". как в этом случае будет выглядеть пример с ордером? мне не очень понятен их смысл

[Александр Кубинцев]

@joger у ордера будут поля source_user_id и destination_user_id (можно условиться, что при вводе-выводе денег из игры фигурирует некоторый технический user_id). Соответственно, баланс пользователя A высчитывается как разница между выборками:
(SELECT sum(amount) FROM orders WHERE destination_user_id = :userA) - (SELECT sum(amount) FROM orders WHERE source_user_id = :userA)

В предложенном примере будет приблизительно такая запись в orders при user_id A = 5, B = 6, amount = 10, status = success

[id, amount, source_user_id, destination_user_id, status, date_created, last_update_time]:
1, 5, 6, 1, 2014-08-22 14:56, 2014-08-22 14:56

В transactions поля такие (type для начала: PURCHASE = 1, REFUND = 2):
[id, parent_id, order_id, amount, type, is_successful, date_created]
1, null, 1, 10, 1, true, 2014-08-22 14:56

[joger]

добавляем from, to, amount в трансакции и избавляемся от ордер. какая от него доп. польза?

[Александр Кубинцев]

@joger у вас при работе с реальными деньгами могут быть ситуации с опротестованием транзакций. Транзакции должны принадлежать ордеру, а также не могут быть удалены/отменены. То есть, вот вам ситуация.
Игрок с помощью ворованной банковской карты зачисляет деньги в игру. Банк допустим делал начисление через холдирование суммы и теперь отменяет операцию начисления. В вашей системе учёта тогда сперва появляется ордер и в нём транзакция на начисление. Через день - новая транзакция в этом ордере на рефанд на ту же сумму. Итоговая сумма по ордеру = 0.

[Александр Кубинцев]

@joger я ошибся немного на счёт статуса ордера.
Там в простейшем варианте необходимо не 2, а 4 варианта: CREATED, PURCHASED, REFUNDED, CANCELED.
Допустим, при операции зачисления денег сперва формируется пустой ордер со статусом CREATED. При сообщении Платежной Системы об успешности оплаты вы создаете транзакцию PURCHASE и меняете статус ордера на PURCHASED.

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

[joger]

вот поэтому я и хотел разделить приход и уход реальных денег(ваши ордеры) в одну таблицу, игровую валюту (трансакции) в другую. без зависимости между ними. тогда баланс юзера это: (real_money_in - real_money_out)+(game_money_to- game_money_from)

[Александр Кубинцев]

@joger а зачем разделять? Применяя к сценарию с передачей игровой валюты я вижу следующий интерфейс.
Пользователь выбирает сперва кому послать деньги. Жмёт ок и создается ордер CREATED. На следующем шаге он выберет сколько переслать и нажмёт ок. В ордере создастся транзакция PURCHASE на указанную сумму. Для ордера следом запишется сумма и новый статус PURCHASED.
На каждом шаге ордер лочится перед изменением, поэтому сценарий с двумя открытыми окнами на 2-м шаге с выбором суммы и одновременным подтверждением не приведет к задвоению.