{"id":197,"date":"2018-02-10T23:00:12","date_gmt":"2018-02-10T22:00:12","guid":{"rendered":"https:\/\/brozanski.net\/?p=197"},"modified":"2018-02-11T12:05:20","modified_gmt":"2018-02-11T11:05:20","slug":"197","status":"publish","type":"post","link":"https:\/\/brozanski.net\/index.php\/2018\/02\/10\/197\/","title":{"rendered":"Kanonizacja – przepis na bezpieczne przetwarzanie danych"},"content":{"rendered":"

Ka\u017cda istniej\u0105ca aplikacja w internecie dzia\u0142a na podstawie danych jakie s\u0105 do niej wprowadzane. Podstawow\u0105 dan\u0105 jest adres zasobu, zwany og\u00f3lnie URI (Unique Resource Identificator), kt\u00f3ry jednoznacznie identyfikuje miejsce z jakiego serwer aplikacji ma pobra\u0107 zas\u00f3b. Mo\u017cliwe jest wprowadzanie danych jako parametr\u00f3w wej\u015bciowych, dodatkowo identyfikuj\u0105cych zas\u00f3b lub definiuj\u0105cych jego zachowanie.
\nTechnolgia internetowa przewiduje wiele r\u00f3\u017cnych sposob\u00f3w reprezentacji zar\u00f3wno identyfikatora zasobu, jak i warto\u015bci parametr\u00f3w wej\u015bciowych, co niestety w niekt\u00f3rych przypadkach mo\u017ce prowadzi\u0107 do powa\u017cnych luk bezpiecze\u0144stwa. Luki te zwykle polegaj\u0105 na b\u0142\u0119dnej interpretacji przez aplikacj\u0119 wprowadzanych danych.<\/p>\n

Co zrobi\u0107, aby nie nara\u017ca\u0107 naszej aplikacji na takie niebezpiecze\u0144stwo? Odpowiedzi\u0105 na to pytanie jest kanonizacja. Poj\u0119cie to nale\u017cy do tych naukowych i cz\u0119\u015bciej mo\u017cna si\u0119 spotka\u0107 z okre\u015bleniem normalizacji lub standaryzacji. Og\u00f3lnie rzecz bior\u0105c, proces kanonizacji polega na sprowadzaniu danego typu danych, kt\u00f3ry mo\u017ce wyst\u0119powa\u0107 w wielu formach, do pewnej „znormalizowanej” postaci. Pozwala to na uproszczenie procesu przetwarzania (np. por\u00f3wnywania podczas wyszukiwania) i unikni\u0119cie nieumy\u015blnej, b\u0142\u0119dnej ich interpretacji.<\/p>\n

Przed jakimi problemami bezpiecze\u0144stwa chroni normalizacja?<\/p>\n

Przekierowanie \u015bcie\u017cki (Path Traversal)<\/h3>\n

Cz\u0119sto aplikacje pozwalaj\u0105 na dost\u0119p do pewnych zasob\u00f3w umieszczonych w systemie plik\u00f3w serwera hostuj\u0105cego lub wprost uruchamia operacje systemowe. Czasami w parametrach wywo\u0142ania podawana jest nazwa pliku lub innego zasobu np.<\/p>\n

https:\/\/mojastrona.com?image=bigicon.jpg<\/p>\n

Normalizacja\/kanonizacja w takim wypadku powinna polega\u0107 na okre\u015bleniu absolutnej \u015bcie\u017cki z jakiej zasoby podawane w parametrze image<\/strong> s\u0105 pobierane i uniemo\u017cliwienie wyj\u015bcia poza t\u0119 \u015bcie\u017ck\u0119, np.<\/p>\n

c:\\inetpub\\wwwroot\\images\\{doklejana nazwa pliku}<\/p>\n

Gdyby takiej kanonizacji nie by\u0142o mogliby\u015bmy wprowadzi\u0107 do parametru \u015bcie\u017ck\u0119 innego pliku, kt\u00f3ry akurat bardzo mocno chcieliby\u015bmy ukry\u0107 (np. „\\..\\web.config”). W taki wypadku mechanizm m\u00f3g\u0142by potraktowa\u0107 powsta\u0142\u0105 \u015bcie\u017ck\u0119 jako prawid\u0142ow\u0105 i taki plik za\u0142\u0105czy\u0107 do wynikowej strony.<\/p>\n

Wstrzykni\u0119cia (Injections)<\/h3>\n

Normalizacja w przypadku wstrzykni\u0119\u0107 dotyczy przede wszystkim sposobu w jaki aplikacja interpretuje i przetwarza dane, kt\u00f3re mog\u0105 wyst\u0119powa\u0107 w r\u00f3\u017cnym kodowaniu. Przyk\u0142adowo warto\u015bci parametr\u00f3w w adresie zasobu (URI) mo\u017cemy kodowa\u0107 w r\u00f3\u017cnych postaciach (np. kodowanie URL, kodowanie Unicode, kodowanie UTF), tzn. \u017ce ten sam znak mo\u017ce wyst\u0119powa\u0107 w wielu r\u00f3\u017cnych postaciach (np. znak „%” mo\u017ce by\u0107 zakodowany jako „%20”, „0x20”, „0x0020”, itd). Problem polega na tym, \u017ce aplikacja musi taki znak poprawnie zdekodowa\u0107 i zinterpretowa\u0107. Mo\u017ce to prowadzi\u0107 do w\u015bwietlenia nieprawid\u0142owej tre\u015bci na wyrenderowanym widoku lub modyfikacji polece\u0144 SQL.<\/p>\n

Kanonizacja w takim wypadku sprowadza si\u0119 do przyj\u0119cia konkretnego formatu (kodowania) za obowi\u0105zuj\u0105cy w naszej aplikacji, pr\u00f3by przetworzenia danych do tego formatu, a w razie b\u0142\u0119du, przerwania przetwarzania i wywo\u0142ania wyj\u0105tku.<\/p>\n

Kwestia metod kodowania i zwi\u0105znych z nim niebezpiecze\u0144stw jest szerokim tematem i\u00a0my\u015bl\u0119, \u017ce wkr\u00f3tce pojawi si\u0119 nie jeden wpis na ten temat.<\/p>\n

Atak XXE – (XML eXternal Entity attack)<\/h3>\n

Atak XXE jest \u015bci\u015ble zwi\u0105zany z b\u0142\u0119dnym przetwarzaniem (parsowaniem) danych w formacie XML. Atak ten polega na umieszczeniu w tre\u015bci dokumentu XML odniesienia do tzw. zewn\u0119trznych encji, kt\u00f3re nast\u0119pnie s\u0105 przetwarzane przez b\u0142\u0119dnie skonfigurowany parser XML. Atak tego rodzaju mo\u017cna wykorzysta\u0107 do przeprowadzenia ataku DoS (Denial of Service), nieautoryzowanego dost\u0119pu do wra\u017cliwych danych, czy nawet skanowania sieci lokalnej w jakiej znajduje si\u0119 serwer aplikacji.<\/p>\n

Opr\u00f3cz poprawnego skonfigurowania parsera XML (o czym innym razem) mo\u017cemy dokona\u0107 tzw. normalizacji wej\u015bciowego dokumentu XML. Dla dokument\u00f3w XML zosta\u0142a stworzona specjalna specyfikacja tzw.\u00a0The Canonical XML Specification<\/a>. Specyfikacja ta definiuje jakie czynno\u015bci nale\u017cy wykona\u0107 na dokumencie, aby sprowadzi\u0107 go do postaci kanonicznej.<\/p>\n

Przyk\u0142adowymi czynno\u015bciami normalizacyjnymi s\u0105:<\/p>\n