Киберсигурност за български онлайн магазини: практичен контролен лист за собственици
Alexander Sverdlov
Анализатор по сигурността
Най-важното накратко
- Онлайн магазинът е цел заради парите и данните на едно място. Картови данни, лични данни на хиляди клиенти и директен поток от плащания правят е-магазина по-атрактивен за нападател от обикновен корпоративен сайт. Повечето атаки са автоматични и не подбират по големина или известност.
- Пет типа атаки покриват почти всичко, което виждаме. Кражба на картови данни от страницата за плащане (skimming), пробив през администраторския панел, измами с фалшиви поръчки и върнати плащания, атаки за претоварване (DDoS) в пиковите дни и компрометиране през плъгин или тема. Контролният лист по-долу адресира всеки от тях.
- PCI DSS ви засяга дори ако не пипате картите. Ако приемате картови плащания, дължите минимална форма на съответствие (най-често самооценка SAQ A), дори когато плащането минава през Stripe, банка или друг доставчик. Правилната интеграция сваля голяма част от тежестта, но не я нулира.
- Платформата ви определя слабите места. WooCommerce и Magento се самохостват и вие отговаряте за всяка актуализация и плъгин; Shopify поема голяма част от инфраструктурната сигурност, но не и вашите пароли, приложения и тема. Защитата за всяка е различна.
- Кражбата на картови данни (Magecart) не личи на клиента. Зловреден код, инжектиран в страницата за плащане, чете номера на карти в реално време, докато магазинът работи нормално. Спира се с контрол на скриптовете, мониторинг на промени и заключен администраторски достъп.
- При пробив часовникът тръгва веднага. Изтичане на клиентски данни е нарушение по GDPR с 72-часов срок за уведомяване на КЗЛД. Подготвеният план за реакция е разликата между контролиран инцидент и хаос с глоби и загубени клиенти.
Преди няколко месеца ни писа собственик на онлайн магазин за домашни стоки с около 6 000 поръчки на месец. Клиенти му се обаждаха ядосани, че картите им са били използвани за измамни покупки скоро след пазаруване при него. Магазинът работеше безупречно, нищо видимо не беше счупено, продажбите си вървяха. "Не разбирам, сайтът работи, нищо не е хакнато." Проблемът беше точно в това: нищо не изглеждаше хакнато, защото добрата атака срещу е-магазин е невидима. В страницата за плащане беше инжектиран няколко реда код, който тихо копираше номера на картите към чужд сървър при всяка поръчка.
Това е реалността на сигурността в е-търговията. За разлика от обикновения корпоративен сайт, онлайн магазинът държи три неща, които нападателят иска наведнъж: картови данни в момента на плащане, база с лични данни на хиляди клиенти и директна връзка с пари. И за разлика от голяма банка, повечето български магазини нямат екип по сигурност, който да гледа какво се случва. Това ги прави идеална, лесна цел за автоматичните атаки, които сканират интернет денонощно.
Тази публикация е контролен лист за собственици и управители на български онлайн магазини, не за специалисти по сигурност. Ще минем през петте най-чести типа атаки, какво всъщност изисква PCI DSS, когато приемате карти, какво е специфично за WooCommerce, Magento и Shopify, как да спрете кражбата на картови данни от страницата за плащане и какво точно да направите, ако клиентски данни изтекат. Целта е да излезете с конкретен списък от действия, не с обща тревога.
Стъпка 1
Защо точно вашият онлайн магазин е на прицел
Първата грешка, която чуваме почти винаги, е "ние сме малки, защо някой ще ни напада". Логиката е човешка, но е грешна, защото предполага, че от другата страна седи човек, който избира жертви. В реалността повечето атаки срещу онлайн магазини са изцяло автоматични. Програми сканират милиони адреси в интернет, търсят познати слабости (стара версия на платформа, уязвим плъгин, отворен администраторски панел) и атакуват всичко, което съвпадне, без да гледат дали магазинът прави хиляда лева на месец или милион. За автоматичната атака вие не сте "малки", вие сте просто поредният съвпадащ адрес.
Втората причина е, че онлайн магазинът концентрира три ценни неща на едно място. Има директна връзка с пари (плащания, връщания, кредити), държи картови или платежни данни поне в момента на транзакцията и пази база с имена, адреси, телефони и история на поръчките на всичките си клиенти. Корпоративният сайт визитка няма нищо от това. Затова е-магазинът е по-скъпа цел и нападателят е готов да вложи повече, за да влезе, дори да автоматизира опитите си върху хиляди магазини едновременно.
Третата причина е специфична за пазара ни. Голяма част от българските онлайн магазини са построени бързо, на самохоствана платформа (най-често WooCommerce), от агенция, която след пускането вече не поддържа сигурността, и работят с десетки плъгини, които никой не актуализира. Това създава точно средата, в която автоматичните атаки процъфтяват: познат софтуер, стари версии, никой не гледа. Добрата новина е, че същата причина прави защитата постижима. Повечето пробиви минават през няколко предвидими врати и затварянето им не изисква нито голям бюджет, нито собствен екип по сигурност.
Стъпка 2
Петте типа атаки срещу български е-магазини
Почти всичко, което виждаме при българските онлайн магазини, се събира в пет типа атака. Ако разберете тези пет и затворите вратата за всеки, покривате огромната част от реалния риск. Ето ги, подредени по това колко често ги срещаме.
1. Кражба на картови данни от страницата за плащане (skimming / Magecart)
Нападателят инжектира няколко реда зловреден код в страницата за плащане. Кодът чете номера на картите, докато клиентът ги въвежда, и ги изпраща на чужд сървър. Магазинът работи напълно нормално, нищо не е счупено, и точно затова кражбата често остава незабелязана с месеци. Това е най-коварната атака срещу е-магазин и ѝ посвещаваме отделна стъпка по-долу.
2. Пробив през администраторския панел
Автоматизирани опити за вход с откраднати или слаби пароли (credential stuffing, brute force) срещу /wp-admin, Magento admin или акаунта ви в Shopify. Веднъж вътре, нападателят може да открадне данни, да инжектира код, да пренасочи плащания или да заключи магазина. Това е най-честата входна точка и същевременно най-лесната за затваряне: силни уникални пароли и задължителна двуфакторна автентикация (MFA) спират почти всички подобни опити.
3. Измами с плащания и върнати суми (fraud и chargeback)
Поръчки с откраднати карти, злоупотреба с промокодове и ваучери, фалшиви оплаквания за неполучена стока, които водят до върнати плащания (chargeback). Тук щетата е директно финансова и често удря малките магазини най-силно, защото нямат правила за проверка на рискови поръчки. Не е класически "хак", но е атака срещу парите ви и изисква контроли в самия процес на поръчка.
4. Атаки за претоварване (DDoS), често в пиковите дни
Магазинът се залива с фалшив трафик и спира да работи точно когато има най-много реални клиенти (Черен петък, празнични разпродажби). Понякога е чист саботаж, понякога е прикритие за друга атака, понякога е изнудване. Защитата минава през CDN и услуга за защита от DDoS пред магазина, които поемат удара, преди да стигне до сървъра ви.
5. Компрометиране през плъгин, тема или разширение
Уязвимост в неактуализиран плъгин, изоставена тема или пиратско разширение е една от най-честите врати към WooCommerce и Magento магазините. Често именно през тази уязвимост влиза кодът за кражба на карти от точка 1. Магазин с трийсет плъгина, половината от които не са обновявани от година, е отворена покана. Контролът тук е дисциплина по актуализации и редовно изчистване на ненужните добавки.
Стъпка 3
PCI DSS: какво ви засяга, ако приемате карти
PCI DSS (Payment Card Industry Data Security Standard) е стандартът за сигурност на картовите плащания, който се изисква от Visa, Mastercard и останалите картови оператори. Първата важна истина: PCI DSS ви засяга, ако приемате картови плащания, дори когато не съхранявате нито един номер на карта при себе си. Това изненадва много собственици на магазини, които смятат, че щом плащането минава през Stripe или банката, отговорността е изцяло тяхна. Не е. Вие носите минимална форма на съответствие винаги.
Втората важна истина: правилната интеграция сваля драстично тежестта. Нивото на изискванията се определя от това колко близо минават картовите данни до вашите системи. Това се изразява чрез така наречените въпросници за самооценка (SAQ, Self-Assessment Questionnaire). Колкото по-малко докосвате картовите данни, толкова по-кратък е въпросникът и по-лесно е съответствието. Ето основните сценарии за типичния български онлайн магазин.
| Как приемате картите | Типичен въпросник | Тежест за вас |
|---|---|---|
| Пълно пренасочване към доставчика (hosted page) | SAQ A | Най-ниска: картата се въвежда изцяло при доставчика |
| Вградено поле от доставчика на вашата страница (iframe) | SAQ A-EP | Средна: вашата страница влияе на сигурността на плащането |
| Картата минава през вашия сървър | SAQ D | Най-висока: пълен набор изисквания, рядко оправдано |
| Препоръка за повечето магазини | SAQ A | Изберете интеграция, при която не докосвате картови данни |
Практическият извод за повечето български магазини е ясен: използвайте интеграция, при която самото въвеждане на картата става изцяло при доставчика на плащания (банка, Stripe, регистриран процесор), а не на вашия сървър. Така попадате в най-леката категория, картовите данни никога не минават през вас и рискът от точка 1 (кражба на карти) рязко намалява. Това е архитектурно решение, което взимате веднъж и от което печелите трайно.
Важно уточнение за SAQ A: дори най-леката категория не означава "нищо за правене". Тя продължава да изисква силни пароли, контрол на достъпа, защитена връзка (HTTPS навсякъде) и поддържане на сигурни компоненти. SAQ A намалява обхвата, но не премахва задължението ви да поддържате самия магазин сигурен. Точно тук много собственици се успокояват погрешно и оставят вратите от Стъпка 2 отворени.
Кой ви иска доказателство за PCI DSS на практика? Най-често доставчикът ви на платежни услуги или банката, с която имате договор за приемане на карти. Те могат да поискат попълнен въпросник за самооценка веднъж годишно. Затова, преди да изберете платежен доставчик, питайте директно: коя SAQ категория ще ми се падне с вашата интеграция и какво точно ще трябва да попълвам. Добрият доставчик ще ви насочи към най-леката работеща опция.
Стъпка 4
Платформена специфика: WooCommerce, Magento и Shopify
Голяма част от сигурността ви зависи от това на каква платформа е магазинът. Ключовата разлика е кой носи отговорност за какво. При самохостваните платформи (WooCommerce, Magento) вие отговаряте за почти всичко: сървър, актуализации, плъгини, архиви. При хостваните (Shopify) платформата поема инфраструктурната сигурност, но не и вашите решения, пароли и приложения. Ето какво означава това на практика.
WooCommerce е най-разпространеният избор в България и същевременно носи най-голяма отговорност за вас. Понеже работи върху WordPress, наследява и неговите рискове: уязвими плъгини, слаби пароли в /wp-admin, изоставени теми. Тук дисциплината по актуализации е всичко. Минимумът: задължителна MFA за всеки администратор, редовно обновяване на ядрото и плъгините, изхвърляне на всичко неизползвано, ограничен достъп до /wp-admin и редовни архиви, които реално сте тествали да възстановявате.
Magento (включително Adobe Commerce) се ползва от по-големи магазини и е мощна, но сложна платформа. Сложността е и рискът: повече компоненти, повече разширения, повече за актуализиране. Magento изисква редовно прилагане на официалните пачове за сигурност (Magento често е била мишена на масови кампании за кражба на карти), стриктно управление на разширенията и обикновено отделен човек или партньор, който поддържа платформата. Ако имате Magento магазин, поддръжката на сигурността не е по избор, тя е постоянна задача.
Shopify прехвърля голяма част от тежестта върху себе си: инфраструктура, актуализации на ядрото, базова защита на плащанията. Това е реално предимство за сигурността. Но не ви освобождава от отговорност. Вашите слаби места при Shopify са: паролата и MFA на акаунта ви, правата на служителите, инсталираните приложения от трети страни (които могат да четат данни) и кода на персонализираната ви тема. Митът "на Shopify съм, значи съм защитен" е опасен точно защото е наполовина верен.
Стъпка 5
Как се спира кражбата на картови данни от страницата за плащане
Това е атаката от историята в началото и заслужава отделно внимание, защото е най-невидимата и най-скъпата за репутацията. Механизмът е прост и коварен. Нападателят влиза в магазина (през уязвим плъгин, слаба админ парола или компрометирано разширение) и инжектира няколко реда JavaScript в страницата за плащане. Този код тихо чете това, което клиентът въвежда в полето за карта, и го изпраща на чужд сървър в реално време. Магазинът продължава да работи нормално, плащането минава успешно, клиентът получава стоката. Нищо не изглежда нередно, а картите изтичат при всяка поръчка.
Точно защото нищо не е "счупено", тази атака често се открива едва когато банки или клиенти забележат вълна от измами, проследими до вашия магазин. Затова защитата е на два фронта: да не допуснете кода да влезе и да забележите бързо, ако все пак влезе.
Да не допуснете кода: затворете входните врати от Стъпка 2. Силни уникални пароли и MFA на всеки администратор, редовни актуализации на платформа и плъгини, изхвърляне на ненужните разширения, ограничен достъп до администраторския панел. Не приемайте картови данни на собствения си сървър (вижте SAQ A от Стъпка 3), за да намалите изобщо стойността на инжектиран код. Колкото по-малко чужд код се зарежда на страницата за плащане, толкова по-малко място има за скрита инжекция.
Да забележите кода: тук помагат няколко технически контрола, които си струва да поискате от разработчика или партньора си. Политика за съдържанието (Content Security Policy), която ограничава кои скриптове могат да се зареждат и къде могат да пращат данни. Subresource Integrity (SRI), който отказва да зареди външен скрипт, ако той е променен. Мониторинг на целостта на файловете и на скриптовете на страницата за плащане, който вдига аларма при всяка неочаквана промяна. И редовен преглед на това какъв код реално се зарежда при плащане.
Практически минимум за защита на плащането: картата се въвежда при доставчика, не при вас (SAQ A); страницата за плащане зарежда възможно най-малко външни скриптове; включена е политика за съдържанието (CSP); има мониторинг, който алармира при промяна в скриптовете; и админ достъпът е заключен с MFA. Този набор спира огромната част от кампаниите за кражба на карти срещу магазини като вашия.
Стъпка 6
Регулаторни изисквания и какво да правите при пробив на клиентски данни
Към техническата сигурност идват и задължения по закон. Най-важното за онлайн магазина е защитата на личните данни на клиентите по GDPR, който в България се прилага от Комисията за защита на личните данни (КЗЛД). Имената, адресите, телефоните и историята на поръчките на клиентите ви са лични данни и вие сте администратор на тези данни с всички произтичащи задължения. Това включва да ги пазите със съответни технически мерки (точно тези от контролния лист дотук) и да уведомите при пробив.
Що се отнася до картовите плащания, надзорът минава по две линии. Договорно, чрез вашия платежен доставчик и картовите оператори, които изискват PCI DSS съответствие (Стъпка 3). И регулаторно, чрез платежната регулация в ЕС, която налага силно удостоверяване на клиента (3-D Secure) при картови плащания онлайн. На практика това означава, че плащанията ви трябва да минават през 3-D Secure, което не само е изискване, но и сваля голяма част от измамите и chargeback-овете от Стъпка 2. Българската народна банка (БНБ) е надзорният орган за платежните услуги в страната, но за типичния онлайн магазин ежедневният партньор по тези изисквания е платежният доставчик или банката ви.
Сега най-важната част: ако клиентски данни изтекат, часовникът тръгва веднага. При пробив на лични данни GDPR изисква уведомяване на КЗЛД в рамките на 72 часа от установяването, а при висок риск за хората и уведомяване на самите засегнати клиенти. Подготвеният план е разликата между контролиран инцидент и паника. Ето какво да направите по часове.
| Период | Действие | Защо |
|---|---|---|
| Час 0-2 | Изолирайте: сменете админ паролите, прекъснете активните сесии, запазете логовете | Спирате достъпа на нападателя и пазите доказателствата |
| Час 2-12 | Оценете обхвата: какви данни, на колко клиенти, засегнати ли са карти | Определя задълженията ви за уведомяване и към кого |
| Час 12-24 | Уведомете платежния доставчик/банката, ако са засегнати карти | Те могат да блокират компрометирани карти и да ограничат щетата |
| До 72 часа | Уведомете КЗЛД за пробива на лични данни (ако има риск за хората) | Законов срок по GDPR; закъснението е отделно нарушение |
| След това | Уведомете засегнатите клиенти при висок риск; отстранете причината; повторен преглед | Запазвате доверието и предотвратявате повторение |
Три неща правят този план изпълним, когато стане напечено. Първо, подгответе го предварително: знайте кой звъни на кого, къде са логовете и кой ще говори с КЗЛД и с клиентите. Второ, имайте контакт за спешна техническа реакция, преди да ви потрябва, защото в час 0 не е моментът да търсите кой може да помогне. Трето, бъдете честни в комуникацията с клиентите: премълчан пробив, който излезе наяве, нанася много по-голяма репутационна щета от навременно и почтено уведомление.
И накрая, ключово прозрение: целият контролен лист дотук съществува, за да не стигнете изобщо до тази таблица. Заключеният админ достъп, актуалните плъгини, защитеното плащане и мониторингът са евтини в сравнение с цената на един реален пробив (глоба, загубени клиенти, разходи за разследване и възстановяване, спрени продажби в най-лошия момент). Превенцията е няколко добре подбрани мерки; възстановяването е скъпо и винаги идва точно когато най-малко може да си го позволите.
Често задавани въпроси
Въпросите, които чуваме от собственици на онлайн магазини
Малък онлайн магазин съм, наистина ли съм цел?
Да, и то точно защото повечето атаки са автоматични. Програми сканират интернет денонощно за магазини с познати слабости (стара версия на платформа, уязвим плъгин, отворен админ панел) и атакуват всичко, което съвпадне, без да гледат оборота. За автоматичната атака вие не сте "малки", а просто поредният съвпадащ адрес. Малките магазини често са по-уязвими именно защото нямат кой да следи сигурността, което ги прави по-лесна, не по-малко вероятна цел.
Плащанията ми минават през банка/Stripe. Засяга ли ме PCI DSS?
Да. Ако приемате картови плащания, дължите минимална форма на съответствие, дори когато не съхранявате нито един номер на карта. Добрата новина е, че при правилна интеграция (картата се въвежда изцяло при доставчика, не при вас) попадате в най-леката категория, SAQ A, която е кратък въпросник за самооценка. Това не ви освобождава от базовата сигурност (силни пароли, MFA, HTTPS, актуални компоненти), но сваля голяма част от тежестта. Питайте платежния си доставчик коя SAQ категория ви се пада с тяхната интеграция.
На Shopify съм, значи съм защитен, нали?
Само наполовина, и това е опасното. Shopify поема инфраструктурата, ядрото и базовата защита на плащанията, което е реално предимство. Но вашите слаби места остават изцяло за вас: паролата и MFA на акаунта, правата на служителите, приложенията от трети страни, които могат да четат данни, и кодът на персонализираната ви тема. Повечето пробиви при Shopify минават именно през тези ваши решения, не през платформата. На всяка платформа паролите, MFA и хората ви остават ваша отговорност.
Как да разбера дали картови данни изтичат от моя магазин?
Трудно е само по поведението на магазина, защото добрата атака е невидима: всичко работи нормално, плащанията минават. Затова разчитайте на технически контроли, не на усещане. Политика за съдържанието (CSP), която ограничава кои скриптове се зареждат, мониторинг на целостта на скриптовете на страницата за плащане, който алармира при промяна, и редовен преглед какъв код реално се зарежда при плащане. Ако получавате сигнали от банки или клиенти за измами скоро след пазаруване при вас, приемете го като сериозен симптом и проверете незабавно.
Колко струва да защитя онлайн магазина си?
По-малко, отколкото очаквате, и многократно по-малко от един реален пробив. Голяма част от защитата е дисциплина, не покупка: силни пароли и MFA, редовни актуализации, изхвърляне на ненужни плъгини, правилен избор на платежна интеграция. Платените елементи (CDN със защита от DDoS, мониторинг на скриптовете, периодичен преглед на сигурността от специалист) са в разумни месечни суми за повечето магазини. За сравнение, един инцидент с изтичане на картови данни носи глоби, разходи за разследване, загуба на клиенти и спрени продажби, които лесно надхвърлят годишния бюджет за сигурност.
Клиентски данни изтекоха. Какво да направя първо?
Първо изолирайте: сменете админ паролите, прекъснете активните сесии и запазете логовете за разследване. После оценете обхвата (какви данни, на колко клиенти, засегнати ли са карти), защото това определя кого трябва да уведомите. Ако са засегнати карти, уведомете платежния доставчик или банката бързо. При пробив на лични данни с риск за клиентите имате 72 часа да уведомите КЗЛД, а при висок риск и самите засегнати клиенти. Подгответе този план предварително и осигурете контакт за спешна техническа реакция, преди да ви потрябва.
Искате безплатен разговор за вашата конкретна ситуация? Свържете се с нас или пишете на alexander@atlantsecurity.com. Ще преценим заедно на каква платформа сте, как приемате картите и кои са най-спешните мерки за вашия магазин.
Александър Свердлов
Основател на Atlant Security. Автор на 2 книги за информационна сигурност, лектор по киберсигурност на най-големите конференции по киберсигурност в Азия и панелист на конференция на ООН. Бивш член на екипа за консултации по сигурността на Microsoft, външен консултант по киберсигурност в Емиратската корпорация за ядрена енергия.