Pull to refresh

Comments 12

Отличная статья. Стимулирует к работе над своими способностями в багхантинге )
Представляю сколько в сети еще крутится таких ресурсов!
Багхантиг — это просто! Багхантинг в массы!
Ещё в очень бородатые годы я писал статью, если не ошибаюсь в районе 2007 года, «Скрытая угроза: „неизменяемые“ поля» про аналогичную ситуацию тогда ещё просто с формами. Технологии идут вперёд, а ошибки идут всё те же… =(
Справедливости ради должен заметить, что в данном случае дело было, как мне видится, несколько в другом.)
Ответ от сервера с суммой заказа возвращается и сейчас; его всё так же можно подменить и попытаться оплатить меньшую сумму. Однако при попытке оплаты платёжная система возвращает ошибку.
Я сам никогда не работал с платёжными системами и не представляю, как обычно организован этот процесс. Документация на CloudPayment есть здесь https://cloudpayments.ru/Docs/Integration. Я особо не вникал, но похоже, что перед оплатой система отправляет данные на сервер магазина и требует подтвердить оплату со стороны магазина. Возможно, для идентификации заказа используется orderID, который анализируется сервером, и по результатам анализа выдаётся разрешение на оплату. Раньше, соответственно, эта проверка почему-то всегда выдавала true.
У каких-то платёжных систем передавалась контрольная сумма из нескольких полей (формировалась строка в т.ч. и из суммы, параметров заказа, соли и прочего), по ней считалась контрольная сумма (точный алгоритм не помню, возможно, она сначала шифровалась известными только магазину и платёжной системе ключами) и по ней платёжная система определяла корректность переданных данных.

Про ответственность — если бы сотрудники и владельцы ресурса оказались несколько менее вменяемыми — легко можно было бы иметь как минимум 159.6 УК РФ или 146, если не 272. Для следователя все вообще шикарно — состав преступления налицо — и человек все сам в письме написал и подтвердил (признает, извиняется и раскаивается), и в платежной системе все прошло, и личные координаты все видны из-за используемой карточки → банк выдаст моментально.

В 2011 году точно таким же образом покупали лицензионный Minecraft.

Я так однажды пробовал купить корпоративную версию утилиты OfficeTab. Там оказалась ручная премодерация заказов, так что ключ я получил лишь на следующий день… на фейковую почту в письме с благодарностью за указание «дыры» и просьбой «please don't make fraud orders» :D

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

Думаю, что даже в этом случае, при желании, можно было-бы «припаять» статью («был бы человек, а статья найдется!») за незаконное исследование трафика (согласно приведенной вверху ссылке).
Разве может быть незаконным исследование своего собственного трафика? Он же его не перехватил у другого пользователя.
Я рассматривал случай, что после исследования он модифицировал запрос и заплатил больше положенного. С точки зрения закона (по крайней мере, исходя из ответа юриста) разницы особой нет, заплатил он меньше или больше; ключевые слова — несанкционированное вмешательство в работу программного обеспечения.

Привожу абзац из ссылки выше (если вам настолько лениво кликать):

Есть ли вообще какая-то ответственность за исследование и взлом чужой программы, сервиса, сети?

Если говорить про действующие российские законы, то да, есть. Когда исследователь тестирует чужой продукт на предмет уязвимостей или проникает в чужую сеть без ведома и согласия владельца, его действия могут быть расценены как неправомерные. И последствием таких действий может стать наступление ответственности различного рода: гражданско-правовой, административной и уголовной.
Sign up to leave a comment.

Articles