Jest kilka rzeczy, które mogą zdradzić dane logowania do serwisu WordPressa. Nie będę tutaj opisywał tej najbardziej oczywistej, czyli posługiwania się loginem bezpośrednio na blogu, tylko skupię się na nieco bardziej chytrej opcji, która zakłada odpytywanie formularza logowania w celu ustalenia, które loginy są dostępne w bazie danych. To tak jak grać w statki i strzelać na oślep, aż w końcu się trafi w któryś z nich, a skąd wiemy, że trafiliśmy? Po zwracanej odpowiedzi od drugiego gracza. I podobnie jest w przypadku formularza logowania WordPressa, z tym, że jeśli chodzi o strony www, to mamy nieco zawężone pole strzału, bo administrator/użytkownik zwykle wybiera niezbyt skomplikowany login często kojarzący się z pewnymi elementami jego życia, a gdy potencjalny atakujący ustali taki login, to będzie w stanie dokonać ataku Brute Force na hasło do tego konta.

Mając już zainstalowanego i wstępnie skonfigurowanego WordPress'a, przydałoby się zadbać prawa dostępu do jego plików jak i również ograniczyć nieco dostęp do samej bazy danych, tak by możliwie najmniejsze uprawnienia zostały nadane, co poprawi znacznie bezpieczeństwo naszej witryny. Jeśli opanowaliśmy już operowanie na instalacji WordPress'a przy pomocy skryptu wp-cli , to możemy bez wahania dokręcić śrubę naszemu serwisowi. Jeśli nie zaznajomiliśmy się jeszcze z powyższym narzędziem, to ograniczenie praw może spowodować problemy z aktualizacją rdzennych plików WordPress'a, jak i instalacją/konfiguracją jego pluginów czy motywów.

WordPress stara się dbać o bezpieczeństwo swoich użytkowników najlepiej jak potrafi. Dowodem na to mogą być unikalne klucze i sole uwierzytelniające (Authentication Unique Keys and Salts) wprowadzone w wersji 2.5 oraz nieco rozbudowane w wersji 2.7. Ten mechanizm nie wykorzystuje sesji PHP do śledzenia np. statusu zalogowania, tylko zaprzęga do tego celu ciasteczka, by utrudnić (albo raczej uniemożliwić) potencjalnemu atakującemu dostęp do witryny. Bez tych kluczy i soli jesteśmy w stanie przewidzieć wszystkie składowe hasha danego ciasteczka, dlatego też powinniśmy pokusić się o ich implementację na swojej stronie. Niemniej jednak, na necie jest bardzo dużo niskiej jakości informacji na temat działania mechanizmu walidacji ciasteczek, a artykuły, które potrafią go opisać w szerszym stopniu, są już lekko nieaktualne, bo zmienia się on praktycznie z każdą nową wersją WordPressa. Zanim jednak przejdziemy do samych kluczy/soli, powinniśmy się zaznajomić ze sposobem w jaki WordPress generuje i sprawdza wspomniane ciasteczka, na podstawie których to autoryzowane są działania użytkowników naszego bloga.

Postanowiłem się w końcu wziąć za porządki związane z wiadomościami pocztowymi i RSS'ami, bo katalog Thunderbird'a już zajmował prawie 650 MiB. Jakby nie patrzeć, to trochę dużo, biorąc pod uwagę, że są to głównie wiadomości tekstowe. W sumie to miałem tam archiwum wszystkich maili z 4-5 ostatnich lat i trochę się tego nazbierało. Nie byłoby tego wpisu gdyby nie fakt, że nawet usunięcie 120 tyś. wiadomości praktycznie nie wpłynęło na zajmowane przez nie przestrzeni na dysku.

Począwszy od wersji 4.2, WordPress wstawia pliki powiązane z Emoji bezpośrednio do nagłówka strony. Jest to porcja 1600 znaków, która ma służyć zamianie tekstowych emotikonek na ich graficzne odpowiedniki. Jeśli z nich nie korzystamy albo wolimy zamiast nich kilka znaków tekstowych, to ten kod jest dla nas kompletnie zbędny i zaśmieca tylko nagłówek, wobec czego powinniśmy się jak najszybciej pozbyć tego balastu.

Jeśli publikujemy posty na swoim blogu, to pierw musimy je gdzieś sporządzić. Możemy to robić w zwykłym notatniku lub też bezpośrednio w formularzu WordPressa dostępnego przy edycji postu. Istnieje też inna możliwość, mianowicie korzystanie ze specjalnie przeznaczonego do tego celu oprogramowania -- klientów blogowych działających w oparciu o protokół XML-RPC. Jest to mechanizm podobny tego znanego choćby z poczty internetowej, czyli mamy konto email, np. na gmailu ale do tworzenia i zarządzania wiadomościami wykorzystujemy np. Thunderbirda. Podobnie możemy postępować z treścią pojawiającą się na blogu i nawet nie musimy być w tym czasie online. Jednym z bardziej znanych klientów, przy pomocy którego możemy wrzucać posty na bloga, to Windows Live Writer (WLW). Poza tym, protokół XML-RPC wykorzystywany jest także przez część serwisów internetowych, np. Flickr , co umożliwia im zamieszczanie postów w naszej witrynie.

W chwili gdy zabierałem się za rozpracowywanie szeregu zagadnień związanych z oczyszczaniem nagłówka generowanego przez WordPress, nie miałem pojęcia, że niektóre opcje nie są dostępne w standardowej instalacji, którą każdy może sobie pobrać z ich strony i wgrać do siebie na serwer. Chodzi oczywiście o krótkie odnośniki (shortlinks). Ich głównym celem jest skracanie linków do paru znaków, tak by można je umieścić np. na Twitterze gdzie długość wiadomości jest znacznie ograniczona i raczej wklejanie tam linku, który by zjadł wszystkie dostępne znaki nie jest zbytnio pożądane.

Na necie widziałem wiele tutoriali na temat zmiany konfiguracji stylów czy motywów WordPressa i w większości z nich ludzie dokonywali poprawek w kodzie źródłowym bezpośrednio przez panel administracyjny. Ni to wygodne, ani bezpieczne. Prze wszystkim, jeśli jakiś robak uzyskałby dostęp do konta administracyjnego naszego bloga, to pierwsze co mu przyjdzie do głowy, to edycja plików właśnie za pomocą wbudowanego w WordPress edytora (Appearance => Editor). Dlatego ze względów bezpieczeństwa kluczowe jest wyłączenie tej opcji i jeśli potrzebujemy zmieniać określone pliki WordPressa, to róbmy to poza samym skryptem i najlepiej przy pomocy zwykłego notatnika co potrafi kolorować składnię, by uniknąć również ewentualnych literówek.

Jeśli piszemy dużo na swoim blogu i mamy sporo treści, którą trzeba uaktualnić, to prawdopodobnie często wprowadzamy poprawki polegające na usuwaniu starych wpisów i tworzeniu szkiców nowych artykułów. Tego typu rotacja sprawia, że sporo wiadomości ląduje w koszu, z tym, że jeśli chodzi o bazę danych, to jej jest bez różnicy czy przenieśliśmy dany post do kosza, przynajmniej do momentu gdy faktycznie on wyleci z bazy danych. Także pod względem objętości bazy nic się nie zmienia. Poza tym, WordPress potrafi opróżniać kosz co pewien czas i dla jednych ten interwał może być za krótki, a dla innych za długi. Postaramy się więc go dostosować.

Klucze SSH mogą być wykorzystane jako sposób identyfikacji danej osoby przy logowaniu się do zdalnego serwera SSH. Te klucze zawsze występują w parach -- jeden prywatny, drugi publiczny. Pierwszy z nich jest znany tylko nam i powinien być trzymany w sekrecie i pilnie strzeżony. Klucz publiczny z kolei zaś jest przesyłany na każdy serwer SSH, z którym chcemy się połączyć. Gdy serwer jest w posiadaniu naszego klucza publicznego i widzi przy tym, że próbujemy nawiązać połączenie, używa on tego klucza by wysłać do nas zapytanie (challange) -- jest ono zakodowane i musi na nie zostać udzielona odpowiednia odpowiedź, a tej może dokonać ktoś, kto jest w posiadaniu klucza prywatnego. Nie ma innej opcji by rozkodować wiadomość, dlatego też nikt inny nie może udzielić na nią prawidłowej odpowiedzi. To rozwiązanie eliminuje wrażliwość na różne formy podsłuchu -- ten kto nasłuchuje nie będzie w stanie przechwycić pakietów zawierających hasło, bo ono nie jest nigdy transmitowane prze sieć. No i oczywiście jeśli chodzi o samo hasło -- odpadają nam ataki typu Brute Force pod kątem jego złamania.