Комментарии 3
Заголовок очень точный: действительно про 2+2=5
>что блокировка товара для покупки происходила на моменте добавления товара в корзину, а не при непосредственном оформлении заказа
Кажется, в этом простом сценарии можно прям упороться, чтобы сделать безопасно и удобно одновременно. Во-первых, что считать оформлением? Нажатие кнопки "оформить", или вызов платежного апи? Когда включать таймер, по срабатыванию которого заказ будет считаться отмененным и товары разблокируют? Атакующему ведь все равно, просто добавить в корзину, или прокликать "далее" пару раз. А если постоянный, доверенный покупатель пришёл за большим количеством разного товара (к примеру, офис менеджер из офиса на 1000 человек делает закупку на месяц по куче позиций начиная от доместосов и печенек и заканчивая удлинителями, и только 2 часа собирает корзину), и будет постоянно натыкаться на то, что в момент оформления 5-10 позиций в корзине уже недоступны. А это клиент, который в одиночку серьёзный оборот делает. Тогда просится некая матрица решений с маппингом на статус клиента и какие-то ещё факторы. Типа, добавление товара в корзину vip клиентом должно сразу блокировать товар на 3 часа, а новорег с нидерландского ip со странной таймзоной не получит блокировки вообще, - просто рефанд дадим, если в момент оплаты картой товар купит или заблокирует кто-то другой
Но! Если появляется возможность предсказуемо генерить рефанды без риска купить что-либо - это тоже дыра. Подозреваю, что можно создать проблемы с платежкой, если их нагенерить очень много. Условно, платежка будет по какому-то центу брать за каждый раз. Значит, просятся либо ещё более упоротые правила, либо что-то вроде рандомизации в бизнес логике, чтобы атакующий всегда имел риск накупить ненужного ему товара, реализуя с 2х акков схему накрутки рефандов
Вспомнился анекдот про серийного программиста.
Когда 2+2=5: чем страшны ошибки бизнес-логики приложений и почему их легко не заметить при разработке