Regularnie publikujemy artykuły o bezpieczeństwie witryn internetowych. Każdy tekst oparty jest na aktualnych standardach i dokumentacji technicznej.
SSL8 min czytania
Let's Encrypt kontra płatne certyfikaty: co wybrać dla swojej witryny?
Let's Encrypt zrewolucjonizował dostępność certyfikatów SSL. Darmowe certyfikaty Domain Validation od tej organizacji są technicznie równoważne płatnym odpowiednikom DV. Szyfrowanie połączenia jest identyczne. Różnica pojawia się na poziomie weryfikacji tożsamości.
Certyfikaty OV (Organization Validation) i EV (Extended Validation) wymagają weryfikacji firmy przez urząd certyfikacji. W przypadku EV w starszych przeglądarkach pojawiała się zielona nazwa firmy w pasku adresu. Chrome i Firefox usunęły ten wskaźnik wizualny w 2019 roku, co znacząco zmniejszyło praktyczną różnicę widoczną dla użytkownika końcowego.
Kiedy warto rozważyć certyfikat komercyjny? Przede wszystkim gdy warunki hostingu nie obsługują automatycznego odnawiania Let's Encrypt, gdy wymagają tego wewnętrzne polityki bezpieczeństwa organizacji lub gdy klient oczekuje ubezpieczenia wystawcy certyfikatu.
Brute force na panelu logowania: jak rozpoznać i ograniczyć ryzyko
Atak brute force polega na systematycznym próbowaniu kolejnych kombinacji hasła, często z użyciem słownika popularnych haseł. Zautomatyzowane narzędzia potrafią wykonać tysiące prób logowania na minutę. Standardowy formularz logowania bez żadnych zabezpieczeń jest na to podatny niezależnie od siły hasła administratora.
Podstawowe mechanizmy ograniczające skuteczność ataku to: limitowanie liczby prób logowania z jednego adresu IP, wprowadzanie opóźnień po kolejnych błędnych próbach, CAPTCHA po przekroczeniu progu oraz alerty e-mail o podejrzanej aktywności. Każda z tych metod ma swoje ograniczenia. Ataki z wielu adresów IP (botnet) ominąć mogą limit na adres IP. CAPTCHA bywa rozwiązywana przez usługi farm ludzkich.
Skuteczniejsza ochrona to uwierzytelnianie dwuskładnikowe. Nawet jeśli atakujący pozna hasło, bez drugiego składnika dostęp jest zablokowany. Opisujemy implementację TOTP (Time-based One-Time Password) w popularnych systemach CMS.
WordPress dzieli aktualizacje na trzy kategorie: rdzeń systemu, motywy i wtyczki. Każda warstwa rządzi się innymi zasadami. Rdzeń WordPress otrzymuje aktualizacje bezpieczeństwa automatycznie w wersji minor (np. 6.5.1 do 6.5.2) domyślnie od wersji 3.7. Aktualizacje major wymagają ręcznej decyzji.
Wtyczki to najczęstszy wektor ataku. Wiele odkrytych podatności dotyczy popularnych wtyczek z milionami instalacji. Czas między opublikowaniem łatki a jej zainstalowaniem przez administratora to okno, które atakujący aktywnie wykorzystują. Niektóre exploity są publikowane publicznie natychmiast po wydaniu łatki, bo analiza kodu łatki ujawnia naturę podatności.
Podejście warstwowe zakłada osobne harmonogramy: automatyczne aktualizacje bezpieczeństwa dla rdzenia, cotygodniowy przegląd wtyczek na środowisku testowym i miesięczny audyt motywu. Każda aktualizacja powinna być poprzedzona kopią zapasową.
NIST 2024: nowe wytyczne dotyczące polityki haseł dla serwisów internetowych
Opublikowany w 2024 roku dokument NIST SP 800-63B wprowadził zmiany, które burzą kilka utrwalonych przekonań o bezpieczeństwie haseł. Wymuszone regularne zmiany haseł nie są zalecane, chyba że istnieje dowód kompromitacji. Wymagania co do złożoności (wielkie litery, cyfry, znaki specjalne) są opcjonalne i mogą prowadzić do przewidywalnych wzorców.
Co NIST zaleca zamiast tego? Minimalna długość 8 znaków, ale preferowane hasła dłuższe bez ograniczeń górnych. Sprawdzanie nowych haseł pod kątem obecności na listach wycieków. Brak wymuszania zmiany hasła bez konkretnego powodu. Pozwolenie na wklejanie haseł (co zachęca do używania menedżerów haseł).
Te zmiany mają praktyczne konsekwencje dla administratorów formularzy rejestracyjnych i paneli logowania. Opisujemy, jak dostosować politykę haseł w popularnych systemach CMS do aktualnych wytycznych.
Formularz kontaktowy jako cel ataku: CSRF, spam i wstrzyknięcia
Formularz kontaktowy to jeden z najczęstszych elementów witryny i jednocześnie potencjalny punkt wejścia dla kilku klas ataków. Cross-Site Request Forgery (CSRF) pozwala atakującemu na wykonanie akcji w imieniu zalogowanego użytkownika przez spreparowany link. Ochrona wymaga tokenu CSRF generowanego per sesja i weryfikowanego po stronie serwera.
Spam przez formularz kontaktowy to osobny problem. Boty skanują strony w poszukiwaniu formularzy i wysyłają przez nie wiadomości masowo. Honeypot (ukryte pole niewidoczne dla ludzi, wypełniane przez boty) to prosta technika bez negatywnego wpływu na doświadczenie użytkownika. reCAPTCHA v3 działa w tle i ocenia zachowanie bez wymuszania rozwiązania zadania.
Wstrzyknięcia przez formularz kontaktowy mogą dotyczyć nagłówków e-mail (email header injection), jeśli dane z formularza są bezpośrednio wklejane do nagłówka wiadomości. Opisujemy walidację po stronie serwera i sanityzację danych wejściowych.
Witryna może mieć aktywny certyfikat SSL i nadal wyświetlać ostrzeżenie przeglądarki. Dzieje się tak gdy strona załadowana przez HTTPS zawiera zasoby (obrazy, skrypty, arkusze stylów) pobierane przez niezabezpieczone HTTP. To zjawisko nazywa się mixed content i podważa ochronę zapewnianą przez szyfrowane połączenie.
Przeglądarki dzielą mixed content na pasywny (obrazy, wideo) i aktywny (skrypty, style). Aktywny mixed content jest blokowany przez domyślnie wszystkie nowoczesne przeglądarki. Pasywny może być wyświetlany z ostrzeżeniem. Nagłówek Content-Security-Policy z dyrektywą upgrade-insecure-requests automatycznie przekierowuje żądania HTTP na HTTPS.
