Банальная XSS уязвимость на странице p2p переводов Фидобанка, позволяющая украсть cvv2 код пользователя

[@dinikin]

Вы правы, можно сформировать урл таким образом, что при нажатии на кнопку отправки перевода, данные карты отправлялись на сторонний сайт. Но если это по какой-то причине не удастся сделать злоумышленнику, украсть cvv2 ему будет проще

[@Homakov]

Если XSS еще можно понять и простить — банк же, ожидаемо что там сидят студенты не слыхавшие ни о HttpOnly ни о Secure флагах для куки.
Но хранить CVV совсем уж фейл и выход из профессии.

[@evgeny_boger]

Несколько лет назад эквайринг мастер-банка после оплаты пользователем присылал магазину первые 4 цифры номера карточки, последние 4 цифры номера карточки и… md5 от номера карточки. Даже без соли.
Пришлось удостовериться, что ответы не попадают случайно ни в какие логи на сервере.

[@GraDea]

То что поле cvv заполняется — не значит, что значение хранится на сервере. Можно использовать localStorage, например.

[@dinikin]

К сожалению не могу сейчас проверить, сервер возвращает 500-ю

[@Homakov]

>localStorage
>украинский банк

Нет, там в сессии, которая на сервере.

[@viperet]

CVV там судя по всему хранится в сессии, заполнил данные, ввел CVV 123, отправил. В другом окне открыл ссылку — CVV заполненый остался, при чем не из localStorage, а прямо HTML прописан. Открыл ссылку в приватной вкладке (или в другом браузере) CVV уже не заполнен.

[@dinikin]

Хех, меня банк по IP забанил, 500-ю возвращает, через hidemyass.com сайт грузится нормально

[@WraithOW]

Хакер заблокирован, клиенты в безопасности. Все ок!

[@webset]

А вдруг еще что-то найдете?

[@MyHabrahabr]

Проверил конфигурацию HTTPS. ВНЕЗАПНО, рейтинг А!

www.ssllabs.com/ssltest/analyze.html?d=pay.fidobank.ua

sslcheck.globalsign.com/ru/sslcheck?host=pay.fidobank.ua#91.208.52.155-srv-reg-cert-ssl-misc

Даже HSTS и SPDY в наличии. Во дают!

Список несущественных проблем:
— Сертификат SHA1
— Не включено OCSP-сшивание (механизм получения состояния сертификата от самого сайта, а не CA)
— Сервер отдаёт предпочтение шифрам на основе длины AES, а не его режима. В результате браузеры, которые не поддерживают 256-битный AEAD GCM (а это все, кроме Android 4.4 и Internet Explorer на Windows 8 / 10), используют 256-битный CBC + MAC, что признано «устаревшей технологией». Сервер должен в первую очередь отдавать предпочтение всем шифрам AEAD GCM.
habrastorage.org/files/65a/b83/603/65ab8360302b4738be7a74db84d8e5cf.png

[@batment]

Этой частью скорее всего занимался уже кто-то более квалифицированный.

[@mtp]

Странно, что в комментах не упомянули Мицгола.