У биржевых хакеров снова наступила «ломка»…

Я так понимаю, все фейковые LibertyReserve-доллары теперь просто сгорят? Или все таки была возможность перевести их в реальные доллары?

Цитаты:

Работаю с Liberty API и могу сказать, что обработку платёжки на бирже явно писали идиоты.
Это вообще касается работы с любой платёжной системой — намалюют абы как (или поставят стандартный скрипт-пример от самой платёжки) и потом удивляются.
Для того, что бы такого не происходило, желательно по возможности заюзать следующие советы (некоторые системы не поддерживают определённый функционал, либо наоборот имеют дополнительные средства — в любом случае стоит их использовать по максимуму):

1. Использовать HTTPS
2. Устанавливать ссылку на обработчик нотификаций в настройках мерчанта и никогда не ставить его в виде параметра в форме (не для всех платёжек такое возможно, но их слава богу мало).
3. Не держать обработчик нотификаций на том же домене и с очевидным адресом. Сделайте пару неговорящих ни о чем поддоменов и используйте один из них, либо зарегистрировать вообще отдельный домен под это дело. Путь к скрипту обработки не должен угадываться на раз, все попытки неправильных запросов отфутболивать как 404.
4. Внимательно проверять статусы транзакций, соотвествие валют, соотвествие суммы записаной в транзакции и той, что пришла в нотификации.
5. Обязательно вести лог действий над транзакцией, любые несоотвествия нещадно и подробно логировать. Потом спасибо сами себе скажите.
6. Ограничить доступ по IP, что-бы доступ имел только сервер платёжной системы. Но нужно учитывать, что иногда IP меняются, так что нужно обязательно нотифицировать себя при несовпадении и подробно логировать то, что пришло, что бы обработать транзакции в ручную если нужно (и хотя обычно платёжки повторяют запрос через некоторое время, надеятся на это не стоит).
7. У большинства платёжек можно задавать свои кастомные поля — используйте их. Впихните туда 1-2 хеша посложнее (только не MD5, а что-нить типа SHA256 или покруче) с параметрами, о которых знает только ваша система и они нигде публично не фигурируют, да и алгоритм составления этого хеша узнают только если вас капитально сломают и утянут код — эти хеши очень сильно повышают надёжность транзакций, т.к. если хоть один параметр не совпадёт — хеш валидацию не пройдёт.
8. Статусы транзакций должны быть реализованы таким способом, что бы если нотификация пришла и была успешно обработана и получила финальный статус success/failed — то сменить скажем failed на success уже нельзя было бы через нотификацию, если кто-то всё же сумеет подделать запрос. Само собой нужно учитывать особенности самой системы — бывают и chargeback, и всякие pending и тому подобное. Так же бывает что failed реально может смениться на success — в таких случаях саппорт должен быть нотифицирован и транзакция должна проверяться в ручную.
9. В некоторых платёжках доступен API для работы с историей операция — юзайте! Это весьма надёжный способ проверить, а был ли мальчик

Уже лучше, кошелки хоть не уносят…