Analiza nagłówków [Observatory]

Narzędzie do testowania

Narzędzie którym się posłużymy [https://observatory.mozilla.org/] na dzień dzisiejszy weryfikuje następujące zabezpieczenia:

• Content Security Policy
• Cookies Secure
• Cross-origin Resource Sharing
• HTTP Public Key Pinning
• HTTP Strict Transport Security
• Redirection
• Referrer Policy
• Subresource Integrity
• X-Content-Type-Options
• X-Frame-Options
• X-XSS-Protection

W artykule nie będziemy opisywali powyższych zabezpieczeń, ponieważ w internecie znajdziemy wiele bardzo dobrych artykułów, które w jasny i przejrzysty sposób pozwalają zrozumieć jak ważne są to zabezpieczenia. Warto w tym miejscu przytoczyć cytat autorów:

„Dziewięć na dziesięć serwisów otrzyma tutaj ocenę niedostateczną i to jasne, że jest to problem dla nas wszystkich. Przez „wszystkich” rozumiemy tu także Mozillę, ponieważ wśród naszych tysięcy witryn wiele nie przejdzie tego testu.” Źródło: Mozilla, news.softpedia, cyberkendra

Oznacza to, że problem jest powszechny i producenci nie nadążają za rozwojem technologii. Każdy powinien mieć wdrożone odpowiednie polityki wewnętrzne, które odpowiadają za podwyższanie jakości kodu i weryfikacji zgodności z obowiązującymi standardami. W szczególności, że mamy do dyspozycji wiele narzędzi online. Mozilla posługuje się następującą oceną poszczególnych zabezpieczeń: https://github.com/mozilla/http-observatory/blob/master/httpobs/scanner/grader/grade.py, która wystawia oceny od F [najgorsza] do A+ [najlepsza]. 

Porównanie systemów open source

Poniżej zestawiliśmy jak producenci poszczególnych systemów open source, zabezpieczają swoje produkty:

Niektórzy producenci rozwiązują problem poprzez odpowiednią konfiguracje serwera dla subdomeny na której znajduje się system, jednakże problem ten cały czas istnieje, ponieważ mechanizmy i zabezpieczenia powinny być wbudowane w aplikacje. O ile z perspektywy bezpieczeństwa nie ma znaczenia na której warstwie zabezpieczenie zostanie zrealizowane, o tyle od strony praktycznej, jeżeli zabezpieczenie nie istnieje w aplikacji to co najmniej aplikacja powinna weryfikować czy serwer został odpowiednio skonfigurowany.

Od strony praktycznej jest bardzo prosto zarówno zweryfikować dowolną aplikacje podając jej adres do strony logowania, jak również poprawić aplikacje, ponieważ Mozilla przygotowała garść porad co należy zrobić, aby wynik ten poprawić, poniżej przykładowe zrzuty ekranu z testów:

YetiForce

SuiteCRM

SugarCRM

coreBOS

Podsumowanie

Można pomyśleć, że niektórzy producenci nie wiedzą o tego typu zabezpieczeniach, które w znaczący sposób utradniają włamanie się do aplikacji dla niektórych typów podatności. Prawda jest jednak taka, że jest to ignorowane a większość firm albo nie rozumie problemu albo ignoruje go, pomimo tego, że każdy audyt bezpieczeństwa powinien wykazać:

• brak weryfikacji konfiguracji serwera
• brak wbudowanych mechanizmów w samej aplikacji [jest to szczególnie istotne dla aplikacji otwartych, które każdy może sobie pobrać i skonfigurować u siebie]

Najnowsza wersja systemu YetiForce posiada 80 na 100 punktów co wyznacza już dzisiaj standardy [10 na 11 testów] w jakich należy tworzyć oprogramowanie, w przyszłości planujemy rozwiązać ostatni problem, który pozwoli nam przejść test 11 na 11.

Co ciekawe, niektóre testy są bardzo proste do spełnienia i każdy producent może to zrealizować w kilka chwil, niektóre jednak wymagają przebudowania architektury w taki sposób, aby była zgodna z obecnie obowiązującymi standardami.

Należy pamiętać, że problem ten nie dotyczy tylko systemów otwartych, problem ten dotyczy większości komercyjnych systemów, również tych z górnej półki.