Комментарии 37
Кстати, пинок ПБ сработал — прошло менее часа и первая уязвимость уже пофикшена. Оперативно. Вторую не проверял — больше манипуляций придется сделать
Интересно, в первом случае API принимает только int в качестве order_id или же можно засунуть что-то вроде Guid?
Спасибо за сигнал, меры приняты и уязвимости уже устранены.
Вопрос не по теме поста: нельзя никак сделать чтобы счета выставлялись в валюте указанной в магазине, а не в гривнах? Я в курсе что это вроде как требование укр. законодательства, но это очень странное поведение для клиентов: в магазине ценник в рублях/доларах/евро, в платежном интерфейсе ликпея тоже, а в итоге счет выставляется в гривнах.
Что ж вы так мало пишете?
Было бы интересно про айти отдел Приватбанка почитать из первых рук…
Было бы интересно про айти отдел Приватбанка почитать из первых рук…
То есть чтобы вы наконец исправили уязвимости понадобилось написать статью на хабр о том как их использовать? Даже не смотря на то что информация вам была передана еще несколько месяцев назад? Серьезно?
По второму пункту по-моему проще проверять формат transaction_id, там только цифры, в телефоне тоже только цифры, хотя это конечно только на стороне магазина делать нужно.
Посмотрел недавно API приёма платежей российских платёжных систем. Иногда за такое хочется взять и, извините, уе… уехать подальше от интернета.
Такое впечатление, что некоторые мелочи туда добавили прямо специально чтобы добавить граблей в реализацию.
Причем неочевидных граблей. Вскользь описанных граблей. Или совсем никак не описанных граблей. Причем у кого три версии API, количество граблей возрастает от версии к версии.
Веселее всего у динозара российских онлайн-платежей.
Параметр «тестовый режим», который
А) не входит в «хеш/дайждест счёта/платежа» (мало кто в здравом уме после прочтения документации этот флаг будет проверять )
Б) типа выключается в контрольной панели (на самом деле фиг, флаг в контрольной панели — всего лишь значение по-умолчанию), что нигде не написано
B) в любом режиме можно провести платёж описанной на сайте «тестовой» карточкой с номером 4222 2222 2222 2222/CVC123 (выключается, но где-то в дебрях, упоминание есть только в английской версии сайта).
Где-то году в 2010 я делал платёжный шлюз webmoney(и др., но этот самый популярный) для биллинга whmcs (и других), по договорённости с первыми пользователями и по сей день я получаю логи обо всех попытках «считерить».
За 4 года попыток «считерить» набралось более нескольких тысяч, если просуммировать рублёвые эквиваленты платежей (здесь учтены только те случаи, где мне известна оригинальная сумма платежа), это более 2млн рублей. И это только несколько довольно небольших предприятий.
Мораль такова: «Если вы владелец магазина, который принимает интернет-платежи, проверяйте транзакции руками, поскольку некоторые ПС работать головой уже, к сожалению, не в состоянии».
Может прямо сейчас у вас за спиной, а возможно и с ведома ваших сотрудников, неустановленные клиенты-физлица выносят, к примеру, диван за 200 тысяч.
Такое впечатление, что некоторые мелочи туда добавили прямо специально чтобы добавить граблей в реализацию.
Причем неочевидных граблей. Вскользь описанных граблей. Или совсем никак не описанных граблей. Причем у кого три версии API, количество граблей возрастает от версии к версии.
Веселее всего у динозара российских онлайн-платежей.
Параметр «тестовый режим», который
А) не входит в «хеш/дайждест счёта/платежа» (мало кто в здравом уме после прочтения документации этот флаг будет проверять )
Б) типа выключается в контрольной панели (на самом деле фиг, флаг в контрольной панели — всего лишь значение по-умолчанию), что нигде не написано
B) в любом режиме можно провести платёж описанной на сайте «тестовой» карточкой с номером 4222 2222 2222 2222/CVC123 (выключается, но где-то в дебрях, упоминание есть только в английской версии сайта).
Где-то году в 2010 я делал платёжный шлюз webmoney(и др., но этот самый популярный) для биллинга whmcs (и других), по договорённости с первыми пользователями и по сей день я получаю логи обо всех попытках «считерить».
За 4 года попыток «считерить» набралось более нескольких тысяч, если просуммировать рублёвые эквиваленты платежей (здесь учтены только те случаи, где мне известна оригинальная сумма платежа), это более 2млн рублей. И это только несколько довольно небольших предприятий.
Мораль такова: «Если вы владелец магазина, который принимает интернет-платежи, проверяйте транзакции руками, поскольку некоторые ПС работать головой уже, к сожалению, не в состоянии».
Может прямо сейчас у вас за спиной, а возможно и с ведома ваших сотрудников, неустановленные клиенты-физлица выносят, к примеру, диван за 200 тысяч.
Где-то я уже это видел :)
Эммм… А что, проверять входные данные и данные отправителя информации из источника, который вы не контролируете, уже перестало быть нормой в разработке???
Когда цепляю очередную ПС к сайту, всегда проверяю IP, все поля по регэкспам, и если удается договориться с самой ПС — еще вешаю https+basic auth на соответствующий стык.
Когда цепляю очередную ПС к сайту, всегда проверяю IP, все поля по регэкспам, и если удается договориться с самой ПС — еще вешаю https+basic auth на соответствующий стык.
Ну большинство нормальных разработчиков так и делает.
Догадайтесь, кто обычно «прикручивает платёжную систему» на небольших сайтах, правильно, фрилансер который меньше всех попросил*.
*) это не значит, что все фрилансеры, которые мало просят безответственные. Это значит, что таки просто часто попадаются.
Догадайтесь, кто обычно «прикручивает платёжную систему» на небольших сайтах, правильно, фрилансер который меньше всех попросил*.
*) это не значит, что все фрилансеры, которые мало просят безответственные. Это значит, что таки просто часто попадаются.
всегда проверяю IP
basic auth
Такие методы аналогичны использованию пластилина или скотча там, где обязательно нужно использовать саморезы или другие специализированные крепления.
Ну, да, конечно отлично будет, если ПС будет подписывать свои запросы закрытым ключом, со всеми вытекающими. Но левым IP-ам доступа к платежному http лучше не давать, чтобы вас за это место нельзя было особенно заddos-ить. Или я не прав?
И вы так со всеми «third-party» системами поступаете? И как в дальнейшем вы хотите мониторить изменения IP адресов для каждой системы? Это каждому маломальскому проекту понадобится отдельный сотрудник в штате, который этим будет заниматься, и то не факт что всегда всё актуально будет.
Против этого существуют более эффективные методы. Они так же используют блокировку по IP адресам, как один из факторов обеспечения безопасности, но чёрный список адресов формируется динамически при поступлении подозрительных запросов, и в редких случаях изменяется вручную.
Нельзя доверять вообще каким-либо запросам от «third-party» систем. После получения каких-либо запросов в вашу систему, вы должны сами запросить подтверждающие данные у «third-party» системы с определённого белого-адреса. И для такого общения систем часто достаточно лишь HTTPS. Посмотрите к примеру на протокол-авторизации OAuth — это отличный пример, как нужно поступать при реализации всех других схем общения различных систем.
за это место нельзя было особенно заddos-ить
Против этого существуют более эффективные методы. Они так же используют блокировку по IP адресам, как один из факторов обеспечения безопасности, но чёрный список адресов формируется динамически при поступлении подозрительных запросов, и в редких случаях изменяется вручную.
Нельзя доверять вообще каким-либо запросам от «third-party» систем. После получения каких-либо запросов в вашу систему, вы должны сами запросить подтверждающие данные у «third-party» системы с определённого белого-адреса. И для такого общения систем часто достаточно лишь HTTPS. Посмотрите к примеру на протокол-авторизации OAuth — это отличный пример, как нужно поступать при реализации всех других схем общения различных систем.
Какие-то ну уж очень «детские» ошибки, которые исправляются все разом — просто добавив на стороне callback-метода проведения платежа отправку запроса в API Liqpay для проверки статуса и суммы платёжной транзакции. Проверив статус и оплаченную сумму по определённой транзакции уже можно наплевать на махинации с подменой параметров.
Вообще магазину, как мне кажется, можно особо не заботиться, о том на сколько круто продуманы подписи создания платежа. Магазину от платёжной системы (ПС) важно только, что бы та позволила пользователю быстро и удобно оплатить определённую сумму. А если пользователь каким либо образом оплатил меньшую сумму, то такие махинации легко нейтрализуются одним лишь запросом проверки статуса и оплаченной суммы от ПС.
Поверьте, никто никогда на стороне магазина не будет делать проверки сразу после колбека. Причем отнюдь не из-за того, что подписанный колбек уже достаточен и не следует переносить свои проблемы на потребителей услуги, а из-за того, что этот функционал никогда, подчеркиваю, никогда не будет запрограммирован — это проверено. Программист со стороны магазина напишет минимально рабочий код, который выполняет задачу и все, дальше не его проблемы, а магазина.
И насчет небеспокойства магазинов относительно сверок вы тоже ошибаетесь. Почему платежи проводятся онлайн? Да потому, что и услуга зачастую оказывается онлайн. Вы окажете услугу злоумышленнику, а от банка не получите ни шиша. Так кому беспокоиться?
И насчет небеспокойства магазинов относительно сверок вы тоже ошибаетесь. Почему платежи проводятся онлайн? Да потому, что и услуга зачастую оказывается онлайн. Вы окажете услугу злоумышленнику, а от банка не получите ни шиша. Так кому беспокоиться?
этот функционал никогда, подчеркиваю, никогда не будет запрограммирован
— Не ради пиара, но мы об этом заботимся, т. е. есть всё таки исключения.
— Вообще, конечно, на такую печальную действительность наталкивают сами ПС. Другие, «правильные» ПС, предоставляют магазину возможность получать лишь событие об обновлении состояния платёжной транзакции предоставляя при этом лишь номер транзакции (внутренний номер транзакции в ПС). Т. е. такой колбек не говорит о том, что случилось событие успешной оплаты. А уже используя полученный номер, магазину нужно делать запрос в ПС, для того чтобы узнать, в каком состоянии сейчас находится транзакция и все данные о ней. Если бы так поступали не единичные ПС, а все, то программисту просто пришлось бы делать всегда правильно.
у вас плохой опыт. По умолчанию опытный программист реализует спецификацию (и читает ее полностью).
В целом странно, что кто-то проверяет что-то от Liqpay по order id. Для этого есть transaction id, она является идентефикатором платежа и соотв. проверки вокруг нее должны быть.
В целом странно, что кто-то проверяет что-то от Liqpay по order id. Для этого есть transaction id, она является идентефикатором платежа и соотв. проверки вокруг нее должны быть.
Небольшой оффтопик, но куда делись номера телефонов, которые возвращались в магазин через API после проведения оплаты?
Из-за таких багов, уже давно снял автоматическое обновление статуса товара, обрабатываю вручную по приходу СМС.
Можете ещё одну багу добавить. Или «особенность». Для отправки авторизационных и подтверждающих платежи sms используется шлюз, который запартнерен с парой мессенжеров. Если Вам удастся на номер клиента LiqPay зарегистрировать себе например Viber (нужен физический доступ к телефону клиента на 1-2 минуты), то после этого все авторризационные и платежные SMS от ликпея будут приходить не клиенту на телефон по SMS а Вам на комп/смартфон в Viber. Я им когда-то писал но службе безопасности пофик
Я им, кстати, раньше отправлял репорт об уязвимости на главной странице: если заходишь на privatbank.ua, он загружается без SSL, на что мне ответили, что это не уязвимость, а «общие рекомендации по безопасности», потому что «предусмотрена двухфакторная модель аутентификации пользователей [...], что позволяет надежно защитить счета клиентов даже в случае компрометации статического пароля». Т. е. пофиг что пароль угонят, у нас еще один есть? Какой смысл тогда в двухфакторности, если один из факторов вообще бесполезный? Не исправляли достаточно долго, несколько месяцев, сейчас уже исправили, поэтому можно и здесь написать.
Разработчикам на будущее: отправлять данные введенные пользователем через SSL недостаточно, форму тоже нужно загружать по SSL. В ином случае в страницу можно встроить любой JS-код или даже заменить её полностью. Все что для этого нужно — зайти в сети, контролируемой злоумышленником (например, подключившись к Wi-Fi точке в кафе).
Разработчикам на будущее: отправлять данные введенные пользователем через SSL недостаточно, форму тоже нужно загружать по SSL. В ином случае в страницу можно встроить любой JS-код или даже заменить её полностью. Все что для этого нужно — зайти в сети, контролируемой злоумышленником (например, подключившись к Wi-Fi точке в кафе).
С последним абзацем верно подметили. Не лишним будет об этом иногда напоминать коллегам-разработчикам. Ведь в наше время даже провайдеры не стесняясь внедряют чужеродные объекты на загружаемые страницы. Тому примеров даже на хабре можно найти много (вот к примеру).
Сообщения от магазина платежной системе и обратно от платежной системы магазину подписываются одним и тем же ключом?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Демонстрация уязвимостей в Liqpay