Comments 31
А робокассе то это сообщили, точнее прошло ли какое-то время после уведомления? А то античат получается.
В shp параметрах там тоже небольшая дыра. Из документации (ссылка), для оплаты, пользователя переносят на сайт робокассы post-запросом. Одним из данных формы является md5-подпись, которая берется от строки «sMerchantLogin:nOutSum:nInvId:sMerchantPass1:shpa=yyy:shpb=xxx». Казалось бы, при заданных параметрах, магазин делает md5 подпись, и мы никаким образом не может составить другую валидную подпись для других параметров. Однако это не совсем верно. Если магазин запихивает в shp-параметры какие-то важные параметры (как например «оплаченную сумму»), воздействовать на них можно так: допустим shpb=1000. Вы тупо добавляете лишний 0, и получаете строчку с shpb=10000. Далее обновляете существующую md5-подпись, добавлением 0 (алгоритм генерации md5 позволяет добавлять в строчку символы). Если на стороне магазина скрипт не проверяет, что же там было в присланной «OutSum», то налицо вы можете пополнить счёт на произвольную сумму.
Подобный недочет со стороны робокассы можно исправить либо заменой md5 на другую функцию, либо же простым банальным переставлением sMerchantPass1 в конец строки.
Поправьте меня, если я написал чушь.
Подобный недочет со стороны робокассы можно исправить либо заменой md5 на другую функцию, либо же простым банальным переставлением sMerchantPass1 в конец строки.
Поправьте меня, если я написал чушь.
«Далее обновляете существующую md5-подпись, добавлением 0 (алгоритм генерации md5 позволяет добавлять в строчку символы). „
Это как это вы сделаете, не зная, sMerchantLogin и sMerchantPass1?
Это как это вы сделаете, не зная, sMerchantLogin и sMerchantPass1?
MerchantLogin-то, кстати, передается в запросе в открытую. Пароль, разумеется, скрыт. Хотя, такой подход вообще говорит о том, что технические пароли (MerchantPass1 и MerchantPass2) хранятся в БД плейнтекстом. Да и вообще, здорово это, количество фактических параметров запроса — на ладони, алгоритм формирования строки для подписи — вот он тут. Строка шифруется без соли, без всего, обычным одним проходом md5. Не внушает мне всё это доверия. Хотя я, возможно, параноик.
Вы не параноик. По крайней мере, этого не следует из вашего комментария.
Вы просто не понимаете, что это не шифрование, а цифровая подпись. В нее включено значение sMerchantPass1 или sMerchantPass2 (зависит от типа запроса к робокассе). Эти два значения достаточно длинны для попытки их перебора. Они известны только магазину и Робокассе, и не передаются при обмене сообщениями. То, что они хранятся «плейнтекстом» — это так и должно быть. Сгенерировать без них новую подпись — невозможно за приемлемое время. Любое изменение в данных (даже порядок передачи в GET-запросе) приведет к несоответствию запроса его подписи.
Вы просто не понимаете, что это не шифрование, а цифровая подпись. В нее включено значение sMerchantPass1 или sMerchantPass2 (зависит от типа запроса к робокассе). Эти два значения достаточно длинны для попытки их перебора. Они известны только магазину и Робокассе, и не передаются при обмене сообщениями. То, что они хранятся «плейнтекстом» — это так и должно быть. Сгенерировать без них новую подпись — невозможно за приемлемое время. Любое изменение в данных (даже порядок передачи в GET-запросе) приведет к несоответствию запроса его подписи.
Для того, чтобы из строчки s+'0' сделать md5, нужно знать только md5 от строчки s.
Меня смущает фраза «алгоритм генерации md5 позволяет добавлять в строчку символы» то ли я что-то не знаю, то ли вы что-то путаете. Я всегда считал что это не так.
Можете на конкретном примере показать?
Например:
md5(1) = c4ca4238a0b923820dcc509a6f75849b
md5(10) = d3d9446802a44259755d38e6d163e820
md5(c4ca4238a0b923820dcc509a6f75849b0) = 8e0e21c3a3888fbb6c04d55a20459d3c
Можете на конкретном примере показать?
Например:
md5(1) = c4ca4238a0b923820dcc509a6f75849b
md5(10) = d3d9446802a44259755d38e6d163e820
md5(c4ca4238a0b923820dcc509a6f75849b0) = 8e0e21c3a3888fbb6c04d55a20459d3c
from hashlib import md5
m1 = md5('10000')
print m1.hexdigest()
# b7a782741f667201b54880c925faec4b
m2 = md5('1000')
m2.update('0')
print m2.hexdigest()
# b7a782741f667201b54880c925faec4b
А вас не смущает что m1 и m2 — объекты, которые, вероятно, хранят исходную хешируемую строку, что позволяет выполнять метод update()?
В данном случае вы правы, m2 хранит состояние.
Однако имея и конец хэшируемой строки, и конечное состояние md5 мы можем «откатить» внутреннее состояние md5 до того места, где мы сможем вставить новые данные. Таким образом мы можем получить новый хэш, не зная секретный префикс.
ОДНАКО! Это не позволяет добавить символы в строку не изменив MD5.
Однако имея и конец хэшируемой строки, и конечное состояние md5 мы можем «откатить» внутреннее состояние md5 до того места, где мы сможем вставить новые данные. Таким образом мы можем получить новый хэш, не зная секретный префикс.
ОДНАКО! Это не позволяет добавить символы в строку не изменив MD5.
Например вот: github.com/danghvu/md5pad, это назвается Length-Extension Attack.
У md5 есть такая уязвимость, о который вы говорите. Но ее практическое применение, тем более в каком-то интернет магазине — фантастика.
В смысле вы потеряете деньги из-за махинаций пользователя? Вы в любом случае получаете не меньше, чем готовы были получить, предоставив пользователю скидку на размер комиссии. Ну и что, что пользователю товар обойдется чуть дешевле при смене способа оплаты — вы то получаете всю сумму, которую готовы были получить по самому дорогому способу. Ну а сообразительному клиенту можно только поаплодировать за догадливость.
Странные люди — согласны на поступление выручки 100 руб если клиент заплатит комиссию 10 руб, но не согласны на 100 руб. если клиент заплатит комиссию 1 руб. В данном случае, клиент за счет сообразительности получит бонус 9 руб СВОИХ сэкономленных денег. Поймите, чем больше у вас довольных клиентов, пусть даже при таком нежданном бонусе, тем лучше для вашего бизнеса.
Вы же все равно работаете в плюс, ну а если вдруг получилось в минус, то долбайте своих маркетологов или кто там у вас цену считает.
Странные люди — согласны на поступление выручки 100 руб если клиент заплатит комиссию 10 руб, но не согласны на 100 руб. если клиент заплатит комиссию 1 руб. В данном случае, клиент за счет сообразительности получит бонус 9 руб СВОИХ сэкономленных денег. Поймите, чем больше у вас довольных клиентов, пусть даже при таком нежданном бонусе, тем лучше для вашего бизнеса.
Вы же все равно работаете в плюс, ну а если вдруг получилось в минус, то долбайте своих маркетологов или кто там у вас цену считает.
На сколько я понял, речь шла о том, что после смены клиентом способа оплаты магазину придётся заплатить Робокассе бОльшую комиссию, чем рассчитывалось при генерации цены.
Мой интерес здесь вовсе чисто технический, как разработчика. Заказчик устанавливает цены на свой товар для продажи в магазине, я создаю такой магазин, в котором возможно реализовывать этот товар по заданным ценам, однако ограничения в самой платформе не позволяют сделать это должным образом. Вот и всё. А сообразительные пользователи — это вообще прекрасно.
А если запустить вирусную рекламу, что этот магазин можно обдурить таким вот нехитрым способом, то у потенциальных покупателей появится крайне заманчивый мотив купить что-то в этом магазине. Народ у нас падкий на халяву, но на возможность обдурить еще больше.
9% при оплате банковской картой, это как то жирно, вам не кажется? Робокасса всегда была жадной…
Я читал, что при использовании Робокассы бросают заказ порядка 70% покупателей.
Во-первых из-за увеличения суммы (набрал на одну сумму, а платить надо больше)
Во-вторых из-за недружественного интерфейса самой робокассы, люди в нём просто теряются.
Пока смотрю в сторону единой кассы. у кого есть опыт работы с ней или другими платёжными агрегаторами?
Во-первых из-за увеличения суммы (набрал на одну сумму, а платить надо больше)
Во-вторых из-за недружественного интерфейса самой робокассы, люди в нём просто теряются.
Пока смотрю в сторону единой кассы. у кого есть опыт работы с ней или другими платёжными агрегаторами?
Кстати тоже очень интересуют другие платежные агрегаторы.
смотрю еще:
sprypay
paysto
смотрю еще:
sprypay
paysto
Личный опыт — за последние 4 года раз 10 платил через РК. И 2 раза в РК «Произошла ошибка», в банке «пули вылетели», в магазине — «счёт не оплачен». А дальше разоборки со всеми сторонами с пинг-понгом: банк делает покерфейс, РК старательно делает вид что техподдержки у неё нет вообще.
Мой нерепрезентативный опыт — 20% проблем при оплате и 100% отсутствия техподдержки. Теперь оплачиваю только через другие системы.
Мой нерепрезентативный опыт — 20% проблем при оплате и 100% отсутствия техподдержки. Теперь оплачиваю только через другие системы.
Я правильно понимаю, что такая «проблема» возникает только если добровольно пытаться взвалить на «себя» бремя комиссии в процессе расчета стоимости?
Sign up to leave a comment.
Как обмануть Робокассу