Analiza systemów open source za pomocą observatory

W internecie jest dostępnych wiele narzędzi online, które pozwalają producentom, dostawcom i klientom weryfikować aktualny stan zabezpieczeń ustawiony dla systemu dostępnego online. Choć systemy klasy CRM/ERP najczęściej nie są dostępne publicznie, o tyle wersje demo producentów już tak. Postaramy się przybliżyć tematykę zabezpieczeń, które są istotne dla każdego systemu webowego a tym bardziej dla projektów open source, które każdy może dowolnie dostosować pod swoje wymagania.

Narzędzie do testowania

Narzędzie, którym się posłużymy (Mozilla Observatory), 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ę oceną poszczególnych zabezpieczeń, która wystawia oceny od F (najgorsza) do A+ (najlepsza). 

Porównanie systemów open source

Poniżej stworzyliśmy zestawienie z oceną zabezpieczeń poszczególnych systemów CRM open source:

Niektórzy producenci rozwiązują problem poprzez odpowiednią konfigurację serwera dla subdomeny, na której znajduje się system. Problem jednak 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 i ją poprawić. 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 utrudniają 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 systemy wymagają jednak 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, ale również większości komercyjnych systemów, także tych z górnej półki.