Как обмануть Робокассу

[@Dialog]

А робокассе то это сообщили, точнее прошло ли какое-то время после уведомления? А то античат получается.

[@khovansky]

Нет, никакого античата, в робокассу запрос направлен.

[@vinograd19]

В shp параметрах там тоже небольшая дыра. Из документации (ссылка), для оплаты, пользователя переносят на сайт робокассы post-запросом. Одним из данных формы является md5-подпись, которая берется от строки «sMerchantLogin:nOutSum:nInvId:sMerchantPass1:shpa=yyy:shpb=xxx». Казалось бы, при заданных параметрах, магазин делает md5 подпись, и мы никаким образом не может составить другую валидную подпись для других параметров. Однако это не совсем верно. Если магазин запихивает в shp-параметры какие-то важные параметры (как например «оплаченную сумму»), воздействовать на них можно так: допустим shpb=1000. Вы тупо добавляете лишний 0, и получаете строчку с shpb=10000. Далее обновляете существующую md5-подпись, добавлением 0 (алгоритм генерации md5 позволяет добавлять в строчку символы). Если на стороне магазина скрипт не проверяет, что же там было в присланной «OutSum», то налицо вы можете пополнить счёт на произвольную сумму.

Подобный недочет со стороны робокассы можно исправить либо заменой md5 на другую функцию, либо же простым банальным переставлением sMerchantPass1 в конец строки.

Поправьте меня, если я написал чушь.

[@Nord001]

«Далее обновляете существующую md5-подпись, добавлением 0 (алгоритм генерации md5 позволяет добавлять в строчку символы). „
Это как это вы сделаете, не зная, sMerchantLogin и sMerchantPass1?

[@khovansky]

MerchantLogin-то, кстати, передается в запросе в открытую. Пароль, разумеется, скрыт. Хотя, такой подход вообще говорит о том, что технические пароли (MerchantPass1 и MerchantPass2) хранятся в БД плейнтекстом. Да и вообще, здорово это, количество фактических параметров запроса — на ладони, алгоритм формирования строки для подписи — вот он тут. Строка шифруется без соли, без всего, обычным одним проходом md5. Не внушает мне всё это доверия. Хотя я, возможно, параноик.

[@maximw]

Вы не параноик. По крайней мере, этого не следует из вашего комментария.

Вы просто не понимаете, что это не шифрование, а цифровая подпись. В нее включено значение sMerchantPass1 или sMerchantPass2 (зависит от типа запроса к робокассе). Эти два значения достаточно длинны для попытки их перебора. Они известны только магазину и Робокассе, и не передаются при обмене сообщениями. То, что они хранятся «плейнтекстом» — это так и должно быть. Сгенерировать без них новую подпись — невозможно за приемлемое время. Любое изменение в данных (даже порядок передачи в GET-запросе) приведет к несоответствию запроса его подписи.

[@vinograd19]

Для того, чтобы из строчки s+'0' сделать md5, нужно знать только md5 от строчки s.

[@Nord001]

Меня смущает фраза «алгоритм генерации md5 позволяет добавлять в строчку символы» то ли я что-то не знаю, то ли вы что-то путаете. Я всегда считал что это не так.

Можете на конкретном примере показать?

Например:
md5(1) = c4ca4238a0b923820dcc509a6f75849b
md5(10) = d3d9446802a44259755d38e6d163e820
md5(c4ca4238a0b923820dcc509a6f75849b0) = 8e0e21c3a3888fbb6c04d55a20459d3c

[@vinograd19]

from hashlib import md5

m1 = md5('10000')
print m1.hexdigest() 
# b7a782741f667201b54880c925faec4b

m2 = md5('1000')
m2.update('0')
print m2.hexdigest() 
# b7a782741f667201b54880c925faec4b

[@maximw]

А вас не смущает что m1 и m2 — объекты, которые, вероятно, хранят исходную хешируемую строку, что позволяет выполнять метод update()?

[@vinograd19]

Вики, хабр (секция про flickr)

[@maximw]

Да, я по-прежнему опасно некомпетентен в криптографии.

[@Nord001]

Огромное спасибо за разъяснение!

[@BarsMonster]

В данном случае вы правы, m2 хранит состояние.
Однако имея и конец хэшируемой строки, и конечное состояние md5 мы можем «откатить» внутреннее состояние md5 до того места, где мы сможем вставить новые данные. Таким образом мы можем получить новый хэш, не зная секретный префикс.

ОДНАКО! Это не позволяет добавить символы в строку не изменив MD5.

[@maximw]

Да, я уже понял. Прочитал ссылки из комментария vinograd19 от 21 октября 2013 12:29 про Length extension attack.

[@farcaller]

Например вот: github.com/danghvu/md5pad, это назвается Length-Extension Attack.

[@maximw]

У md5 есть такая уязвимость, о который вы говорите. Но ее практическое применение, тем более в каком-то интернет магазине — фантастика.

[@InteractiveTechnology]

Вы написали чушь. Каким образом вы собираетесь изменить этот самый md5 хэш не зная sMertchantPass1?

[@FireWind]

В смысле вы потеряете деньги из-за махинаций пользователя? Вы в любом случае получаете не меньше, чем готовы были получить, предоставив пользователю скидку на размер комиссии. Ну и что, что пользователю товар обойдется чуть дешевле при смене способа оплаты — вы то получаете всю сумму, которую готовы были получить по самому дорогому способу. Ну а сообразительному клиенту можно только поаплодировать за догадливость.
Странные люди — согласны на поступление выручки 100 руб если клиент заплатит комиссию 10 руб, но не согласны на 100 руб. если клиент заплатит комиссию 1 руб. В данном случае, клиент за счет сообразительности получит бонус 9 руб СВОИХ сэкономленных денег. Поймите, чем больше у вас довольных клиентов, пусть даже при таком нежданном бонусе, тем лучше для вашего бизнеса.
Вы же все равно работаете в плюс, ну а если вдруг получилось в минус, то долбайте своих маркетологов или кто там у вас цену считает.

[@happyproff]

На сколько я понял, речь шла о том, что после смены клиентом способа оплаты магазину придётся заплатить Робокассе бОльшую комиссию, чем рассчитывалось при генерации цены.

[@alexeyrom]

Нет, неправильно. Комиссия, наоборот, меньше.

[@khovansky]

Мой интерес здесь вовсе чисто технический, как разработчика. Заказчик устанавливает цены на свой товар для продажи в магазине, я создаю такой магазин, в котором возможно реализовывать этот товар по заданным ценам, однако ограничения в самой платформе не позволяют сделать это должным образом. Вот и всё. А сообразительные пользователи — это вообще прекрасно.

[@maximw]

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

[@GlumShadow]

9% при оплате банковской картой, это как то жирно, вам не кажется? Робокасса всегда была жадной…

[@Pelmen]

Я читал, что при использовании Робокассы бросают заказ порядка 70% покупателей.
Во-первых из-за увеличения суммы (набрал на одну сумму, а платить надо больше)
Во-вторых из-за недружественного интерфейса самой робокассы, люди в нём просто теряются.

Пока смотрю в сторону единой кассы. у кого есть опыт работы с ней или другими платёжными агрегаторами?

[@zikkuratvk]

Кстати тоже очень интересуют другие платежные агрегаторы.
смотрю еще:
sprypay
paysto

[@servekon]

Работаю с Payonline. Небольшая комиссия, продуманное api(нравится, что также можно отправлять дополнительные параметры, которые потом вернуться по callback).

[@NoN]

Личный опыт — за последние 4 года раз 10 платил через РК. И 2 раза в РК «Произошла ошибка», в банке «пули вылетели», в магазине — «счёт не оплачен». А дальше разоборки со всеми сторонами с пинг-понгом: банк делает покерфейс, РК старательно делает вид что техподдержки у неё нет вообще.

Мой нерепрезентативный опыт — 20% проблем при оплате и 100% отсутствия техподдержки. Теперь оплачиваю только через другие системы.

[@stifff]

Я правильно понимаю, что такая «проблема» возникает только если добровольно пытаться взвалить на «себя» бремя комиссии в процессе расчета стоимости?

[@khovansky]

Абсолютно верно.

[@stifff]

Но, с другой стороны, если мы взваливаем на себя комиссию, то должны быть морально готовы к тому, что придется возмещать самую большую из возможных (по закону Мерфи), а если возмещаем меньшую — это можно считать приятным бонусом.

Отсюда правило © — чужие риски ведут к дополнительному «попадалову».