Przegląd konfiguracji Drupala pod kątem bezpieczeństwa

W pierwszej części serii poświęconej audytom bezpieczeństwa w Drupalu opisaliśmy, jak robić przegląd modułów i bibliotek. Jednak moduły oraz zależności na nic się nie przydadzą, jeśli dowolny użytkownik będzie mógł zobaczyć nasz niestandardowy routing na którym wyświetlamy wszystkie informacje o klientach. Dlatego w tym artykule przyjrzymy się konfiguracji naszego serwisu. Poprawna konfiguracja jest jednym z kluczowych elementów wpływających na bezpieczeństwo.

Sprawdzanie konfiguracji Drupala

Na naszej liście w tej części znajdzie się między innymi sprawdzenie uprawnień dla ról, dostępów do drupalowych widoków i routingów. Zweryfikujemy również poprawność konfiguracji formatów tekstu oraz dokonamy innych sprawdzeń, mających na celu wyszukanie największej liczby potencjalnych wektorów ataku na naszą aplikację.

Audyt uprawnień dla ról

Przechodząc pod adres /admin/people/roles, naszym oczom ukaże się lista wszystkich dostępnych ról.

Na liście po prawej stronie (kolumna OPERATIONS) po kliknięciu możemy wybrać opcję edit permissions, która przekieruje nas na stronę /admin/people/permissions/[machine_name_roli]     (przykład dla roli Anonymous: /admin/people/permissions/anonymous). Po przejściu do edycji uprawnień Drupal wylistuje nam wszystkie możliwe uprawnienia, które zostały nadane dla wybranej roli.

W celu weryfikacji uprawnień należy w pierwszej kolejności zastanowić się, jakie zadanie jest przypisane do roli. Musimy zadać sobie pytanie, czy rola X powinna mieć uprawnienia do czynności Y, na przykład: czy rola content editor powinna mieć możliwość edycji wszystkich widoków? Jeśli odpowiedź brzmi nie, należy ograniczyć uprawnienia.

Do audytu uprawnień potrzebna jest pełna znajomość projektu. Jeśli znajdziemy uprawnienie, którego naszym zdaniem dana rola nie powinna posiadać, powinniśmy jedynie poinformować o możliwości posiadania nadobowiązkowych uprawnień przez rolę w raporcie z przeprowadzonego audytu. Więcej informacji o tym jak stworzyć dobry raport, przedstawimy w jednym z kolejnych artykułów w ramach serii dotyczącej audytu bezpieczeństwa Drupala.

Audyt uprawnień dla widoków

Po przeprowadzeniu audytu dla ról nadszedł czas na pochylenie się nad widokami. Wszystkie są wylistowane na stronie /admin/structure/views.

Naszym zadaniem w tym przypadku będzie w pierwszej kolejności wejście w edycję każdego widoku, który dostarcza routing. Interesuje nas sekcja PAGE SETTINGS, a dokładniej opcja Access, która jedynie intencjonalnie powinna być ustawiona na “Unrestricted”.

W przypadku audytu uprawnień dla widoków, podobnie jak w przypadku ról, należy zadać sobie pytanie: jakie restrykcje należy nałożyć na widok X? Jeśli widok powinien być dostępny dla każdego, dobrą praktyką jest nadanie restrykcji, która wymaga posiadania uprawnień do dostępu do opublikowanej zawartości (access published content). Jeśli dowolny z widoków nie posiada restrykcji lub są one w naszej opinii zbyt małe, powinniśmy o tym poinformować w raporcie.

Audyt plików routing.yml w custom modułach

Jeśli chodzi o routingi stworzone w custom modułach, audyt wygląda podobnie. Należy przejrzeć każdy plik *.routing.yml w celu upewnienia się, że każdy routing posiada odpowiedni poziom zabezpieczeń. Oto przykładowa deklaracja nowego routingu

W tym przypadku uprawnienia dostępu do strony /machine_name/transliterate ma każdy użytkownik posiadający uprawnienie access content. Dobrą praktyką w tym przypadku jest również określenie minimalnego poziomu dostępu dla każdego routingu na access content.

Audyt formatów tekstu

Pod ścieżką /admin/config/content/formats znajdują się wszystkie formaty tekstu dostępne na stronie. Audyt w tym przypadku będzie polegał na sprawdzeniu, czy na przykład nie istnieje możliwość wrzucenia kodu JavaScript przy użyciu danego formatu tekstu lub czy nie można podlinkować obrazka, który będzie pobierany z innej strony. Ważne jest również to, aby lista możliwych rozszerzeń plików nie pozwalała na wrzucanie plików o niebezpiecznych rozszerzeniach, jeśli nie jest to niezbędne. Błędy w konfiguracji oczywiście raportujemy, stopień zagrożenia zależy od typu błędu.

Audyt logowania błędów

Na stronie /admin/config/development/logging znajduje się opcja konfiguracyjna Error messages to display. Jej zadaniem jest ustawienie poziomu wyświetlania błędów. Opcja ta powinna być ustawiona na None na stronie produkcyjnej. Jeśli ta opcja na środowisku produkcyjnym jest ustawiona na inny wariant niż None - raportujemy to jako zagrożenie o niskim stopniu.

Podstawowy audyt logowania

Panel logowania może w dwojaki sposób informować, czy użytkownik próbujący się zalogować podał niepoprawne dane. Może dawać lakoniczną odpowiedź w stylu “dane są niepoprawne” lub podawać inną informację, gdy login jest niepoprawny, a odmienną, kiedy hasło jest niepoprawne. W ostatnim przypadku mamy wektor do ataku brute force. Atakujący może w pierwszej kolejności zbruteforceować loginy, aby następnie bruteforceować hasła i w ten sposób otrzymać dostęp do kont użytkowników.

Kolejnym aspektem, który warto sprawdzić, jest polityka haseł. Jest to temat dyskusyjny, ponieważ niektórzy proponują wymuszanie zmiany hasła co pewien okres, a inni mówią, że hasło powinno zawierać przynajmniej jedną dużą literę, jedną małą, jedną cyfrę i jeden znak specjalny. Niektórzy łączą obie zasady, a użytkownicy na końcu tworzą hasła typu Lipiec2021!, które spełniają wszystkie wymogi. Moja osobista rekomendacja w tym przypadku wyklucza wymuszanie zmiany hasła co pewien okres. Określenie złożoności hasła jest rekomendowane, ale najważniejsza jest jego długość - im hasło jest dłuższe tym więcej czasu potrzeba na jego złamanie. Polityka haseł to sprawa, która zależy od typu projektu i trzebą ją analizować indywidualnie. W przypadku słabej polityki haseł należy zaraportować ją jako zagrożenie o poziomie zależnym od tego, jak zła ta polityka jest.

Audyt formularzy

Formularze powinny mieć zabezpieczenie przed spamem. Tam gdzie to możliwe powinny być tworzone z wykorzystaniem Drupal API. Należy sprawdzić, czy formularze są zabezpieczone przed spamem oraz czy ich walidacja nie pozwala na wprowadzenie błędnych lub niebezpiecznych danych. W przypadku wykrycia niepoprawności w konfiguracji formularza, należy to zaraportować, poziom zagrożenia jest zależny od sytuacji. Inny poziom zagrożenia będzie dla potencjalnego SQLi, a inny na możliwość wprowadzenia błędnych danych na przykład w select liście.

Dodatkowe rekomendacje

Istnieją moduły Drupala, które podnoszą bezpieczeństwo naszej aplikacji. Jednym z takich modułów jest Security Kit. Dzięki niemu zniwelujesz prawdopodobieństwo wykorzystania luk w zabezpieczeniach strony internetowej. Ten moduł oferuje zabezpieczenia Anti-XSS, Anti-CSRF, Anti-ClickJacking i inne. Rekomendujemy zapoznanie się z podlinkowanym postem i rozważenie instalacji.

Modułem, który może pomóc w audycie bezpieczeństwa Drupala jest Security Review. Wykorzystuje on zautomatyzowane testy bezpieczeństwa, które wspomagają audyt.

Moduł ten:

• sprawdza uprawnienia do plików,
• robi audyt formatów tekstu,
• robi audyt opcji odpowiedzialnej za raportowanie błędów,
• przeprowadza audyt opcji, w której określamy, jakie rozszerzenia plików da się wgrać (np. do pobrania w blog poście),
• monitoruje błędy bazy w celu wykrycia potencjalnego ataku,
• monitoruje panel logowania w tym samym celu,
• sprawdza konfigurację pliku trusted hosts,
• sprawdza uprawnienia do widoków.

Security Review jest godny polecenia, ponieważ może przyspieszyć proces audytowania strony.

Konfiguracja Drupala sprawdzona - co dalej?

W tej części serii poświęconej przeprowadzaniu audytu bezpieczeństwa Drupala zapoznaliśmy się ze sposobami na sprawdzenie konfiguracji Drupala. Znamy opcje konfiguracyjne, które mogą otwierać wektory ataku oraz wiemy, jakie są rekomendacje, by te wektory zamknąć.

Przyswojenie wiedzy dostarczonej w tym poście pozwoliło Ci na lepsze zrozumienie, że poprawna konfiguracja systemu jest równie ważna co jego aktualność. Audyt konfiguracji jest kolejną z czynności, które wykonujemy podczas audytu bezpieczeństwa - nasz zespół wsparcia Drupala rekomenduje kompleksowe sprawdzanie konfiguracji podczas audytu bezpieczeństwa.

W kolejnej części tej serii artykułów sięgniemy do kodu i zaznajomimy się z podstawowymi sposobami na jego audyt. Przedstawimy sposoby na analizę modułów oraz skórek. Przyjrzymy się temu, co siedzi w repozytorium. Czy są w nim jakieś hasła, klucze? A może cały dump bazy danych?