Jakie zagrożenia czyhają na sklep internetowy?

Prowadząc sklep internetowy, korzystasz właściwie ze wszystkich mechanizmów typowych dla zwykłej strony WWW, ale dokładasz do nich kolejne elementy: konto klienta, koszyk, zamówienia, płatności, rabaty, stany magazynowe oraz integracje z zewnętrznymi usługami. Sklep nie tylko wyświetla treść, ale również przyjmuje dane od użytkownika, przetwarza je, wykonuje określone operacje i komunikuje się z systemami płatności, firmami kurierskimi czy zewnętrznymi API. To oznacza, że potencjalnym celem ataku nie jest już sama strona albo znajdujące się na serwerze pliki. Dla napastnika wartość może mieć konto Twojego klienta, historia jego zamówień, proces płatności, kod rabatowy albo możliwość wykorzystania błędu, który pozwoli kupić produkt taniej, zablokować jego dostępność czy wykonać setki automatycznych operacji w ciągu kilku sekund.

Nie oznacza to, że prowadząc sklep internetowy, każdego dnia odpierasz wszystkie możliwe rodzaje cyberataków. Dobrze jednak wiedzieć, gdzie kończą się zagrożenia charakterystyczne dla każdej strony WWW, a gdzie zaczynają się problemy wynikające bezpośrednio z tego, że za pomocą strony sprzedajesz produkty, przyjmujesz płatności i obsługujesz konta klientów.

Zanim przejdziesz dalej, przeczytaj: Jakie zagrożenia czyhają na stronę internetową? Wyjaśniamy tam podstawowe zagrożenia dla strony WWW, a wszystkie one dotyczą również sklepów internetowych. Dlatego tutaj skupimy się na tym, co charakterystyczne dla e-commerce.

• Sklep internetowy to więcej niż strona WWW
  • Płatności i checkout
  • Konta klientów i dane
  • Koszyk, rabaty i inne mechanizmy sprzedaży
• Nie wszystko jest zagrożeniem w tym samym znaczeniu
• Jak chronić sklep internetowy?
• Monarx jako jedna z warstw ochrony sklepu

Sklep internetowy to więcej niż strona WWW

Jeżeli ktoś wykorzystuje podatność SQL Injection, próbuje wykonać kod na serwerze, umieszcza web shell albo infekuje pliki złośliwym oprogramowaniem, sam mechanizm ataku nie zmienia się tylko dlatego, że zaatakowana witryna jest sklepem WooCommerce, PrestaShop czy inną platformą sprzedażową. Nie ma więc sensu drugi raz tworzyć tej samej listy zagrożeń.

W sklepie pojawia się jednak coś więcej:

• możliwość składania zamówień,
• dokonywania płatności,
• korzystania z kont klientów,
• zmiany zawartości koszyka,
• stosowania voucherów
• czy rezerwowania dostępnego towaru.

Właśnie w tych miejscach powstają scenariusze charakterystyczne dla e-commerce i nie zawsze przypominają one klasyczne włamanie.

Możesz zadać sobie proste pytanie:

• po co ktoś miałby atakować właśnie Twój sklep?

Przecież nie przechowujesz tajnych dokumentów ani kodów do systemów wojskowych. Sprzedajesz buty, zabawki, części samochodowe, kosmetyki albo karmę dla psa. Razem z tymi produktami obsługujesz jednak pieniądze, dane klientów, adresy dostawy, historię zakupów, konta użytkowników i mechanizmy pozwalające wpływać na przebieg transakcji. Nawet niewielki sklep przetwarza więc informacje i udostępnia funkcje, które dla kogoś innego mogą mieć konkretną wartość.

Wyobraź sobie teraz, że każdy z tych elementów może stać się osobnym celem. Ktoś może próbować przejąć konto klienta, pozyskać jego dane, wykorzystać sklep do sprawdzania cudzych kart, wpłynąć na wysokość płatności, użyć kodu rabatowego niezgodnie z jego przeznaczeniem albo zablokować dostępność produktu bez zamiaru jego zakupu. Możliwych scenariuszy są dziesiątki i nie ma większego sensu rozpisywać wszystkich rzeczy, które mogą wydarzyć się później. Z punktu widzenia przestępcy najprostszą motywacją pozostają oczywiście pieniądze, ale droga do nich nie musi prowadzić przez klasyczne przejęcie całego sklepu.

Dane kart płatniczych są dziś często obsługiwane poza samym sklepem przez zewnętrznych operatorów płatności, co ogranicza zakres informacji przetwarzanych bezpośrednio przez sprzedawcę.

Nie oznacza to jednak, że checkout przestaje być interesującym miejscem ataku. Nadal można próbować ingerować w proces płatności, przekierować klienta, wykorzystać złośliwy skrypt, fałszować określone parametry albo po prostu nadużywać mechanizmów, które sklep udostępnia każdemu kupującemu.

Przyjrzyjmy się więc zagrożeniom, które pojawiają się właśnie dlatego, że strona internetowa staje się sklepem. Podobnie jak w naszym artykule o zagrożeniach dla stron WWW, pokażemy konkretne scenariusze, ale nie będziemy tworzyć katalogu wszystkich możliwych konsekwencji. W większości przypadków już sam opis problemu pozwoli Ci bez większego trudu wyobrazić sobie, co może wydarzyć się później.

Na hostingu SEOHOST działa kilka uzupełniających się warstw ochrony. Monarx Security analizuje pliki, aktywność aplikacji PHP oraz wybrane zdarzenia związane z ruchem, WAF pomaga filtrować podejrzane żądania kierowane do aplikacji, a mechanizmy Anti-DDoS odpowiadają za ochronę infrastruktury przed wybranymi atakami sieciowymi. Ogranicza to znaczną część zagrożeń występujących po stronie środowiska hostingowego, ale nie zastępuje aktualizacji sklepu, poprawnej konfiguracji aplikacji ani zabezpieczenia samej logiki sprzedażowej.

Jakie dodatkowe zagrożenia dotyczą sklepu?

Poniższa tabela nie zastępuje listy typowych zagrożeń dla stron internetowych (jaką już tworzyliśmy we wcześniejszym artykule). Pokazuje scenariusze, które nabierają w naszej ocenie szczególnego znaczenia, kiedy strona zaczyna sprzedawać.

Nie warto natomiast tworzyć osobnych kategorii dla każdej rzeczy, którą napastnik może zrobić już po przejęciu sklepu. To nieskończona liczba scenariuszy. Jeżeli ktoś uzyska dostęp do panelu administracyjnego i zmieni numer telefonu, regulamin, adres e-mail albo opis produktu, nie mamy czterech nowych rodzajów cyberataku. To działania wykonane po uzyskaniu dostępu. Inaczej wygląda sytuacja, gdy sam mechanizm sklepu pozwala zrobić coś, czego nie powinien, na przykład zmienić wartość rabatu, ominąć etap płatności albo podejrzeć cudze zamówienie. Wtedy problem znajduje się bezpośrednio w logice aplikacji.

Płatności i checkout

Checkout jest miejscem, w którym spotyka się kilka istotnych elementów sklepu. Klient ma już produkty w koszyku, przekazuje dane potrzebne do realizacji zamówienia, wybiera dostawę i rozpoczyna płatność. Sam sklep w tym czasie oblicza wartość transakcji i komunikuje się z kolejnymi systemami.

Nie każdy sklep obsługuje płatność tak samo. W jednym przypadku klient zostanie przekierowany na stronę operatora płatności, w innym część procesu odbędzie się bez opuszczania sklepu. Niezależnie od rozwiązania jest to jednak fragment procesu sprzedażowego, który szczególnie interesuje osoby szukające błędów i możliwości nadużycia.

E-skimming – sklep działa, a dane mogą wyciekać

E-skimming, nazywany także web skimmingiem, polega na umieszczeniu w stronie złośliwego kodu, który przechwytuje informacje wpisywane przez użytkownika. Jednym z najbardziej znanych określeń związanych z takimi kampaniami jest Magecart.

Najbardziej niebezpieczne jest to, że klient może nie zauważyć niczego podejrzanego. Produkty nadal się wyświetlają, koszyk działa, zamówienie zostaje złożone i nie pojawia się żaden komunikat o błędzie. W tle działa jednak dodatkowy fragment kodu obserwujący określone pola albo kierujący użytkownika do elementu procesu przygotowanego przez napastnika.

Skąd taki kod bierze się w sklepie? Może zostać wprowadzony przez przejęte konto administratora, podatną wtyczkę lub moduł, zmodyfikowany plik albo zewnętrzny skrypt, który wcześniej sam został zainfekowany. Skimmer jest więc często skutkiem wcześniejszego naruszenia bezpieczeństwa, ale dla sklepu tworzy dodatkowe zagrożenie właśnie w miejscu, w którym klient ufa stronie i przekazuje jej dane potrzebne do zakupu.

Manipulacja procesem płatności

Wyobraź sobie zamówienie za 499 zł. Sklep musi wiedzieć, jaka jest jego wartość, jaki ma identyfikator, jaką metodę płatności wybrał klient oraz czy operator rzeczywiście potwierdził wykonanie transakcji. Jeżeli któraś z tych informacji może zostać zmieniona przez użytkownika i sklep nie zweryfikuje jej ponownie po swojej stronie, pojawia się przestrzeń do nadużycia.

Napastnik może więc sprawdzać, co stanie się po zmianie wartości przekazywanej pomiędzy kolejnymi etapami, pominięciu jednego z kroków albo ponownym wysłaniu wcześniej poprawnego żądania. Nie oznacza to, że w każdym sklepie można po prostu zmienić cenę z 499 zł na 4,99 zł. Pokazuje jednak, dlaczego błędy logiki biznesowej są w e-commerce tak samo istotne jak klasyczne podatności w kodzie.

Zwróć uwagę, że „atakującym” nie musi być człowiek siedzący przed komputerem. Może to być automat, bot albo przygotowany wcześniej skrypt wykonujący kolejne próby. Nie musi instalować malware ani uzyskiwać dostępu do panelu administratora, ponieważ sklep sam udostępnia proces płatności każdemu klientowi. W takiej sytuacji sprawdzane jest po prostu, jak zachowa się aplikacja po otrzymaniu parametrów, kolejności działań lub żądania, którego jej twórca nie przewidział.

Carding – kiedy Twój sklep staje się narzędziem

Przy cardingu sklep nie musi być właściwym celem ataku. Może zostać wykorzystany jako narzędzie do sprawdzania skradzionych danych kart. Jeżeli przestępca posiada dużą bazę takich informacji, potrzebuje sposobu na ustalenie, które z nich nadal pozwalają przeprowadzić transakcję.

Automat może więc wykonywać kolejne próby zakupów, często na niewielkie kwoty, i obserwować odpowiedź systemu płatniczego. Z punktu widzenia właściciela sklepu wygląda to zupełnie inaczej niż klasyczne włamanie. Nikt nie próbuje dostać się do panelu ani zmienić plików. Zamiast tego możesz zobaczyć serię nietypowych płatności, dużą liczbę odrzuconych transakcji albo wiele podobnych prób wykonanych w krótkim czasie.

Konta klientów i dane

Jeżeli pozwalasz klientowi utworzyć konto, tworzysz kolejną część sklepu, której nie posiada wiele prostych stron firmowych. Użytkownik może znaleźć tam swoje zamówienia, dane kontaktowe, adres dostawy, faktury, rabaty, punkty programu lojalnościowego czy zapisane preferencje.

Nie zakładaj przy tym, że wartościowe są wyłącznie numery kart lub hasła. Sama historia zakupów może być informacją prywatną. Zakupy związane ze zdrowiem, specjalistyczną dietą, produktami erotycznymi czy innymi osobistymi potrzebami nabierają zupełnie innego znaczenia, gdy zostają powiązane z konkretnym nazwiskiem i adresem.

Credential stuffing – Twój sklep nie musiał mieć żadnego wycieku

Załóżmy, że z zupełnie innego serwisu wyciekła baza adresów e-mail i haseł. Twój sklep nie został zaatakowany i nic z niego nie wyciekło, ale część klientów korzysta w kilku miejscach z tych samych danych logowania. Automat bierze więc zdobyte wcześniej kombinacje i zaczyna sprawdzać je również w Twoim sklepie.

Nie zgaduje haseł znak po znaku. Podaje konkretny adres e-mail i hasło, którego dana osoba rzeczywiście używała w innym miejscu. Jeżeli użytkownik powtórzył je także u Ciebie, logowanie zakończy się powodzeniem. Twój sklep nie musi mieć więc własnego wycieku, żeby konto klienta zostało przejęte. Źródło problemu może znajdować się zupełnie gdzie indziej.

Przejęcie konta klienta

Jeżeli logowanie się powiedzie, dochodzimy do Account Takeover, czyli przejęcia konta. Z punktu widzenia sklepu użytkownik podał prawidłowe dane logowania, więc otrzymuje dostęp do funkcji przewidzianych dla właściciela konta. Dopiero ich zakres decyduje o tym, co może zobaczyć lub zrobić napastnik.

Może uzyskać dostęp do wcześniejszych zamówień, danych zapisanych na koncie, rabatów, punktów lojalnościowych czy innych funkcji przypisanych klientowi. Podobny problem może dotyczyć administratora. Wystarczy fałszywa wiadomość podszywająca się pod operatora płatności, firmę kurierską, dostawcę towaru albo hosting, aby osoba zarządzająca sklepem sama przekazała dane logowania na przygotowanej stronie.

Wyciek danych bez klasycznego włamania

Nie każdy wyciek zaczyna się od cyberprzestępcy, który pokonał zabezpieczenia serwera. Dane mogą znaleźć się w miejscu publicznie dostępnym przez błąd konfiguracji albo nieprawidłowe działanie aplikacji. Może to być kopia bazy pozostawiona w dostępnym katalogu, plik zawierający informacje o klientach, źle skonfigurowane API albo mechanizm, który po zmianie identyfikatora pokazuje cudze zamówienie.

Efekt pozostaje podobny: osoba, która nie powinna mieć dostępu do danych, jednak je otrzymuje. W sklepie pojedyncze zamówienie potrafi łączyć nazwisko, adres, dane kontaktowe i zakupiony produkt. Czasami właśnie takie zestawienie jest bardziej wrażliwe niż każda z tych informacji analizowana osobno.

Koszyk, rabaty i inne mechanizmy sprzedaży

Przejdźmy do zagrożeń, które najmocniej odróżniają sklep od zwykłej strony internetowej. Napastnik nie zawsze potrzebuje Twojego hasła, nie musi przejmować serwera i nie musi instalować złośliwego oprogramowania. Może zachowywać się jak zwykły klient: otworzyć produkt, dodać go do koszyka, podać kod rabatowy i rozpocząć składanie zamówienia. Różnica zaczyna się wtedy, gdy zamiast wykonywać kolejne czynności dokładnie tak, jak przewidział interfejs, zacznie zmieniać parametry i obserwować reakcję aplikacji.

Manipulacja koszykiem i ceną

Jeżeli produkt kosztuje 500 zł, samo wyświetlenie tej ceny w przeglądarce nie oznacza jeszcze, że każda część sklepu prawidłowo zweryfikuje ją na dalszych etapach zakupu. Atakujący może sprawdzać dane wysyłane podczas dodawania produktu do koszyka, zmiany liczby sztuk, wyboru sposobu dostawy czy finalizacji zamówienia.

Nie chodzi o banalne zmienienie tekstu „500 zł” na „5 zł” w przeglądarce. Liczą się wartości rzeczywiście wykorzystywane przez aplikację. Jeżeli parametr przesyłany przez użytkownika wpływa na końcową cenę i serwer nie sprawdza go poprawnie, może pojawić się możliwość manipulacji.

Kody rabatowe i vouchery

Kod rabatowy wygląda niepozornie, ale również uruchamia określoną logikę: sklep sprawdza, czy kod istnieje, czy nadal obowiązuje, ile razy można go wykorzystać, do jakich produktów się odnosi i czy można połączyć go z inną promocją. Błąd w jednym z tych warunków może wystarczyć, żeby klient otrzymał większą korzyść, niż przewidział sprzedawca.

Próby mogą obejmować automatyczne zgadywanie kodów, wielokrotne używanie jednorazowego vouchera, łączenie promocji, które powinny się wykluczać, albo wpływanie na wartość rabatu. Z punktu widzenia serwera nie zawsze wygląda to jak klasyczny atak. Użytkownik nadal znajduje się w koszyku i używa funkcji, którą sklep sam mu udostępnił. Problemem jest sposób jej wykorzystania.

Denial of Inventory – towar jest, ale klient nie może go kupić

Wyobraź sobie, że masz w magazynie dziesięć sztuk popularnego produktu. Sklep na określonym etapie zakupów rezerwuje towar dla klienta, aby dwie osoby nie mogły jednocześnie kupić ostatniej sztuki. Taki mechanizm jest potrzebny, ale może zostać wykorzystany przeciwko sklepowi.

Bot rozpoczyna dziesięć zakupów i blokuje cały dostępny zapas, po czym żadnego z zamówień nie kończy. Towar fizycznie nadal leży na półce, ale kolejny klient widzi brak dostępności i nie może go kupić. Właśnie na tym polega Denial of Inventory. Towar jest w magazynie, ale sklep przestaje go sprzedawać. Szczególnie bolesne może być to podczas premier, wyprzedaży, sprzedaży biletów i limitowanych kolekcji.

Boty i scalping

Ten sam mechanizm automatyzacji można wykorzystać na wiele sposobów. Bot może sprawdzać ogromną liczbę kodów rabatowych, pobierać katalog i ceny produktów, tworzyć konta, rozpoczynać płatności albo wykupywać najbardziej pożądane towary chwilę po rozpoczęciu sprzedaży.

Dla sklepu bot nie zawsze wygląda jak „atak”. Czasem wykonuje dokładnie tę samą operację co zwykły klient. Różnica polega na tym, że może zrobić to setki albo tysiące razy szybciej i na znacznie większą skalę. W przypadku scalpingu automat konkuruje z normalnymi kupującymi o ograniczoną liczbę egzemplarzy i dzięki automatyzacji ma nad nimi przewagę. Sklep nie musi mieć przy tym klasycznej podatności. Mechanizm może działać zgodnie z projektem, a problemem staje się sposób i skala jego wykorzystania.

Nie wszystko jest zagrożeniem w tym samym znaczeniu

W artykule poświęconym zagrożeniom dla stron internetowych skupialiśmy się przede wszystkim na problemach technicznych, które mogą dotknąć właściwie każdą aplikację udostępnioną w internecie: podatnościach, złośliwym kodzie, przejęciu dostępu czy przeciążaniu usługi. W sklepie internetowym sytuacja jest trochę bardziej złożona. Część opisanych wyżej scenariuszy rzeczywiście wynika z przełamania zabezpieczeń, ale część polega po prostu na wykorzystaniu prawidłowo działającej funkcji w sposób, którego właściciel sklepu nie przewidział albo nie chce akceptować.

Dlatego na każdy z tych przypadków warto spojrzeć osobno. E-skimming oznacza już ingerencję w kod lub proces obsługi klienta. Credential stuffing wykorzystuje cudze dane logowania i próbuje przejąć konto. Manipulacja płatnością może wynikać z błędu w logice aplikacji. Z kolei scalping nie musi oznaczać żadnej podatności technicznej – automat może po prostu szybciej niż człowiek wykonać prawidłową ścieżkę zakupu.

To ostatnie jest dobrym przykładem, ponieważ z czysto sprzedażowego punktu widzenia sklep osiąga swój podstawowy cel: produkt został sprzedany. Czy powinieneś być zadowolony? Problem pojawia się gdzie indziej. Jeżeli limitowany towar znika w ciągu kilku sekund za sprawą automatów, zwykli klienci nie mają szansy go kupić, rośnie frustracja, trudniej budować lojalność i relację z marką, a oferta może natychmiast pojawić się na rynku wtórnym. Nie każda sytuacja wymaga więc tego samego rodzaju zabezpieczenia i nie każda wymaga „blokowania ataku”. Najpierw trzeba ustalić, z czym naprawdę mamy do czynienia: podatnością, nadużyciem, automatyzacją czy po prostu sposobem korzystania ze sklepu, którego z biznesowego punktu widzenia nie chcemy akceptować.

Jak chronić sklep internetowy?

Wiemy, że po przeczytaniu całej listy może się wydawać, że prowadzenie sklepu internetowego wymaga jednoczesnej znajomości bezpieczeństwa serwerów, programowania, płatności, botów, ochrony danych i administracji systemami. Nie jest naszym celem zniechęcać Cię do uruchamiania czy rozwijania sklepu. Wręcz przeciwnie. Chodzi o świadomość, że działalność w internecie wiąże się z określonym ryzykiem, podobnie jak prowadzenie samochodu. Samo posiadanie prawa jazdy nie sprawia, że możesz przestać obserwować drogę, ignorować stan techniczny samochodu i przez kilka lat nie wykonywać żadnego przeglądu. Jeżeli jesteś uważny, reagujesz na sygnały i dbasz o podstawowe elementy, ryzyko można znacząco ograniczyć. Ze sklepem jest podobnie: nie powinien zostać uruchomiony i pozostawiony sam sobie na kolejne lata. Wymaga aktualizacji, administracji, kontroli dostępu, kopii zapasowych, sprawdzania używanych dodatków oraz okresowego przeglądu tego, jak zmienia się sama aplikacja i otaczające ją środowisko.

Bardzo ważne jest też zrozumienie, że za poszczególne części sklepu odpowiadają różne warstwy ochrony – podobnie jak w samochodzie inne podzespoły odpowiadają za hamowanie, przyczepność, bezpieczeństwo pasażerów czy widoczność. Hosting zabezpiecza infrastrukturę i środowisko aplikacji. Operator płatności odpowiada za swoją część procesu transakcyjnego. Twórca sklepu musi poprawnie zaprojektować logikę cen, rabatów i uprawnień. Administrator odpowiada za aktualizacje i konfigurację, a właściciel sklepu za sposób organizacji dostępów, kont pracowników czy wybór narzędzi, z których korzysta firma.

Od czego zacząć zabezpieczanie sklepu?

Nie ograniczaj się do odpowiedzi: „mam certyfikat SSL i hosting w sprawdzonej firmie”. To dobre elementy, ale tylko fragment całej układanki. Zacznij od ustalenia, jak sklep jest zabezpieczony dzisiaj i kto odpowiada za poszczególne obszary.

Jeżeli budujesz sklep samodzielnie, potraktuj tę listę jako część procesu wdrożenia, a nie czynność wykonywaną dopiero po pierwszym problemie.

Jeśli sklep tworzy agencja, nie zakładaj z kolei, że słowo „opieka” automatycznie obejmuje wszystkie te elementy. Ustal zakres odpowiedzialności jeszcze przed uruchomieniem sprzedaży, a jeśli sklep już działa – zrób taki przegląd teraz.

Problem zacznie się wtedy, gdy założysz, że jedno narzędzie załatwia całe bezpieczeństwo sklepu. Nie istnieje system, który jednocześnie poprawi podatną wtyczkę, naprawi błędną logikę rabatu, zatrzyma każdy rodzaj bota, zabezpieczy skrzynkę e-mail pracownika i uniemożliwi administratorowi wpisanie hasła na stronie phishingowej.

Monarx jako jedna z warstw ochrony sklepu

Na hostingu SEOHOST korzystamy z Monarx Security. System działa automatycznie po stronie środowiska hostingowego od momentu objęcia usługi ochroną i nie wymaga od Ciebie ręcznego uruchamiania kolejnych skanów. W przypadku sklepu internetowego jego działanie można sprowadzić do trzech głównych obszarów:

• Pliki i złośliwy kod – Antivirus + Active Protection: Monarx analizuje pliki znajdujące się na koncie hostingowym, klasyfikuje wykryte zagrożenia i może automatycznie reagować na potwierdzony malware lub zainfekowany kod.
• Działanie aplikacji PHP – ThreatShield: mechanizm działa podczas wykonywania aplikacji i pomaga wykrywać oraz blokować niebezpieczne operacje wykonywane przez kod PHP. Ma to znaczenie między innymi wtedy, gdy ktoś próbuje wykorzystać podatny komponent sklepu.
• Ruch kierowany do aplikacji – SmartWAF: dodatkowa warstwa analizuje wybrane żądania i informacje o źródle ruchu, pomagając blokować część połączeń rozpoznanych jako niebezpieczne.

W praktyce oznacza to, że sklep lub platforma sprzedażowa jest chroniona nie tylko poprzez sprawdzanie plików leżących na serwerze. Ochrona działa również w czasie wykonywania aplikacji oraz przy obsłudze części ruchu kierowanego do strony. Nie jest to jednak zamknięty system bezpieczeństwa całego e-commerce, tylko bardzo ważna warstwa działająca po stronie hostingu.

Po Twojej stronie nadal pozostają aktualizacje WordPressa, WooCommerce, PrestaShop lub innej platformy, aktualizacje modułów i wtyczek, zabezpieczenie kont administratorów, 2FA, prawidłowa konfiguracja certyfikatów SSL, kontrola logiki checkoutu, bezpieczeństwo integracji, kopie zapasowe oraz opieka administratora lub agencji. Ktoś się tym musi zająć.

Operator płatności odpowiada natomiast za własny fragment procesu transakcyjnego. Dopiero połączenie tych elementów tworzy środowisko, w którym pojedynczy problem nie musi od razu oznaczać przejęcia całego sklepu.

Prowadzisz sklep internetowy? Hosting SEOHOST korzysta z wydajnego środowiska NVMe i LiteSpeed oraz dodatkowych mechanizmów bezpieczeństwa, w tym ochrony Monarx Security. Jeśli przenosisz działający sklep od innego operatora, możesz również skorzystać z bezpłatnej migracji.

Nie musisz znać nazw wszystkich możliwych podatności ani samodzielnie analizować każdego żądania wysyłanego do sklepu. Dobrze jednak rozumieć, że zagrożenie nie kończy się na pliku malware znalezionym na serwerze. Ktoś może próbować przejąć konto Twojego klienta, wykorzystać błąd w checkoutcie, manipulować rabatem albo użyć prawidłowo działającego koszyka w sposób, którego nikt nie przewidział.

Sklep internetowy łączy stronę WWW z systemem sprzedażowym, płatnościami i danymi klientów. Bezpieczeństwo trzeba więc budować dokładnie w tych samych miejscach, w których pojawiają się jego dodatkowe funkcje.