Jeśli haker zmienił blog_charset na UTF-7, czy to czyni WordPress podatnym na kolejne ataki?


19

Miałem klienta, który został ostatnio zhakowany i zauważyłem, że na jej stronie pojawiają się dziwne postacie, takie jak  i Æ. Okazuje się, że hakerzy zmienili blog_charset na UTF-7 w wp_optionstabeli w bazie danych. Ustawiłem go z powrotem na UTF-8, ale zastanawiałem się, czy w czasie, gdy był ustawiony na UTF-7, czy mogłoby to stworzyć jakieś luki w zabezpieczeniach?

Przeprowadziłem pewne wyszukiwanie i odkryłem, że kiedyś istniała usterka WordPress UTF-7, która została naprawiona w wersji 2.0.6 . Korzystamy z najnowszej wersji WordPress, więc nie mogli użyć tego exploita, ale czy są jakieś inne exploity związane z UTF-7? Naprawdę, czy jest jakiś powód, dla którego hakerzy zmieniliby blog_charset poza byciem bólem? Próbowałem ustalić, jak się tam dostali i zastanawiam się, czy to się w jakiś sposób łączy.

Odpowiedzi:


23

<i >są zakodowane jako +ADw-i +AD4-w UTF-7 . Teraz wyobraź sobie, co następuje:

  1. Ktoś wysyła +ADw-script+AD4-alert(+ACI-Hello+ACI-)+ADw-/script+AD4-jako komentarz. Wszystkie urządzenia sanitarne przejdą bez szwanku.

  2. Baza danych oczekuje i traktuje wszystkie przychodzące dane jako UTF-8. Ponieważ wszystkie strumienie UTF-7 są ważne UTF-8 za ten nigdy nie spowoduje błędu SQL i mysql_real_escapealbo htmlspecialcharsnie będzie go dotknąć.

  3. WordPress wysyła nagłówek text/html;charset=utf-7.

  4. WordPress wyświetla komentarz, oczekując ucieczki danych. Ponieważ jednak przeglądarka traktuje to jako UTF-7, JavaScript zostanie wykonany.

Tak, to jest problem bezpieczeństwa.

UTF-7 nie jest obsługiwany przez wszystkie przeglądarki, większość wyświetli tekst jako Windows-1252 (lub cokolwiek to jest domyślne kodowanie w ich systemie operacyjnym) lub jako UTF-8. Główny problem jest taki: ucieczka nie będzie już działać.


Po prostu zmiana wartości kodowania z powrotem nie jest rozwiązaniem. Zwykły użytkownik nie może go zmienić, więc trzeba mieć , aby znaleźć otwartych drzwi.


Dzięki! Trzymam kciuki, że poprawienie wpisu w bazie danych zamknęło lukę w zabezpieczeniach.
Jennette

Nie martw się, podjąłem już kilka działań w celu zamknięcia luk bezpieczeństwa. Po prostu nie mogłem rozgryźć, jak się tam dostają. Wydaje się, że nic nie zostało zhakowanych w ciągu ostatnich kilku dni, więc mam nadzieję, że zmiana kodowania z powrotem na UTF-8 była ostatnim krokiem do zamknięcia wszystkich dziur.
Jennette,

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.