Сигурност на плащанията: PCI и измами

Модул 6: Управление и сигурност · Време за четене: 11 минути

Учебна цел: След този урок ще можете да обясните защо един онлайн магазин никога не обработва сам данни от платежни карти, какво означават PCI DSS и SAQ A за малък магазин, как да защитите страницата за плащане и как да разпознаете и ограничите измамите и card testing.

Основни понятия: PCI DSS, данни от карти, доставчик на плащания, пренасочване към страницата за плащане, вграден платежен формуляр (iframe), SAQ A, скриптове на страницата за плащане, e-skimming, https, HSTS, card testing, rate limiting, captcha, 3-D Secure, възстановяване на плащане (chargeback), риск от измама

Данните от карти нямат място във Вашия магазин

Номерът на кредитната карта, срокът на валидност и кодът за сигурност са злато за престъпниците. Който ги съхранява или предава, попада под PCI DSS (Payment Card Industry Data Security Standard), стандарта за сигурност на картовите организации. Актуалната версия е v4.0.1. За фирма, която сама обработва данни от карти, това е голям пакет от изисквания: разделяне на мрежите, дневници, сканирания, тестове от акредитирана организация.

Малкият магазин не иска да попада в това и не е необходимо. Твърдото правило е: данните от карти никога не влизат във Вашия магазин. Клиентът ги въвежда при Вашия доставчик на плащания (Mollie, Stripe, PayPal, WooPayments или друг, урок 4.4). След това магазинът получава само информация: платено или не, с референтен номер. Без номер на карта, без код. Това означава също:

• никога не създавайте собствено поле във формуляр за номера на карти, дори "само за една поръчка по телефона";
• никога не приемайте данни от карти по имейл, чат или телефон и не ги записвайте в бележка към поръчката;
• не използвайте плъгин, който съхранява данни от карти в собствената Ви база данни.

Пренасочване или вграден формуляр: SAQ A

Малките магазини доказват, че отговарят на PCI DSS, с SAQ (Self-Assessment Questionnaire, въпросник за самооценка). Понякога доставчикът на плащания го изисква. Най-лекият е SAQ A, за магазини, които изцяло възлагат плащането на външен доставчик. В един магазин това работи по два начина:

1. Пренасочване. След "поръчване" клиентът отива на страницата за плащане на доставчика и след това се връща. Магазинът никога не вижда данните от картата, нито страницата, на която те се въвеждат.
2. Вграден формуляр. Полето за плащане е на Вашата страница за плащане, но е iframe (част от страница) на доставчика. Данните от картата отиват директно от браузъра към доставчика.

От 31 март 2025 г. важи нова версия на SAQ A. В нея има условие, което засяга най-вече втория начин: който използва вграден формуляр, трябва да потвърди, че сайтът му не е уязвим за атаки със скриптове, които могат да засегнат платежната система. Причината е e-skimming: зловреден скрипт на страницата за плащане, който чете какво въвежда клиентът или поставя фалшиво поле за плащане върху истинското. Който пренасочва към страницата на доставчика, не попада под това условие. Попитайте Вашия доставчик на плащания кой SAQ важи за Вашата интеграция; той знае точно.

Какво правите във всеки случай:

• Дръжте страницата за плащане максимално изчистена. Всеки скрипт на тази страница по принцип може да чете въведеното: чат уиджети, tag manager, рекламни пиксели, инструменти за A/B тестове. Зареждайте на страницата за плащане само това, което е нужно за плащането. Tag manager на страницата за плащане е врата, през която всеки с достъп до този акаунт може да добавя скриптове.
• Малко плъгини, и то актуализирани (урок 6.2). Повечето случаи на e-skimming в WordPress влизат през пробив в плъгин или откраднатата парола на администратор.
• Content-Security-Policy (заглавен ред, който указва от кои домейни могат да идват скриптове) ограничава щетите, ако все пак нещо проникне. Това е работа за човек, който може да я тества; грешна CSP разваля бутона Ви за плащане.

https и HSTS на страницата за плащане

Целият Ви магазин естествено работи през https (курс за WordPress, урок 3.1). За страницата за плащане се добавят две неща:

• http трябва веднага да пренасочва към https с постоянно пренасочване (301 или 308). Клиент, който някога въведе http://shop.example.com/afrekenen/, не бива да получи некриптирана страница.
• HSTS (HTTP Strict Transport Security) е заглавен ред, с който казвате на браузъра да отваря сайта Ви известно време само през https. Така предотвратявате някой в отворена Wi-Fi мрежа да прихване първата некриптирана заявка. max-age от поне 180 дни е обичаен минимум. Включете HSTS едва когато всичко, включително поддомейните, които обхващате, работи през https: браузър, който е видял HSTS, след това отказва http. KB 6752 обяснява как да го настроите.

Смесеното съдържание (скрипт или stylesheet през http на https страница) на страницата за плащане е особено опасно: точно такъв файл може да бъде подменен по пътя.

Card testing

При card testing престъпниците използват Вашия магазин, за да пробват откраднати номера на карти. Те автоматично правят стотици малки поръчки. Всяко успешно плащане им показва, че дадена карта работи. Вие получавате купчина неуспешни поръчки, такси за транзакции, възстановени плащания и в най-лошия случай доставчик на плащания, който блокира акаунта Ви.

Как да го разпознаете: много поръчки за кратко време, често на един и същ евтин продукт, с различни имена, но еднакви или странни адреси, и много поръчки със статус Неуспешно.

Как да го ограничите:

• Rate limiting (ограничение на броя заявки за определено време). Store API на WooCommerce, който се използва от блоковете за количката и плащането, има вграден rate limiting, но той е изключен по подразбиране. В WooCommerce > Настройки > Разширени > Характеристики можете да включите "Rate limiting Checkout block and Store API" за правенето на поръчки. С код (филтър) можете сами да зададете границата; по подразбиране тя е 25 заявки за 10 секунди и се броят само поръчките и другите действия за запис. Ако магазинът Ви е зад прокси или CDN, трябва да включите поддръжката на прокси, иначе всички посетители се броят като един.
• Captcha или подобна преграда при плащането. Самият WooCommerce казва, че rate limiting и captcha работят най-добре заедно: нападателите често сменят IP адреса си.
• Настройките на Вашия доставчик на плащания. Доставчиците имат собствени филтри срещу измами и лимити. Включете ги и следете какво докладват.
• 3-D Secure (допълнителното потвърждение в банковото приложение, част от задълбоченото установяване на идентичността на клиента в ЕС) затруднява престъпниците и при спор често прехвърля отговорността към банката на картодържателя.

Други измами

Не всяка измама е автоматизирана. Сигнали, които взети заедно са причина да изчакате малко с изпращането:

• адрес за фактуриране и адрес за доставка в различни държави или адрес за доставка при услуга за препращане на пратки;
• първа поръчка само със скъпи, лесни за препродажба продукти, с експресна доставка;
• няколко опита с различни карти;
• клиент, който след плащането иска пратката да бъде изпратена на друг адрес.

Възстановяване на плащане (chargeback) е отмяна на плащане с карта от банката на клиента. Губите сумата, често и такси, а продуктът вече го няма. Затова пазете доказателства за изпращането и доставката. Плащане с iDEAL досега не можеше да бъде отменено по този начин; как стоят нещата при Wero, ще научите от Вашия доставчик на плащания (урок 4.4). В България обичайни методи за плащане са наложен платеж, карта и банков превод; при плащане с карта рискът от chargeback важи и там.

Обобщение

• Данните от карти никога не влизат във Вашия магазин: нито във формуляри, нито в бележки или имейли. Обработва ги доставчикът на плащания.
• Пренасочването към страницата за плащане или вграденото поле на доставчика Ви държи в най-лекия въпросник по PCI (SAQ A); при вградено поле страницата Ви за плащане трябва да е защитена срещу атаки със скриптове.
• Дръжте страницата за плащане изчистена, през https с 301 от http и с HSTS от поне 180 дни.
• Card testing ограничавате с rate limiting (изключен по подразбиране), captcha и филтрите на Вашия доставчик.
• Следете за сигнали за измама и пазете доказателства за доставката срещу възстановяване на плащания; за магазин в България това важи особено при плащане с карта, наред с наложен платеж и банков превод.

Тест (quiz)

Задача

Задача A6.3: Безопасна ли е Вашата страница за плащане? Въведете адреса на магазина си и адреса на страницата за плащане. Програмата проверява сертификата, зарежда страницата за плащане през http (без да следва пренасочването) и през https (с празна количка, нищо не се поръчва). Зелено, ако сертификатът е валиден, http пренасочва с 301 или 308 към https, заглавният ред Strict-Transport-Security има max-age от поне 180 дни, няма смесено съдържание и най-много пет други домейна зареждат скриптове на страницата (програмата ги показва). Оранжево при липсващ или твърде кратък HSTS, временно пренасочване (302 или 307), повече от пет домейна със скриптове или tag manager, или поле за номер на карта в собствения HTML вместо при доставчика. Червено, ако https или сертификатът не са наред, http не пренасочва или скриптове или stylesheets се зареждат през http. Никога не съхранявайте сами данни от карти. Тази проверка вижда само това, което е на страницата без количка.

Въпрос към Вас (не се проверява): пренасочва ли Вашият платежен плъгин към доставчика, или полето за плащане е на Вашата страница? Кой SAQ според доставчика Ви важи за Вас?

Зелената отметка означава, че тази проверка в момента е наред, а не че магазинът Ви е безопасен.

Прочетете още

Стъпките в панела важат за WebOké; при други доставчици работи по подобен начин.

• Безплатен курс по WordPress 3.1: https и сертификатът
• HSTS и защитни headers за Вашия уебсайт
• Задължително пренасочване на посетителите към https
• Ръководство за DirectAdmin 6.4: Посетителите винаги да се пренасочват към https
• Безплатен курс Безопасно онлайн за предприемачи 4.2: Вашият уебсайт: https, HSTS и защитни заглавни редове @@ОМСКРИВАНЕ@@
• Промени в SAQ A (PCI Security Standards Council, на английски): https://blog.pcisecuritystandards.org/important-updates-announced-for-merchants-validating-to-self-assessment-questionnaire-a
• Rate limiting за Store API (developer.woocommerce.com, на английски): https://developer.woocommerce.com/docs/apis/store-api/rate-limiting/
• Card testing attacks and the Store API (developer.woocommerce.com, на английски): https://developer.woocommerce.com/2024/12/18/card-testing-attacks-and-the-store-api/
• Сигурност на плащанията във Вашия онлайн магазин: PCI, card testing и какво прави Вашият хостинг доставчик