Комментарии 28
Думал, что увижу здесь какую-то статью по модели безопасности разделеления интересов или что-то вроде этого.
На самом деле все что вы написали это общие рекомендации для всех, и относится это не только к межпроектному взаимодействию, фактически оно здесь за уши притянуто.
На самом деле все что вы написали это общие рекомендации для всех, и относится это не только к межпроектному взаимодействию, фактически оно здесь за уши притянуто.
Согласен. Скорее, это вырезка из общих рекомендаций для межпроектного взаимодействия + указание на то, о чём надо думать в первую очередь.
Я думаю, это имеет некоторую ценность для разработчиков, которые сталкиваются с разработкой веб-сервисов впервые. Чтобы меньше было лажи (а лаже есть, о чём я и говорю в статье).
Я думаю, это имеет некоторую ценность для разработчиков, которые сталкиваются с разработкой веб-сервисов впервые. Чтобы меньше было лажи (а лаже есть, о чём я и говорю в статье).
Возможно, имело смысл разбить статью на несколько частей.
Уверен, за один раз осилили ее далеко не все
Уверен, за один раз осилили ее далеко не все
Да, это очевидная мысль. К сожалению, когда я начал писать заметку, я думал, что она получится раза в 2 короче. Потом я пообщался с несколькими разработчиками и понял, что люди в целом часто понимают «что-то», но цельной картины у них нет (например, даже касательно того, как же на самом деле работает https).
Поэтому пришлось кое-какие моменты увеличить в размере. Разбивать же заметку на 2-3 статьи — это отдельный не вполне простой труд, на это времени уже не нашлось (я прошу прощения, но се ля ви).
Кроме того, мне кажется, что многие вещи из верхней части статьи должны быть очевидны (а в статье они просто упорядочены), поэтому верхняя часть просто «пролистается» многими читателями.
Поэтому пришлось кое-какие моменты увеличить в размере. Разбивать же заметку на 2-3 статьи — это отдельный не вполне простой труд, на это времени уже не нашлось (я прошу прощения, но се ля ви).
Кроме того, мне кажется, что многие вещи из верхней части статьи должны быть очевидны (а в статье они просто упорядочены), поэтому верхняя часть просто «пролистается» многими читателями.
У Ассиста всё ещё хуже — там форма клиенте никак не подписана, и перед реальным платежом Ассист не делает контрольный запрос к магазину. Т. е. покупателю ничто не мешает изменить руками, скажем, сумму платежа, и Ассист примет этот платёж, поскольку не механизмов по проверке его корректности. А бедному магазину придётся потом вручную откатывать платёж с кучей документов, да ещё и с потерей комиссионных.
И да, этот механизм «работает» чуть ли не со дня основания Ассиста без изменений. Российский лидер интернет-платежей, не баран чихнул…
И да, этот механизм «работает» чуть ли не со дня основания Ассиста без изменений. Российский лидер интернет-платежей, не баран чихнул…
Довольно странно, что об этом мало информации в интернете. Если честно, я не удивлюсь, если разработчики нескольких магазинов «слепо» верят, что товар оплачен, если осуществился переход на ok_return_url. Среди сотен клиентов наверняка есть те, кто «не подумал».
Кстати, короткая заметка в Вашем блоге — чуть ли не единственное, что я могу вспомнить на эту тему.
Кстати, короткая заметка в Вашем блоге — чуть ли не единственное, что я могу вспомнить на эту тему.
Сколько видел магазинов — все доверяют return_url исключительно на уровне «Вам будет зачислено Х руб. в ближайшее время». Реальное зачисление проводится только по result_url.
Это наиболее актуально для магазинов, которые торгуют «сразу отгружаемой» информацией. Например, хостинги, доменные регистраторы или сервисы по продаже статей.
Кстати, сейчас задумался: я знаю одного доменного регистратора, который зачисляет деньги на счёт сразу (при оплате картой через Ассист). Называть не буду. Но, возможно, там всё хорошо: проверки реже, чем раз в 10 минут осуществлять можно. Если 2 клиента не попадают в 10-минутный промежуток, то всё относительно надёжно работает.
Кстати, сейчас задумался: я знаю одного доменного регистратора, который зачисляет деньги на счёт сразу (при оплате картой через Ассист). Называть не буду. Но, возможно, там всё хорошо: проверки реже, чем раз в 10 минут осуществлять можно. Если 2 клиента не попадают в 10-минутный промежуток, то всё относительно надёжно работает.
Вы прочтите внимательнее. О return_url тут речь вообще не идёт, Ассист просто слепо принимает любые платежи без проверки. А потом, да, он перекинет клиента обратно в магазин и магазин может быть даже и увидит, что вместо 1000$ клиент заплатил 1$. Но платёж всё равно уже произведён и ты теперь должен разбираться и с клиентом (с которого хоть доллар, но взят) и с Ассистом, чтобы откатить платёж. Хотя в нормальной системе платёж должен был быть проверен и отклонён ещё ДО реальной оплаты.
Да, я понял Вашу мысль. Моя фраза про return_url не была ответом на эту проблему.
Пуская принимает. Вам-то что? Вы сколько увидели денег в результате проверки (1$) — столько и зачисляйте на счёт. Сложно вести счёт пользователя? ну сделайте «бонусный счёт» с которого можно оплачивать покупку. Заплатил доллар — выбери товаров на доллар и мы тебе выдадим твой заказ. В чём проблема?
А юзер, если с него просили 1000, а он заплатил 1 — идёт в АССИСТ, выяснять, почему с него так мало денег сняли. Тут даже суппорт свой напрягать не стоит решением вопроса…
А юзер, если с него просили 1000, а он заплатил 1 — идёт в АССИСТ, выяснять, почему с него так мало денег сняли. Тут даже суппорт свой напрягать не стоит решением вопроса…
Чёрт его знает, почему. Может быть действительно, народ просто не понимает слабости протокола.
У Киберплата, кстати, 4 года назад тоже протокол был так себе: david-m.livejournal.com/772914.html (но хоть форма там подписывалась). Как сейчас — не знаю, вполне допускаю, что тоже ничего не изменилось.
У Киберплата, кстати, 4 года назад тоже протокол был так себе: david-m.livejournal.com/772914.html (но хоть форма там подписывалась). Как сейчас — не знаю, вполне допускаю, что тоже ничего не изменилось.
Хорошая статья. Последовательно и грамотно изложено, а объем информации
(В рамках курса по изучению «Криптографии» в университете, все вышеописанное изучается около года).
Более подробно и так же не менее интересно описано в книге Венбо Мао Современная криптография. Теория и практика, с кратким введением в эллиптические кривые (ГОСТ Р 34.11-94) и прочее… Только там читать побольше =)
Дмитрий, у Вас вверху статьи написано:
Защита (или отсутствие защиты) от различных типов атак демонстрируется на примере протоколов популярных сегодня систем: Assist, Cyberplat, WebMoney, ChronoPay, Robokassa и PayPal (платёжные системы), а также OpenID, OpenAuth, OAuth (децентрализованная аутентификация).
(В рамках курса по изучению «Криптографии» в университете, все вышеописанное изучается около года).
Более подробно и так же не менее интересно описано в книге Венбо Мао Современная криптография. Теория и практика, с кратким введением в эллиптические кривые (ГОСТ Р 34.11-94) и прочее… Только там читать побольше =)
Дмитрий, у Вас вверху статьи написано:
Защита (или отсутствие защиты) от различных типов атак демонстрируется на примере протоколов популярных сегодня систем: Assist, Cyberplat, WebMoney, ChronoPay, Robokassa и PayPal (платёжные системы), а также OpenID, OpenAuth, OAuth (децентрализованная аутентификация).
Извиняюсь… (не дописал)
не могли бы Вы, пожалуйста, снизу кратко подытожить в какой-нибудь сводной таблице «отсутствие защиты» у представителей вышеуказанных систем (у кого они имеются). Просто, тогда бы статья носила бы не тольго академический характер, но имела бы и непосредственную практическую ценность.
Спасибо.
не могли бы Вы, пожалуйста, снизу кратко подытожить в какой-нибудь сводной таблице «отсутствие защиты» у представителей вышеуказанных систем (у кого они имеются). Просто, тогда бы статья носила бы не тольго академический характер, но имела бы и непосредственную практическую ценность.
Спасибо.
Первое:
На самом деле всё сильно зависит от срока жизни заказа,
возможности его отзыва, реальных потерь и т.п. вещей.
Тут зависит от того, за что принимаем оплату.
Например пополнение счёта у оператора связи.
Никто не мешает через сутки откатить платёж. Издержки минимальны.
Приём средств в оплату игровых валют (WoW, Rappelz & etc...) — та же тема.
Продажа билетов — не видел получения билетов день в день.
Второе:
Ну и вы забыли про ежедневные отчёты и сверки по альтернативному каналу.
Нормальная бухгалтерия без этого вообще работать откажется. ;-)
Яндекс.Деньги, Вебмани, Робокасса — ежедневные отчёты.
Третье:
Вот лично я так и не понял, каким образом предлагается бороться с несовершенством протоколов платёжных систем или агрегаторов платежей? Сразу скажу — у всех есть дополнительные поля и прочие не обозначенные в документации вещи, которые можно под это дело использовать. Интересно что скажет именно автор статьи.
ЗЫ. Я не зануда, я просто с платёжками работаю более 7 лет во многих компаниях (много — это больше трёх). И с максимальным количеством платёжек. Слава богу вы ещё СМС-платежи не рассматривали. Там вообще швах полный как с логикой, так и с безопасностью. Причём ещё ДО ваших скриптов. :-)
На самом деле всё сильно зависит от срока жизни заказа,
возможности его отзыва, реальных потерь и т.п. вещей.
Тут зависит от того, за что принимаем оплату.
Например пополнение счёта у оператора связи.
Никто не мешает через сутки откатить платёж. Издержки минимальны.
Приём средств в оплату игровых валют (WoW, Rappelz & etc...) — та же тема.
Продажа билетов — не видел получения билетов день в день.
Второе:
Ну и вы забыли про ежедневные отчёты и сверки по альтернативному каналу.
Нормальная бухгалтерия без этого вообще работать откажется. ;-)
Яндекс.Деньги, Вебмани, Робокасса — ежедневные отчёты.
Третье:
Вот лично я так и не понял, каким образом предлагается бороться с несовершенством протоколов платёжных систем или агрегаторов платежей? Сразу скажу — у всех есть дополнительные поля и прочие не обозначенные в документации вещи, которые можно под это дело использовать. Интересно что скажет именно автор статьи.
ЗЫ. Я не зануда, я просто с платёжками работаю более 7 лет во многих компаниях (много — это больше трёх). И с максимальным количеством платёжек. Слава богу вы ещё СМС-платежи не рассматривали. Там вообще швах полный как с логикой, так и с безопасностью. Причём ещё ДО ваших скриптов. :-)
Я там выше уже ответил. Проблемы именно со «сразу отгружаемым товаром». Но Вы правы, в случае хостинга, например, откатить платёж и забанить сервер — плёвое дело. Если только кто-то и правда сверяет бухгалтерские документы с реальностью. Я лично не уверен в дисциплине мелких компаний.
>Вот лично я так и не понял, каким образом предлагается бороться с несовершенством протоколов платёжных систем или агрегаторов платежей?
Бороться с несовершенством протоколов никак не предлагается. Предлагается не верить слепо «ненадёжным» протоколам. Предлагается понимать, где кроется «ненадёжность». В некоторых случаях можно пробовать повышать надёжность — например, добавляя проверку сертификата к HTTPS-соединению (иногда это можно сделать и иногда это будет, скажем так, не совсем глупой затеей).
Ну и, что немаловажно, предлагается также не писать «плохие» протоколы, ежели кому-то из читателей вдруг придётся этим заниматься.
К сожалению, панацеи предложить не могу :)
>Вот лично я так и не понял, каким образом предлагается бороться с несовершенством протоколов платёжных систем или агрегаторов платежей?
Бороться с несовершенством протоколов никак не предлагается. Предлагается не верить слепо «ненадёжным» протоколам. Предлагается понимать, где кроется «ненадёжность». В некоторых случаях можно пробовать повышать надёжность — например, добавляя проверку сертификата к HTTPS-соединению (иногда это можно сделать и иногда это будет, скажем так, не совсем глупой затеей).
Ну и, что немаловажно, предлагается также не писать «плохие» протоколы, ежели кому-то из читателей вдруг придётся этим заниматься.
К сожалению, панацеи предложить не могу :)
Проблемы исключительно со «сразу отгружаемым товаром» — ок.
Согласен, с ним проблемы, но минимальные.
Если товар мелко-виртуальный (микро-платежи) — ущерб минимален.
Если товар крупный (основная оплата — макро-платежи пластиком), то тут уже надо закладываться изначально на фрод. Ибо он существует помимо взаимодействия агрегатор-магазин. Опять же — тут юридическое решение вопроса проще. Ибо товар куда-то доставлялся. ;-)
Насколько я знаю, проверка HTTPS-серртификата делается исключительно на стороне платёжной системы. В жизни не встречал реализации на стороне магазина.
Согласен, с ним проблемы, но минимальные.
Если товар мелко-виртуальный (микро-платежи) — ущерб минимален.
Если товар крупный (основная оплата — макро-платежи пластиком), то тут уже надо закладываться изначально на фрод. Ибо он существует помимо взаимодействия агрегатор-магазин. Опять же — тут юридическое решение вопроса проще. Ибо товар куда-то доставлялся. ;-)
Насколько я знаю, проверка HTTPS-серртификата делается исключительно на стороне платёжной системы. В жизни не встречал реализации на стороне магазина.
Не отмечен еще один краеугольный камень безопасности — транзакционность запросов. Все взаимодействие должно происходить в рамках транзакций, с возможностью отката, если на каком-то этапе произошел сбой. Это тоже вектор атаки, и он используется злоумышленниками. Естественно, должен проводиться аудит транзакций, особенно тех, которые не завершены. Также из-за особенностей работы в вебе, зависшие транзакции (когда не получен ответ от второй стороны), должны как-то обрабатываться, например откатываться по таймауту.
MD5 (который уже «сломали»)
А можно пруфлинк?
Имеется в виду нахождение коллизий. Немного в русской и английской Википедии написано: ru.wikipedia.org/wiki/MD5. Где ещё почитать — не помню.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Безопасность при межпроектном взаимодействии