Zamawianie oprogramowania to zawsze trudne wyzwanie. Spotkania, projekty, ustalenia, opisy funkcjonalne, limity czasowe, budżety itp… Jak już przez to przebrniemy i nasz wykonawca (w końcu) dostarczy oprogramowanie, to zawsze pozostaje najtrudniejsze zadanie, czyli odbiór prac (coś jak odbiór mieszkania tylko gorszy) i kolejny odbiór aplikacji w związku ze zgłoszonymi zastrzeżeniami przy pierwszym. Co poradzić, życie.

Ładne to oprogramowanie, ale niezbyt bezpieczne

Wszyscy skupiają się głównie na wyglądzie (bo przecież przycisk miał być zielony, a nie czerwony), na tym czy aplikacja się włącza oraz czy mniej lub bardziej karkołomnie użytkownik jest w stanie wykonywać zadania przy jej pomocy. Praktycznie już nikogo nie interesują aspekty bezpieczeństwa co jest niezwykle częstym błędem popełnianym zarówno przez wykonawcę, jak i zleceniodawcę.

Dobry projekt to podstawa

Już na etapie projektowania aplikacji powinno się określić architekturę bezpieczeństwa. Co przez to rozumieć? Np. to jak będą wyglądać procesy działające w ramach aplikacji i jakie dane będą w nich przetwarzane. Czy i w jaki sposób przetwarzane dane będą przekazywane do zewnętrzych komponentów oraz przechowywane. Zawsze wymagaj od wykonawcy stworzenia takiej dokumentacji, a przynajmniej wstępnych założeń na etapie projektowania.

Na co zwracać uwagę?

Spory wpływ na bezpieczeństwo aplikacji ma również wybór technologii, w której będzie wykonana. Należy wystrzegać się korzystania z już niewspieranych lub kończących swój żywot techologii. 

W przypadku komunikacji z zewnętrznymi komponentami zawsze wymagajcie, aby było zapewnione szyfrowanie kanału komunikacyjnego w jak najlepszy sposób.

Na etapie projektowania zwracajcie również uwagę, aby programiści nie próbowali chodzić na skróty np. przez zaszywanie haseł dostępowych w aplikacji lub żeby proces uwierzytelnienia odbywał się po stronie serwera, a nie u klienta (bardzo rzadkie, ale zdarza się w praktyce). Zdecydowana większość współczesnych platform ma przygotowane komponenty z wieloma funkcjami bezpieczeństwa, z których warto skorzystać (czasem sprowadza się to zmiany jednej flagi w pliku konfiguracyjnym z „false” na „true”). Dobre praktyki nie muszą oznaczać znacznego wzrostu kosztów, jeśli wykonawca ma odpowiednie doświadczenie.

Projekt gotowy i co dalej?

Aplikacja została stworzona. Co dalej? Testujemy do upadłego. Jeżeli aplikacja kliencka ma komunikować się z serwerem to sprawdźmy jak ten proces wygląda np. przy pomocy Wiresharka, czyli narzędzia do analizy pakietów (https://www.wireshark.org). To oprogramowanie dla bardziej zaawansowanych użytkowników, ale warto zachęcić osoby „techniczne” przynajmniej do wypróbowania. Jeśli dane wrażliwe dane pomiędzy jednym a drugim urządzeniem będą widoczne, to znaczy że połączenie nie jest bezpieczne.

Możemy spróbować przeszukać plik exe pod kątem występujących ciągów znaków programem strings z pakietu Windows Sysinternals. Jeśli ten program pokaże np. nazwę użytkownika lub, co gorsza, coś co przypomina hasło, to nie jest dobrze i stanowi to podstawę do zgłoszenia zastrzeżeń.

Jeżeli aplikacja do poprawnego działania wymaga stworzenia usług, to sprawdźmy z jakimi uprawnieniami jest wykonywana (a ponieważ wielu programistów chodzi na skróty, to mogą to być uprawnienia administratora systemu). W przypadku, gdy dla potrzeb usług tworzony jest kompletnie nowy profil użytkownika (bo inaczej aplikacja nie ruszy), to sprawdźmy ich uprawnienia: czy koniecznie musi być administratorem, czy konto jest oznaczone jako usługowe, czy ma wyłączone logowanie interaktywne.

Jeżeli aplikacja kliencka wymaga dostępu do usług sieciowych i niestety hasło musi być przechowywane na stacji klienta, to postarajmy się skorzystać z mechanizmów, które zabezpieczą dostęp.

Wiele ciekawych aspektów jest poruszanych w OWASP Application Security Verification Standard (stworzonej głównie dla aplikacji webowych, ale sporo można wykorzystać także przy aplikacjach desktopowych).

Jeżeli chcecie podzielić się własnymi radami dotyczącymi zamawiania oprogramowania lub brakuje Wam czegoś w artykule, zachęcamy do dyskusji.