Статьи

Сбербанк остановил массовую атаку на банковские карты россиян с Украины

Еще одна охуительная новость на сегодня: «Сбербанк остановил массовую атаку на банковские карты россиян с Украины»: https://iz.ru/1322170/2022-04-18/sberbank-ostanovil-massovuiu-ataku-na-bankovskie-karty-rossiian-s-ukrainy – и я как дед ща буду рассказывать истории из своей молодости.

 

Что произошло?

Сейчас множество интернет-магазинов и онлайн-сервисов используют «нативные» платежные виджеты. Что это такое? Это платежная форма на твоём сайте / в приложении, которая не подгружается из вне (со стороны эквайрера), а реализована штатными средствами сайта / приложения. Т.е. пользователь вводит данные своей карты именно на твоём сайте, а не в iframe или на отдельном сайте банковского учреждения. После этого, владелец сайта передаёт полученные данные карты покупателя в сервис эквайринга. Такой подход открывает огромное количество возможностей для дизайна платежной формы, чтобы красиво вписать её в твоё приложение или сайт.

По идее, сайты / приложения, которые используют подобные «нативные» платежные формы должны сертифицироваться на предмет соответствия стандарту безопасности «PCI DSS». Такая сертификация и должна защитить покупателей от подобных атак, ведь никто не мешает владельцу сайта попросту сохранить указанные платежные данные покупателя и использовать их по своему усмотрению или просто допустить утечку из-за своей некомпетентности.

Но что мы имеем в реальности? Всем похуй. Некоторое время назад я делал мобильное приложение для магазина цветов. Для оплат я взял первый попавшийся эквайринг, который:
А) имеет специалистов, которые умеют общаться по электронной почте
Б) отвечает хотя бы раз в сутки
Таким эквайрингом оказался Cloud Payments.

Их платежный виджет был тогда максимально уебанским, при попытке открыть его внутри приложения – вылазил поп-ап который имел огромные отступы справа и слева по 30%, при этом сама платежная форма полностью не залазила в этот самый поп-ап так, что покупатель попросту не мог ввести CVV. Я им написал об этом, типа или поправьте, или дайте какие-нибудь возможности для кастомизации. На что мне ответили «держи нативный виджет, ебись как хочешь» – подключили мне возможность работы с нативными платежными виджетами и скинули рабочий, уже настроенный под меня пример кода.

Естественно, никакой сертификации я не проходил, а покупатели вбивали карты именно в приложении – т.е. данные для каждой из этих карт можно было спокойно сохранять на сервере, а потом все эти карты без труда высосать до последнего рубля (ну или загнать в ебейший минус, если это кредитка).

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

Безопасными платежными формами можно называть только те, которые тянутся с сайта банка – это либо просто перенаправление на страницу, которая расположена на домене банка, либо какой-нибудь поп-ап, открывающий iframe с домена банка.

Второй способ обчистить кошельки раисян и отправить их деньги на поддержку збройних сил України – это рекарринг (recurring). Рекаррингом называют возможность «сохранить» карту для дальнейших покупок на этом сайте / сервисе.

Как ты понимаешь, в случае с «нативной» платежной формой – тебя уже ничего не спасет, при желании админ сайта спокойно сохранит данные твоей карты если захочет, даже если ты не устанавливал галку «сохранить карту». Если же админ не хочет хранить данные карты у себя, он спокойно может хранить твои карты на стороне эквайринга, передав в него признак того, что ты хочешь воспользоваться рекаррингом, опять же вне зависимости от того ставил ты галку или нет.

При использовании банковских платежных виджетов (не «нативных») ситуация чуть лучше – если ты не ставил галку «сохранить карту» она и не будет сохранена. Но здесь проблема в другом, большинство пользователей как-раз таки «сохраняет» карты на сайтах и сервисах, где они привыкли платить, тем более что зачастую эта галка отмечена по умолчанию, и покупатели даже не придают ей значения. А значение придавать стоит, т.к. обычно банки не используют 3D-Secure (подтверждение операции по СМС) для рекарринговых платежей. Поэтому владелец сайта / сервиса без труда может запустить процесс автоматического списания средств (допустим по 1 000 руб.) для каждого пользователя с сохранённой на стороне эквайрера банковской картой до тех пор, пока средства на этой карте не закончатся.

Поэтому, я рекомендую 10 раз подумать прежде чем при любой твоей оплате ставить галку «сохранить эту карту».

А вообще, единственным способом защитить твои деньги на карте от подобных атак являются ЛИМИТЫ. Сейчас каждый уважающий себя банк позволяет БЕСПЛАТНО выпускать виртуальные карты, некоторые банки позволяют даже несколько штук одновременно. Эти виртуальные карты вяжутся к счету основной карты (не важно, хоть к дебетовой, хоть к кредитной), но имеют другой номер карты, срок действия, CVV и свои лимиты.

Так ты можешь установить небольшой лимит (например, тыщ 10) для этой виртуальной карты, а при необходимости – увеличивать его. Если же ты спалишь карту на каком-нибудь заскамившемся ресурсе (или у тебя возникнут какие-либо подозрения в адрес того или иного ресурса) – ты просто блокируешь виртуалку и мгновенно выпускаешь новую.

Виртуалки – это не только безопасно, но и профитно! Почти все сервисы, которые предлагают какой-то пробный период сейчас требуют данные банковской карты, а после истечения триала ты должен успеть отказаться от этого сервиса, пока он автоматически не начал списывать бабки за свои услуги. С виртуалкой всё проще – привязал витуалку, получил триал, тут же заблокировал виртуалку. Пробный период закончился, выпустил новую виртуалку, зарегистрировал новый аккаунт, запустил новый триал и так пока не надоест (или пока совесть мучать не начнёт)

Может заинтересовать

Популярное