Zawartość artykułu
PrestaShop 1.6.x – fikcyjne konta klientów – przyczyna ataku.
Problem jest stosunkowo nowy i pojawił się dosłownie w przeciągu paru ostatnich dni od publikacji tego artykułu. Objawia się zakładaniem przez nieznanego sprawcę fikcyjnych kont klientów, gdzie w sekcji „nazwisko” podany jest złośliwy link do spamerskiej strony:
Zazwyczaj bazujący na usługach do skracania linków:
www.cutt.us www.twixar.com www.lmy.de www.xurl.es www.v.ht
Atakujący wykorzystał tutaj słabość PrestaShop, jeśli chodzi o tzw. walidację (sprawdzanie poprawności) nazwiska klienta. W ten sposób – w miejscu nazwiska wklejony jest link, zapewne w celu późniejszego przekierowania. Konta takie są zakładane co około 1h i nadają się jedynie do usunięcia.
Poniżej prezentujemy „łatę” do oprogramowania, która zabezpiecza przed tym atakiem.
Oczywiście należy rozważyć dodatkowo instalację tzw. mechanizmu captcha, który by uniemożliwiał automatyczne tworzenie kont. Np. wymagałby przepisania kodu z obrazka itp. Tak czy inaczej, zaprezentowana tutaj metoda rozwiązania tego konkretnego ataku powinna pomóc.
Fałszywe konta klientów w PrestaShop – rozwiązanie problemu i instalacja łaty.
Otwórz plik:
classes/Validate.php
Znajdź funkcję isName() może mieć postać typu:
public static function isName($name) { return preg_match(Tools::cleanNonUnicodeSupport('/^[^0-9!<>,;?=+()@#"°{}_$%:]*$/u'), stripslashes($name)); }
Umieść pod nią nową funkcję:
public static function isCustomerName($name) { if (preg_match(Tools::cleanNonUnicodeSupport('/www|http/ui'),$name)) return false; return preg_match(Tools::cleanNonUnicodeSupport('/^[^0-9!\[\]<>,;?=+()@#"°{}_$%:\/\\\*\^]*$/u'), $name); }
Następnie otwórz plik:
classes/Customer.php
Znajdź początek wystąpienia tablicy definition:
public static $definition = array(
(okolice 157 linii)
Następnie zamień te 2 linijki:
'lastname' => array('type' => self::TYPE_STRING, 'validate' => 'isName', 'required' => true, 'size' => 32), 'firstname' => array('type' => self::TYPE_STRING, 'validate' => 'isName', 'required' => true, 'size' => 32),
Na:
'lastname' => array('type' => self::TYPE_STRING, 'validate' => 'isCustomerName', 'required' => true, 'size' => 32), 'firstname' => array('type' => self::TYPE_STRING, 'validate' => 'isCustomerName', 'required' => true, 'size' => 32),
Czyli zmieniamy funkcję walidującą z isName na nowo stworzoną: isCustomerName
Po zabezpieczeniu sklepu możemy śmiało usunąć konta klientów założone przez atakującego.
Przy usuwaniu najlepiej jest skorzystać z opcji:
Chcę żeby moi klienci mogli zarejestrować się ponownie za pomocą tego tego samego adresu e-mail. Wszystkie dane zostaną usunięte z bazy danych.
Wtedy – dane są kompletnie kasowane z bazy danych. I nie możliwe jest ewentualne przywrócenie hasła na takim fake’owym koncie:
Problem nie powinien powrócić przynajmniej jeśli chodzi o ten konkretny atak.
Uwaga! Po „bożemu” należałoby umieścić ten kod w plikach overrides. Niestety (jeszcze) nie mamy sprawdzonego i przetestowanego rozwiązania, które działa w ten sposób. W związku z tym, że edycja dotyczy tutaj plików jądra PrestaShop – po aktualizacji systemu – te zmiany mogą zniknąć. Należy wtedy upewnić się, czy można założyć konto klienta z linkiem w nazwisku lub imieniu. Zapewne twórcy PrestaShop pracują już nad łatą i pojawi się ono wraz z najbliższą aktualizacją. Jeśli nie – ww. modyfikacje należy przenieść w nowszej wersji, aby problem nie powrócił.
Alternatywnym rozwiązaniem tego problemu może być instalacja (darmowego) modułu Captcha bazującym na algorytmie Google’a:
grafika: all-free-download.com
Dzięki
Dzięki, miałem akurat taki sam problem w sklepie klienta i Twoje rozwiązanie pomogło!
Dziękuję za pomoc. Super, że podzieliłeś się tym rozwiązaniem.
Dzień dobry – czy to rozwiązanie zadziała także dla PrestaShop 1.5.xxx
Niestety @Sebastian na tę chwilę nie obsługujemy żadnego sklepu pod PS 1.5.x i nie możemy tego sprawdzić / nie było to tam przez nas wykonywane. Czyli ten atak też tam ma miejsce? Ciekawe..
Na starszych, czyli 1.4 to samo
Witam. Wykonałem powyższe zmiany i rzeczywiście boty przestały zakładać fikcyjne konta. Problem w tym, że po kilku dniach zaczęli się do mnie zgłaszać użytkownicy, że nie mogą założyć konta, bo wyskakuje im, że mają niepoprawne imię lub nazwisko. Co równie gorszego to to, że starym klientom przy próbie resetu hasła w przypadku jego zapomnienia wyskakiwał błąd 500. Błąd był powodowany, że w linku przy potwierdzeniu resetu hasła w końcówce występowała spacja _ Po jej zlikwidowaniu formularz wyświetlał się poprawnie, ale wyskakiwało, że nie można zmienić hasła dla tego konta.
Nie było innej rady i musiałem przywrócić pliki do czasu sprzed zmian. Wszystko wróciło do normy. Czekam czy fikcyjne konta znowu będą zakładane.