Każda istniejąca aplikacja w internecie działa na podstawie danych jakie są do niej wprowadzane. Podstawową daną jest adres zasobu, zwany ogólnie URI (Unique Resource Identificator), który jednoznacznie identyfikuje miejsce z jakiego serwer aplikacji ma pobrać zasób. Możliwe jest wprowadzanie danych jako parametrów wejściowych, dodatkowo identyfikujących zasób lub definiujących jego zachowanie.
Technolgia internetowa przewiduje wiele różnych sposobów reprezentacji zarówno identyfikatora zasobu, jak i wartości parametrów wejściowych, co niestety w niektórych przypadkach może prowadzić do poważnych luk bezpieczeństwa. Luki te zwykle polegają na błędnej interpretacji przez aplikację wprowadzanych danych.
Co zrobić, aby nie narażać naszej aplikacji na takie niebezpieczeństwo? Odpowiedzią na to pytanie jest kanonizacja. Pojęcie to należy do tych naukowych i częściej można się spotkać z określeniem normalizacji lub standaryzacji. Ogólnie rzecz biorąc, proces kanonizacji polega na sprowadzaniu danego typu danych, który może występować w wielu formach, do pewnej „znormalizowanej” postaci. Pozwala to na uproszczenie procesu przetwarzania (np. porównywania podczas wyszukiwania) i uniknięcie nieumyślnej, błędnej ich interpretacji.
Przed jakimi problemami bezpieczeństwa chroni normalizacja?
Przekierowanie ścieżki (Path Traversal)
Często aplikacje pozwalają na dostęp do pewnych zasobów umieszczonych w systemie plików serwera hostującego lub wprost uruchamia operacje systemowe. Czasami w parametrach wywołania podawana jest nazwa pliku lub innego zasobu np.
https://mojastrona.com?image=bigicon.jpg
Normalizacja/kanonizacja w takim wypadku powinna polegać na określeniu absolutnej ścieżki z jakiej zasoby podawane w parametrze image są pobierane i uniemożliwienie wyjścia poza tę ścieżkę, np.
c:\inetpub\wwwroot\images\{doklejana nazwa pliku}
Gdyby takiej kanonizacji nie było moglibyśmy wprowadzić do parametru ścieżkę innego pliku, który akurat bardzo mocno chcielibyśmy ukryć (np. „\..\web.config”). W taki wypadku mechanizm mógłby potraktować powstałą ścieżkę jako prawidłową i taki plik załączyć do wynikowej strony.
Wstrzyknięcia (Injections)
Normalizacja w przypadku wstrzyknięć dotyczy przede wszystkim sposobu w jaki aplikacja interpretuje i przetwarza dane, które mogą występować w różnym kodowaniu. Przykładowo wartości parametrów w adresie zasobu (URI) możemy kodować w różnych postaciach (np. kodowanie URL, kodowanie Unicode, kodowanie UTF), tzn. że ten sam znak może występować w wielu różnych postaciach (np. znak „%” może być zakodowany jako „%20”, „0x20”, „0x0020”, itd). Problem polega na tym, że aplikacja musi taki znak poprawnie zdekodować i zinterpretować. Może to prowadzić do wświetlenia nieprawidłowej treści na wyrenderowanym widoku lub modyfikacji poleceń SQL.
Kanonizacja w takim wypadku sprowadza się do przyjęcia konkretnego formatu (kodowania) za obowiązujący w naszej aplikacji, próby przetworzenia danych do tego formatu, a w razie błędu, przerwania przetwarzania i wywołania wyjątku.
Kwestia metod kodowania i związnych z nim niebezpieczeństw jest szerokim tematem i myślę, że wkrótce pojawi się nie jeden wpis na ten temat.
Atak XXE – (XML eXternal Entity attack)
Atak XXE jest ściśle związany z błędnym przetwarzaniem (parsowaniem) danych w formacie XML. Atak ten polega na umieszczeniu w treści dokumentu XML odniesienia do tzw. zewnętrznych encji, które następnie są przetwarzane przez błędnie skonfigurowany parser XML. Atak tego rodzaju można wykorzystać do przeprowadzenia ataku DoS (Denial of Service), nieautoryzowanego dostępu do wrażliwych danych, czy nawet skanowania sieci lokalnej w jakiej znajduje się serwer aplikacji.
Oprócz poprawnego skonfigurowania parsera XML (o czym innym razem) możemy dokonać tzw. normalizacji wejściowego dokumentu XML. Dla dokumentów XML została stworzona specjalna specyfikacja tzw. The Canonical XML Specification. Specyfikacja ta definiuje jakie czynności należy wykonać na dokumencie, aby sprowadzić go do postaci kanonicznej.
Przykładowymi czynnościami normalizacyjnymi są:
- usuwanie białych znaków z nazw tagów
- kodowanie dokumentu do UTF-8
- usuwanie sekcji CDATA i zastąpienie ich właściwym kontentem
- zastąpienie samozamykających się tagów osobnymi tagami otwarcia i zamknięcia
- itd
Po szczegóły polecam zajrzeć pod wspomniany wyżej link.
Inne zastosowania kanonizacji
Poza ochroną normalizacja może być wykorzystywana do zadań, które optymalizują metody analizy danych, jak na przykład indeksowanie na potrzeby wyszukiwania (SEO), czy też podczas analizy leksykograficznej, gdy uwspólniamy znaczenie słów w różnych formach gramatycznych, np. słowo „drzewo” i jego różne odmiany, jak: „drzewa”, „drzew”, „drzewem”, itd.
Podsumowanie
Każda aplikacja przetwarza jakieś dane. Aby uchronić się przed problemami, warto czasami przemyśleć, jakie dane przetwarzamy i czy jest możliwe takie ich sformatowanie, aby nasze algorytmy nie musiały być zbyt skomplikowane i nie generowały dodatkowych problemów (np. podatności bezpieczeństwa).