Kilka porad dotyczących zabezpieczania aplikacji ...i swojego portfela

[code] Z zainteresowania jestem diagnostykiem wdrażanych zabezpieczeń, z zawodu na razie programistą. Oto mój krótki poradnik dla kupujących, dla wdrażających, dla używających, dla tworzących serwisy internetowe. [/code]

1.Sygnatura serwera oraz używanego na nim oprogramowania:

Bardzo często kupujemy od dostawcy konto na serwerze www, no cóż, wszystko cacy, jednak nie do końca.

Przyjmijmy, że jest to tradycyjne środowisko LAMP (Linux, Apache, MySQL, Php), chociaż problem dotyczy komercyjnych serwerów typu WAMP lub WASP.NET

Najczęstsze błędy:

1. sygnatura serwera rozgłaszana w nagłówkach HTTP -> czyli np.: „Apache 2/2.2.3 nazwa_systemu mod_ssl_fips, itd.”

a. Należy poprosić dostawcę, aby w konfiguracji serwera WWW ustawił i. ServerSignature = off ii. ServerTokens = Prod

b. Dotyczy to serwera Apache, ale również coraz bardziej popularnego nginx -> ma być server_tokens=off

c. Ten błąd dotyczy nawet dużych dostawców, portali społecznościowych, prasowych.

______________________________________________________

Oczywiście wyłączenie tych dyrektyw na nic się zdaje kiedy domorosły cracker wykorzysta narzędzi typu sniffer, ale może jednak najpierw się skusi na sprawdzenie nagłówków HTTP poprzez wykonanie prostego i LEGALNEGO zabiegu

a. wchodzimy na stronę popularnego walidatora W3C (służy on sprawdzenia, czy treść serwisu jest poprawna zgodnie z przyjętym schematem, wiadomo, treść części serwisów jest w pełni generowana przez javascript, ale to temat na inną dyskusję)

http://validator.w3.org/

b. wpisujemy interesujące nas adres

c. wybieramy "More Options"

d. zaznaczamy "Verbose Output"

e. klikamy "Check" i np.: dla http://dobreprogramy.pl mamy Server: Microsoft-IIS/7.0 czyli w tym momencie potencjalnie dowiadujemy się, albo jest to Windows 7 Vista albo jest to Windows Server 2008 Poprawione, dzięki Nemhein za sprostowanie. ;)

i tak dalej....

Na szczęście cześć serwisów korzysta z zewnętrznych zaufanych serwerów proxy, poprzez które wszystkie dane przesyłane do głównego serwera aplikacji są filtrowane pod względem takich chociażby zagrożeń jak: 1) skanowania portów 2) ataków sql injection 3) ataków DDoS

2. dane konfiguracyjne PHP

a. expose_php jest na on -> ma być na off -> z jakiej racji odwiedzający ma wiedzieć, jaką wersję php stosujemy b. enable_dl jest na on -> jeżeli nie chcesz, aby którykolwiek z klientów ładował swoje rozszerzenia, które mogą spacyfikować Twoją infrastrukturę, ustaw globalnie na off

3. Zezwolenie na listowanie zawartości katalogów -> w niektórych przypadkach jest to pożądane, natomiast nie jest codzienną praktyką.

2. zezwolenie na atak DDoS z wykorzystaniem W3C LinkChecker, czyli narzędzia do weryfikowania poprawności linków, odnośników

a. należy dodać regułę do konfiguracji zapory ogniowej, aby odrzucał połączenia z http://validator.w3.org/checklink/ oraz poinformować Klienta o niemożności użycia tego narzędzia.

b. jeżeli dobrze się przyjrzycie, to jest najprostsze, darmowe narzędzie, które można wykorzystać do zwiększenia zużycia Waszych zasobów, uwzględniając włączenie

3. Stara wersja systemu operacyjnego oraz bibliotek

Stara wersja systemu operacyjnego Tutaj trzeba jednak spuścić z tonu: migracja serwerów na nowszy system operacyjny, niezależnie czy to Windows, Linux, BSD, Solaris, może zakończyć się niepowodzeniem. W przypadku administratorów jest to często zrozumiałe zachowanie podyktowane koniecznością zachowania kompatybilności ze sprzętem (sterowniki do urządzeń peryferyjnych, kart sieciowych, kontrolerów RAID).

Stare wersja bibliotek serwerowych

część dostawców nadal posiada np.: serwer Apache 1.3.1. Oczywiście jeżeli jest to wersja udostępniana przez producenta systemu operacyjnego poprzez oficjalne repozytoria, zazwyczaj nie mamy się czego obawiać, chociaż i tak to zakrawa o pomstę, że jako Klient płacisz za oprogramowanie, które już dawno przestało być wspierane przez producenta, np.: php4 … lub nawet php3…

Tak, doskonale sobie zdaję sprawę, że migracja np.: na php5 jest pracochłonna, wymagająca czasami przeanalizowania całego kodu aplikacji wraz ze strukturą bazy danych.

Stare wersje bibliotek niestety, część np.: polskich sklepów internetowych używa starych bibliotek (nawet z roku 2003) lub tak niepoprawnie napisanych, że atak na aplikację i na nasze dane osobowe jest niestety nieunikniony. Jeżeli jesteś właścicielem sklepu internetowego i zależy Tobie na marce i chcesz się dowiedzieć na temat błędów, które znalazłem lub mogę znaleźć, zapraszam do kontaktu.

Nielegalne wersja bibliotek

niestety, też przykra praktyka, np.: w sklepach internetowych, porównywarkach cen, portalach producentów płyt głównych -> jeżeli zamawiasz produkt w postaci portalu WWW, upewnij się, że twórca dostarczył spis wszystkich bibliotek, które użył do wytworzenia wraz ze wskazaniem licencji i jakie konsekwencje prawne ona rodzi wobec Ciebie jako kupującego.… Jeżeli jesteś zainteresowany tym tematem, również proszę o kontakt.

Brak danych o środowisku wytworzenia produktu

jako nabywający aplikację masz prawo wiedzieć, wręcz się domagać, aby została Tobie udostępniona specyfikacja środowiska, w którym wytworzono oprogramowanie. Zdarza się, że wgrywasz cały kod na serwer i ….nie działa.

Zdarza się, że wytwarzając oprogramowanie twórcy aplikacji nie biorą pod uwagę np.: różnic w systemach Windows i Linux, chociażby

rozróżniania wielkości liter przez systemy plików architektury (np.: wytworzona aplikacja była testowana na systemie X 32 bitowym, a Ty jako Klient masz do dyspozycji system Y 64bitowy bez bibliotek, których użył Twórca aplikacji)…

W przypadku tworzenia zwykłych portali internetowych, dajcie mi tak z tydzień, 
a postaram się zaprezentować sposób tworzenia i testowania oprogramowania 
w miarę przystępny dla twórcy, jak i potencjalnego klienta ;)

4. Architektura serwisu

Temat rzeka, ale postaram się przybliżyć jedną ch….rną zasadę, miało być koronną :p

Filtrowanie danych przychodzących od użytkownika lub zewnętrznej usługi

Obojętnie, czy wysyłane dane tekstowe z formularza, pliki zazwyczaj metodą GET oraz POST, filtruj z łaski swojej wszystkie dane zanim wstawisz je do używanego źródła danych.

Najbardziej karygodnym przykładem jest …. rozpoznawanie typów plików poprzez rozszerzenie pliku!

Błąd!!! Jeżeli chcesz weryfikować typ pliku, powinieneś zweryfikować na początek typ mime. Każdy typ pliku ma unikalną sygnaturę, poprzez którą można rozpoznać, czy jest to np.: JPG czy też GIF.

Dla php jest to biblioteka fileinfo (dla wersji php niższych niż 5.3 trzeba ją zainstalować z repozytorium pecl),

dla Javy polecam z własnego doświadczenia Mime-Util (http://sourceforge.net/projects/mime-util/)

Zapraszam wszystkich do dyskusji.

Karol