Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00695 010498 11034301 na godz. na dobę w sumie
Hack Proofing XML. Edycja polska - książka
Hack Proofing XML. Edycja polska - książka
Autor: Liczba stron: 324
Wydawca: Helion Język publikacji: polski
ISBN: 83-7361-004-9 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> webmasterstwo >> xml i xslt - programowanie
Porównaj ceny (książka, ebook, audiobook).
XML szybko staje się uniwersalnym protokołem wymiany informacji pomiędzy systemami używającymi HTTP. HTML zapewne zachowa swoją pozycję języka opisującego wygląd dokumentów w sieci WWW, jednak tam, gdzie w grę wchodzą dane, XML jest dużo lepszym rozwiązaniem. Walidacja, czyli sprawdzenie poprawności dokumentu XML, to pierwsza zapora przed atakami hakerskimi. Te same właściwości, które czynią XML silnym i uniwersalnym narzędziem sprawiają, że jest on podatny na działania hakerów. Wiele zapór sieciowych nie filtruje dokumentów XML -- to kolejna przyczyna, dla której niepoprawne strukturalnie dokumenty mogą stanowić poważne zagrożenie dla systemów. 'Hack Proofing XML. Edycja polska' objaśni Ci wszystkie niuanse bezpieczeństwa związane z technologiami XML i .NET.

  1. Dowiesz się, kim są hackerzy
    Poznasz wyjaśnienie terminów: haker, cracker, black hat, phreaker i script kiddies -- nauczysz się rozpoznawać prawdziwe zagrożenia
  2. Poznasz sposób, w jaki cenne dane mogą się wydostać na zewnątrz Dowiesz się, w jaki sposób bannery, komunikaty o błędach i analiza protokołów może dostarczyć ważnych informacji potencjalnym napastnikom
  3. Nauczysz się budować poprawne dokumenty XML
    Zapoznasz się z celami, jakie postawili przed XML twórcy tego standardu i dowiesz się, w jaki sposób poprawność kodu XML może cię zabezpieczyć przed hakerami
  4. Poznasz atak 'czystym tekstem'
    To potężna broń hakerów, zabezpiecz przed nią swój system
  5. Nauczysz się stosować podpis elektroniczny w dokumentach XML
    Specyfikacja podpisu elektronicznego w XML jest elastyczna i pozwala podpisywać w bezpieczny sposób rozmaite dokumenty, a nawet zasoby zewnętrzne
  6. Dowiesz się, jak szyfrować XML
    Szyfrowanie to jedna z najważniejszych metod zabezpieczania dokumentów, pozwalająca dodatkowo sprawdzić, czy dokument nie był modyfikowany w czasie przesyłania; czy jest kompletny, a także kontrolować dostęp do danych zawartych w dokumencie
  7. Zastosujesz system kontroli dostępu oparty na rolach
    Przekonasz się, że bezpieczny system operacyjny współdziałający z odpowiednio zabezpieczoną aplikacją stanowi najlepszą zaporę przeciwko zakusom hakerów
  8. Poznasz ryzyko związane ze stosowaniem XML
    Zobaczysz, że architektura .NET i mechanizmy bezpieczeństwa w nią wbudowane mogą stanowić alternatywę w stosunku do 'czystego' XML
  9. Dowiesz się, jak zgłaszać błędy
    Kogo, kiedy i w jaki sposób informować o wykrytych dziurach w zabezpieczeniach? Jak wiele informacji ujawniać?
Znajdź podobne książki Ostatnio czytane w tej kategorii

Darmowy fragment publikacji:

Hack Proofing XML. Edycja polska Autor: praca zbiorowa T³umaczenie: Adam Jarczyk ISBN: 83-7361-004-9 Tytu³ orygina³u: Hack Proofing XML Format: B5, stron: 324 Przyk³ady na ftp: 15 kB XML szybko staje siê uniwersalnym protoko³em wymiany informacji pomiêdzy systemami u¿ywaj¹cymi HTTP. HTML zapewne zachowa swoj¹ pozycjê jêzyka opisuj¹cego wygl¹d dokumentów w sieci WWW, jednak tam, gdzie w grê wchodz¹ dane, XML jest du¿o lepszym rozwi¹zaniem. Walidacja, czyli sprawdzenie poprawnoġci dokumentu XML, to pierwsza zapora przed atakami hakerskimi. Te same w³aġciwoġci, które czyni¹ XML silnym i uniwersalnym narzêdziem sprawiaj¹, ¿e jest on podatny na dzia³ania hakerów. Wiele zapór sieciowych nie filtruje dokumentów XML — to kolejna przyczyna, dla której niepoprawne strukturalnie dokumenty mog¹ stanowiæ powa¿ne zagro¿enie dla systemów. „Hack Proofing XML. Edycja polska” objaġni Ci wszystkie niuanse bezpieczeñstwa zwi¹zane z technologiami XML i .NET. IDZ DO IDZ DO PRZYK£ADOWY ROZDZIA£ PRZYK£ADOWY ROZDZIA£ SPIS TREĎCI SPIS TREĎCI KATALOG KSI¥¯EK KATALOG KSI¥¯EK KATALOG ONLINE KATALOG ONLINE ZAMÓW DRUKOWANY KATALOG ZAMÓW DRUKOWANY KATALOG TWÓJ KOSZYK TWÓJ KOSZYK DODAJ DO KOSZYKA DODAJ DO KOSZYKA CENNIK I INFORMACJE CENNIK I INFORMACJE ZAMÓW INFORMACJE ZAMÓW INFORMACJE O NOWOĎCIACH O NOWOĎCIACH ZAMÓW CENNIK ZAMÓW CENNIK CZYTELNIA CZYTELNIA FRAGMENTY KSI¥¯EK ONLINE FRAGMENTY KSI¥¯EK ONLINE Wydawnictwo Helion ul. Chopina 6 44-100 Gliwice tel. (32)230-98-63 e-mail: helion@helion.pl Spis treści Podziękowania...................................................n................................ 7 Autorzy............................................n.................................................. 9 Wstęp ...................................................n.......................................... 13 Rozdział 1. Zen obrony przed hakerami ...................................................n........... 17 Wprowadzenie...................................................n...................................................n..17 Tao hakera ...................................................n...................................................n.......17 Haker...................................................n...................................................n.........18 Kraker ...................................................n...................................................n.......19 Script Kiddie ...................................................n.................................................20 Phreaker ...................................................n...................................................n....21 Black hat, white hat, co za różnica? ...................................................n.......................22 Gray hat...................................................n...................................................n.....23 Rola hakera ...................................................n...................................................n......24 Przestępca...................................................n...................................................n..24 Sztukmistrz ...................................................n...................................................n25 Specjalista od zabezpieczeń ...................................................n............................26 Obrońca klientów...................................................n...........................................27 Aktywista praw obywatelskich ...................................................n........................28 Cyberwojownik ...................................................n.............................................29 Motywacje hakera ...................................................n...............................................29 Uznanie...................................................n...................................................n......29 Podziw...................................................n...................................................n.......30 Ciekawość...................................................n...................................................n..31 Władza i korzyści...................................................n...........................................31 Zemsta...................................................n...................................................n.......32 Kodeks hakera...................................................n...................................................n..34 Podsumowanie ...................................................n...................................................n.35 Rozwiązania w skrócie ...................................................n.........................................36 Pytania i odpowiedzi ...................................................n............................................37 Rozdział 2. Klasy ataków.........................................n.......................................... 39 Wprowadzenie...................................................n...................................................n..39 Identyfikacja i charakter klas ataków ...................................................n.....................39 Odmowa usługi...................................................n..............................................40 Przecieki informacji ...................................................n.......................................47 Dostęp do systemu plików ...................................................n..............................52 Dezinformacja ...................................................n...............................................54 4 Hack Proofing XML. Edycja polska Dostęp do plików specjalnych i baz danych...................................................n......58 Zdalne uruchomienie dowolnego kodu...................................................n.............60 Rozszerzenie uprawnień ...................................................n.................................62 Metody szukania punktów podatnych na atak...................................................n.........65 Dowód poprawności idei ...................................................n................................65 Standardowe techniki badawcze ...................................................n......................68 Podsumowanie ...................................................n...................................................n.76 Rozwiązania w skrócie ...................................................n.........................................78 Pytania i odpowiedzi ...................................................n............................................79 Rozdział 3. Podstawy języka XML ...................................................n................... 81 Wprowadzenie...................................................n...................................................n..81 Wprowadzenie do języka XML...................................................n.............................82 Założenia XML-a...................................................n...........................................82 Jak wygląda dokument XML?...................................................n.........................82 Tworzenie dokumentu XML...................................................n...........................83 Struktura dokumentu XML...................................................n.............................87 Poprawnie zbudowane dokumenty XML ...................................................n...............87 Transformacja XML-a poprzez XSLT ...................................................n...................88 Wykorzystanie wzorców przez XSL ...................................................n................91 XPath ...................................................n...................................................n..............93 Podsumowanie ...................................................n...................................................n.94 Rozwiązania w skrócie ...................................................n.........................................94 Pytania i odpowiedzi ...................................................n............................................95 Rozdział 4. Typ dokumentu — kontrola poprawności .......................................... 97 Wprowadzenie...................................................n...................................................n..97 Definicje typu dokumentu i poprawnie zbudowane dokumenty XML ..........................98 Schemat i poprawne dokumenty XML...................................................n................. 101 Wprowadzenie do ataków tekstem jawnym...................................................n.......... 104 Ataki tekstem jawnym...................................................n.................................. 106 Sposoby kontroli poprawności XML-a...................................................n................. 109 Kontrola poprawności wprowadzanego tekstu ...................................................n 110 Kontrola poprawności dokumentu lub komunikatu............................................. 115 Podsumowanie ...................................................n.................................................. 123 Rozwiązania w skrócie ...................................................n....................................... 126 Pytania i odpowiedzi ...................................................n.......................................... 127 Rozdział 5. Podpisy cyfrowe w XML-u.............................................n.................. 129 Wprowadzenie...................................................n...................................................n 129 Zasady działania podpisu cyfrowego...................................................n.................... 129 Podstawowe pojęcia podpisów cyfrowych i uwierzytelniania .............................. 130 Zabezpieczanie za pomocą podpisów cyfrowych XML ............................................ 134 Przykłady podpisów XML ...................................................n............................ 134 Podpisywanie części dokumentu...................................................n.................... 143 Przekształcanie dokumentu za pomocą XPath ...................................................n...... 144 Przekształcanie dokumentu za pomocą XSLT ...................................................n...... 145 Zarządzanie listami podpisanych elementów za pomocą manifestów ......................... 147 Ustalanie tożsamości za pomocą X.509...................................................n.......... 149 Algorytmy wymagane i zalecane ...................................................n................... 150 Ostrzeżenia i pułapki...................................................n.......................................... 151 Zestawy narzędzi producentów ...................................................n..................... 152 Podsumowanie ...................................................n.................................................. 153 Rozwiązania w skrócie ...................................................n....................................... 154 Pytania i odpowiedzi ...................................................n.......................................... 156 Spis treści 5 Rozdział 6. Szyfrowanie w XML-u ...................................................n.................. 157 Wprowadzenie...................................................n...................................................n 157 Rola szyfrowania w bezpieczeństwie przesyłanych wiadomości ................................ 158 Bezpieczeństwo wymagane przy przesyłaniu wiadomości................................... 158 Metody szyfrowania...................................................n..................................... 163 Jak stosować szyfrowanie w XML-u?...................................................n.................. 170 Transformacje XML-a przed zaszyfrowaniem ...................................................n 173 Schemat procesu szyfrowania ...................................................n....................... 174 Praktyczne zastosowanie szyfrowania...................................................n.................. 175 Podpisywanie tekstu jawnego zamiast szyfrogramu............................................ 176 Szyfrogram nie pozwala na kontrolę poprawności jawnego tekstu ....................... 178 Szyfrowanie a odporność na kolizje ...................................................n............... 179 Podsumowanie ...................................................n.................................................. 179 Rozwiązania w skrócie ...................................................n....................................... 180 Pytania i odpowiedzi ...................................................n.......................................... 180 Rozdział 7. Kontrola dostępu oparta na rolach.................................................. 183 Wprowadzenie...................................................n...................................................n 183 Mechanizm filtrowania z analizą stanu...................................................n................. 183 Filtrowanie pakietów ...................................................n.................................... 184 Brama warstwy aplikacji...................................................n............................... 185 Proces FTP ...................................................n................................................. 186 Technologie zapór sieciowych i XML...................................................n............ 187 Najpierw analiza stanu...................................................n.................................. 187 Ocena zmian stanu ...................................................n....................................... 189 Wpływ ustawień domyślnych na bezpieczeństwo............................................... 191 Kontrola dostępu oparta na rolach i implementacje wymuszania typu ........................ 192 NSA — architektura Flask ...................................................n............................ 194 SELinux...................................................n...................................................n... 197 Wykorzystanie w XML-u technik kontroli dostępu opartej na rolach ......................... 202 Kiedy dokonywać oceny? ...................................................n............................. 205 Ochrona integralności danych ...................................................n....................... 206 RBAC i Java ...................................................n............................................... 207 Kontrola poprawności obiektów ActiveX ...................................................n....... 210 Narzędzia pomagające w implementacji mechanizmów RBAC ........................... 210 Podsumowanie ...................................................n.................................................. 215 Rozwiązania w skrócie ...................................................n....................................... 216 Pytania i odpowiedzi ...................................................n.......................................... 217 Rozdział 8. .NET i bezpieczeństwo XML-a ...................................................n...... 219 Wprowadzenie...................................................n...................................................n 219 Zagrożenia związane z używaniem XML-a w .NET Framework ............................... 220 Problem poufności ...................................................n....................................... 220 Wewnętrzne zabezpieczenia .NET — realna alternatywa.......................................... 221 Uprawnienia ...................................................n................................................ 222 Uczestnik ...................................................n...................................................n. 223 Uwierzytelnienie...................................................n.......................................... 224 Autoryzacja ...................................................n................................................. 224 Zasady bezpieczeństwa...................................................n................................. 224 Bezpieczeństwo typologiczne...................................................n........................ 224 Bezpieczeństwo dostępu kodu...................................................n............................. 225 Model bezpieczeństwa dostępu kodu w .NET...................................................n. 225 6 Hack Proofing XML. Edycja polska Bezpieczeństwo oparte na rolach...................................................n......................... 240 Uczestnicy...................................................n...................................................n 241 Kontrola zabezpieczeń opartych na rolach ...................................................n...... 244 Zasady bezpieczeństwa ...................................................n...................................... 246 Tworzenie nowego zestawu uprawnień ...................................................n.......... 248 Zmiany w strukturze grup kodu...................................................n..................... 253 Zabezpieczanie Remoting ...................................................n............................. 259 Kryptografia...................................................n...................................................n... 259 Narzędzia zabezpieczeń...................................................n...................................... 262 Zabezpieczanie XML-a — najważniejsze wskazówki............................................... 262 Szyfrowanie w XML-u...................................................n................................. 262 Podpisy cyfrowe w XML-u...................................................n........................... 267 Podsumowanie ...................................................n.................................................. 269 Rozwiązania w skrócie ...................................................n....................................... 271 Pytania i odpowiedzi ...................................................n.......................................... 275 Rozdział 9. Zgłaszanie problemów związanych z bezpieczeństwem .................... 279 Wstęp ...................................................n...................................................n............ 279 Dlaczego należy zgłaszać problemy związane z bezpieczeństwem? ........................... 280 Pełne ujawnienie ...................................................n.......................................... 281 Kiedy i komu zgłosić problem? ...................................................n........................... 284 Komu zgłaszać problemy związane z bezpieczeństwem? .................................... 284 Jak wiele szczegółów publikować? ...................................................n...................... 287 Publikowanie kodu exploitu ...................................................n.......................... 287 Problemy ...................................................n...................................................n. 288 Podsumowanie ...................................................n.................................................. 290 Rozwiązania w skrócie ...................................................n....................................... 291 Pytania i odpowiedzi ...................................................n.......................................... 292 Dodatek A Hack Proofing XML — rozwiązania w skrócie .................................. 295 Rozdział 1. Zen obrony przed hakerami ...................................................n............... 295 Rozdział 2. Klasy ataków ...................................................n................................... 297 Rozdział 3. Podstawy języka XML...................................................n...................... 298 Rozdział 4. Typ dokumentu — kontrola poprawności .............................................. 299 Rozdział 5. Podpisy cyfrowe w XML-u ...................................................n............... 300 Rozdział 6. Szyfrowanie w XML-u ...................................................n..................... 302 Rozdział 7. Kontrola dostępu oparta na rolach ...................................................n...... 303 Rozdział 8. .NET i bezpieczeństwo XML-a...................................................n.......... 303 Rozdział 9. Zgłaszanie problemów z bezpieczeństwem ............................................ 307 Skorowidz...................................................n................................... 309 Rozdział 4. Typ dokumentu — kontrola poprawności Wprowadzenie Definicja typu dokumentu (DTD — document type definition) i schemat (Schema) gra- ją zasadniczą rolę w zapewnianiu poprawności dokumentu XML. Te dwa mechani- zmy są ze sobą skojarzone na wiele sposobów, lecz każdy z nich spełnia odpowiednią funkcję w weryfikacji, czy dokument XML będzie zachowywał się zgodnie z oczeki- waniami. Właściwe wykorzystanie DTD i schematów pomaga programiście koncen- trować się na projekcie struktury danych, zamiast martwić się o błędy pisowni i formy, spowalniając proces twórczy. W niniejszym rozdziale najpierw zajmiemy się mechanizmami działania DTD i sche- matów dostępnych dla XML-a. Zobaczymy, czym różnią się DTD i schemat oraz jak mogą razem służyć do zapewnienia poprawności dokumentu. Następnie opiszemy ogólne zasady ataku tekstem jawnym oraz zakończymy rozdział kilkoma poradami, na co należy zwracać uwagę przy kontroli poprawności XML-a. Kontrola poprawności (validation) dokumentu XML i komunikatów wysyłanych do niego jest pierwszą czynnością podczas zabezpieczania XML-a przed włamaniami. Właściwości, które czynią z XML-a potężny język służący do definiowania danych w dowolnych systemach powodują zarazem, iż jest on podatny na ataki. Co więcej, ponieważ wiele zapór firewall przepuszcza dane XML bez filtrowania, źle zbudowa- ny i nie sprawdzony pod względem poprawności dokument XML może stanowić po- ważną lukę w zabezpieczeniach na poziomie systemu. 98 Hack Proofing XML. Edycja polska Definicje typu dokumentu i poprawnie zbudowane dokumenty XML DTD są strukturalnymi narzędziami kontroli poprawności dokumentów XML. Ze- wnętrzne DTD mogą opisywać właściwości atrybutów, elementów i jednostek stoso- wanych w dokumencie XML. Do opisywanych właściwości należą zawartość, ilość (liczba) i struktura każdej pozycji. DTD mogą być częścią dokumentu lub zewnętrz- nymi obiektami względem używających je dokumentów. Definicjami DTD mogą być specjalnie stworzone opisy struktur danych, składniki specyfikacji stosowanych przez partnerów w biznesie lub też standardowe dokumenty używane przez autorów doku- mentów XML na całym świecie. Zanim będziemy mogli użyć DTD do sprawdzenia, czy dany dokument jest popraw- nie zbudowany, musimy zdeklarować tę definicję. Deklaracja DTD dla prostej pozy- cji w katalogu może wyglądać następująco: !ZONXGTUKQP!  1 6;2 ECVCNQI=  . / 06-CVCNQI 2TQFWMV  . / 062TQFWMV 0T2TQFWMVW 0CYC2TQFWMVW  GPC5MNGRQYC  . / 060T2TQFWMVW 2 #6#  . / 060CYC2TQFWMVW 2 #6#  . / 06 GPC5MNGRQYC 2 #6#  06+6;EQOOGPVAQWVQHUVQEM6GPVQYCTLGUVLWľPKGFQUUVGRP[YOCIC[PKG ? Powyższy fragment kodu DTD oznacza, iż katalog może zawierać dowolną liczbę wpisów produktów, aczkolwiek nie musi zawierać ani jednego. Każdy produkt może (lecz nie musi) posiadać elementy 0T2TQFWMVW, 0CYC2TQFWMVW i GPC5MNGRQYC, które są danymi typu znakowego. Ponadto, zdefiniowaliśmy stałą łańcuchową, która zawsze zawiera komunikat o wyczerpaniu zapasów produktu. Proszę zwrócić uwagę, że DTD może ograniczyć typ danych zawartych w elemencie do danych znakowych, lecz nie wymusza określonego układu cyfr, liter i znaków sterujących, o ile nie definiuje trans- lacji łańcucha znaków dla nazwy jednostki. Jak zobaczymy w dalszej części rozdziału, w tych kontekstach schematy pozwalają na o wiele dokładniejszą kontrolę niż DTD. Poprzedni przykład mógł zdefiniować te same informacje w sposób nieco odmienny, definiując atrybuty elementu 2TQFWMV. DTD stworzony w ten sposób wyglądałby na- stępująco: !ZONXGTUKQP!  1 6;2 ECVCNQI=  . / 06-CVCNQI 2TQFWMV  . / 062TQFWMV /26; #66.+562TQFWMV0T2TQFWMVW #6#4 37+4 0CYC2TQFWMVW #6#4 37+4  GPC5MNGRQYC #6#4 37+4  06+6;EQOOGPVAQWVQHUVQEM6GPVQYCTLGUVLWľPKGFQUUVGRP[YOCIC[PKG ? Rozdział 4. ♦ Typ dokumentu — kontrola poprawności 99 Powyższa definicja DTD mówi, iż element -CVCNQI posiada jeden podelement — 2TQ FWMV. Liczba produktów może być dowolna (również 0). 2TQFWMV nie posiada podele- mentów, jedynie trzy atrybuty:  0T2TQFWMVW  0CYC2TQFWMVW  GPC5MNGRQYC Te trzy atrybuty muszą posiadać wartości, jeśli element 2TQFWMV istnieje. Definiowane informacje w obu przypadkach są takie same, lecz istnieją subtelne różnice w sposo- bach organizacji danych i kontroli danych potomnych przez element nadrzędny. DTD nie są zapisywane zgodnie ze składnią dokumentu XML. Spoglądając na proste DTD z przykładów, zauważymy, iż struktura języka różni się od normalnej składni XML-a. Oznacza to, że poprawność dokumentu DTD nie może być sprawdzana przez analizator składni kontrolujący poprawność XML-a. Jednym z powodów, dla których opracowano schematy, była chęć pozbycia się w XML-u po- trzeby stosowania dwóch odrębnych gramatyk: jednej dla dokumentu XML, a drugiej dla narzędzia nadającego strukturę i sprawdzającego poprawność. DTD mogą być albo wewnętrzne (zawarte w samym dokumencie XML) lub zewnętrz- ne (w serwerze, do którego dokument ma dostęp). Zewnętrzne DTD są powszechnie spotykane i często używane do wymuszenia określonej struktury danych lub jednoli- tej stylistyki dokumentów tworzonych przez różne wydziały lub jednostki partnerskie. Odwołanie do zewnętrznej definicji DTD wymaga użycia zewnętrznej deklaracji o na- stępującej postaci:  1 6;2 ECVCNQI5;56 /JVVRVGORWTKQTI CVCNQIFVF Kilka podstawowych deklaracji i atrybutów pokrywa ogromną większość instrukcji spotykanych w DTD, zarówno wewnętrznych, jak i zewnętrznych. Tabela 4.1 przed- stawia najważniejsze typy atrybutów i ich zastosowania. Tabela 4.2 zawiera najprzy- datniejsze deklaracje elementów i ich właściwości. Tabela 4.3 wymienia najczęściej stosowane atrybuty DTD i ich definicje. Tabela 4.1. Typy i zastosowanie atrybutów DTD Typ atrybutu Zastosowanie atrybutu Właściwości atrybutu #6# #66.+56PCYC #6# 06+6;  06+6;HQVQ5;56 / E HQVQLRI Dane znakowe. Może zawierać znaki (), znaki przedstawione jako nazwy (NV) lub numery () Odwołanie do obiektu, który nie będzie analizowany składniowo. Poprzez deklaracje PVKV[ są często tworzone odwołania do plików graficznych lub multimedialnych. 100 Hack Proofing XML. Edycja polska Tabela 4.1. Typy i zastosowanie atrybutów DTD — ciąg dalszy Typ atrybutu Zastosowanie atrybutu Właściwości atrybutu PWOGTCVKQP #66.+56EGINC NKEQYMC^ HCMVWTQYCPC 4 37+4 Lista atrybutów. Atrybuty rozdzielone przez znak ^ muszą być pobierane pojedynczo. + + 4 ( #66.+56/NQVGM5-7+ 4 37+4 #66.+560CTGFKC /NQVGM5-7+ 4 (4 37+4 0/61- 0 #66.+56MNWE0/61- 0 4 37+4 016#6+10 #66.+56V[RQITCHKEP[ 016#6+104 37+4 Wartość atrybutu musi być legalną nazwą XML. Musi też być unikatowa w obrębie dokumentu. Przypomina to stosowanie atrybutu klucza w bazach danych. Wartość atrybutu jest identyfikatorem innego elementu i musi się ściśle zgadzać (proszę pamiętać o rozróżnianiu wielkości liter). Ten atrybut służy do wywoływania identyfikatorów zdeklarowanych w atrybucie + . Wartość atrybutu musi być legalną nazwą XML. W tym przypadku nazwa nie ma specjalnej funkcji ani możliwości, lecz funkcjonuje przede wszystkim jako etykieta. Może być to przydatne przy przekazywaniu poprzez dokument XML informacji do języka programowania, np. Javy. Kolejna metoda wskazania na plik lub inny zasób, np. zawartość multimedialną, nie podlegająca analizie składni. Tabela 4.2. Deklaracje i właściwości elementów DTD Deklaracje elementów Właściwości deklaracji 2 #6# #0; JQKEGU Analizowane składniowo dane znakowe. Podobny do typu atrybutu #6#. Musi zawierać jedynie znaki. Oznacza, że element może zawierać dane dowolnego typu. Element może zawierać dowolny z listy elementów potomnych. Elementy potomne rozdzielone przecinkami mogą być wszystkie obecne. Gdy elementy rozdzielone są znakiem (^), wówczas może być obecny jeden, lecz nie wszystkie. Tabela 4.3. Atrybuty DTD i ich definicje Atrybut domyślny Definicja atrybutu (KZGF +ORNKGF .KVGTCN 4GSWKTGF Atrybut będzie miał wartość zdefiniowaną w deklaracji. Wartość ta nie może zostać zmieniona i pozostaje stała przez cały czas działania aplikacji. Atrybut opcjonalny. Zdefiniowany element może pozostać pusty bez skutków ubocznych. Atrybut posiada wartość początkową (domyślną) podaną w deklaracji. Wartość ta może zostać zmieniona przez dane wejściowe lub działanie aplikacji. Do atrybutu musi być przypisana wartość. Rozdział 4. ♦ Typ dokumentu — kontrola poprawności 101 Schemat i poprawne dokumenty XML Każdy dokument XML, aby prawidłowo funkcjonować, musi być poprawnie zbudo- wany (well-formed) i poprawny (Valid). Są to dwie niezależne nazwy dwóch całkiem odrębnych właściwości dokumentu. Poprawnie zbudowany dokument XML może nie być poprawnym dokumentem XML, lecz dokument XML nie zbudowany poprawnie nie może być poprawny. Poprawnie zbudowany dokument XML spełnia określone wymagania dotyczące znaczników elementu głównego, znaczników początkowych i końcowych, elementów i atrybutów oraz dopuszczalnych znaków. Poprawna budowa dotyczy struktury dokumentu, lecz nie jego zawartości. Z drugiej strony, poprawny do- kument XML spełnia kryteria zdefiniowane w swojej definicji DTD lub w schemacie. DTD i schematy są w istocie dwoma odmiennymi sposobami ustanawiania reguł do- tyczących zawartości dokumentu XML. DTD ma dłuższą historię i bardziej ugrunto- wane standardy, lecz posiada znaczące ograniczenia w porównaniu ze schematem. Po pierwsze, dokument DTD nie może być napisany w XML-u. Oznacza to, iż DTD nie jest dokumentem XML. Po drugie, wybór typów danych dostępnych przy definiowaniu zawartości atrybutu lub elementu jest w DTD bardzo ograniczony. Schemat nie tylko definiuje strukturę danych opisanych przez dokument, lecz również pozwala autorowi definiować określone składniki struktury danych. Dla jednego dokumentu XML możemy użyć zarówno DTD, jak i schematów, lecz poziom kontroli dostępny w schematach czyni z nich cenniejsze niż DTD narzędzie do zabezpieczania danych i komunikatów definiowanych w dokumencie. Organizacja W3C przedstawiła propozycję standardowej specyfikacji schematu (http://www.w3. org/XML/Schema.html#dev). Schemat jest po prostu zbiorem wstępnie zdefiniowanych reguł, opisujących dane za- warte w dokumencie XML. Ideowo schemat jest bardzo podobny do definicji tablicy w relacyjnej bazie danych. W schemacie XML definiujemy strukturę XML dokumen- tu, jego elementy, typy danych elementów i skojarzonych z nimi atrybutów, a co naj- ważniejsze, stosunki nadrzędny-podrzędny pomiędzy elementami. Możemy tworzyć schematy na różne sposoby. Jednym z nich jest ręczne wprowadzanie informacji za pomocą Notatnika. Możemy też tworzyć schematy za pomocą narzędzi wizualnych, np. VS.NET i XML Authority. Wiele zautomatyzowanych narzędzi potrafi też gene- rować surowe schematy na podstawie przykładowych dokumentów XML (technika ta przypomina inżynierię wsteczną). Jeśli nie chcemy ręcznie pisać schematu, możemy wygenerować surowy schemat z przykładowego dokumentu XML za pomocą progra- mu VS.NET XML Designer. Następnie będziemy mogli dopasować schemat tak, by stał się ściśle zgodny z naszymi regułami biznesowymi. W VS.NET wygenerowanie schematu z przykładowego dokumentu XML wymaga zaledwie jednego kliknięcia myszą. Aby utworzyć surowy schemat z naszego dokumentu Catalog1.xml (patrz: ry- sunek 4.1 bazujący na listingu z rozdziału 3.): 1. Otwórz plik Catalog1.xml (dostępny pod adresem ftp://ftp.helion.pl/przyklady/ hpxmlp.zip) w projekcie VS.NET. VS.NET wyświetli dokument XML i jego widoki XML i Data na dole okna. 2. Kliknij XML w menu Main i wybierz Create Schema (Utwórz schemat). Hack Proofing XML. Edycja polska 102 Rysunek 4.1. Fragment schematu XSD wygenerowanego przez program XML Designer I to już wszystko! System utworzy schemat o nazwie Catalog1.xsd. Jeśli klikniemy podwójnie ten plik w Solution Explorerze, zobaczymy ekran jak na rysunku 4.1. Pro- szę zwrócić uwagę na zakładki DataSet i XML na dole ekranu. Widok DataSet omó- wimy w dalszej części rozdziału. Na potrzeby naszej dyskusji poniżej zamieściliśmy również listing schematu (Cata- log1.xsd). Deklaracja schematu XML (XSD — XML Schema Declaration) zaczyna się od określonych standardowych wpisów. Wprawdzie kod XSD może wydawać się złożony, lecz nie musimy bać się jego składni. W rzeczywistości strukturalna część XSD jest bardzo prosta. Zgodnie z definicją element może posiadać jedną lub więcej struktur danych EQORNGZ6[RG lub UKORNG6[RG. Struktura danych EQORNGZ6[RG zagnież- dża inne struktury danych EQORNGZ6[RG i UKORNG6[RG. Struktura UKORNG6[RG zawiera jedynie dane. W naszym przykładzie XSD (patrz poniżej) element -CVCNQI może zawierać jeden lub więcej (WPDQWPFGF) egzemplarzy elementu 2TQFWMV. Wobec tego element -CVCNQI jest definiowany jako zawierający strukturę EQORNGZ6[RG. Poza elementami 2TQFWMV ele- ment -CVCNQI może zawierać też inne elementy, na przykład 5WRRNKGT. W formancie XSD definiujemy tę regułę za pomocą struktury EJQKEG, jak poniżej: ZUFGNGOGPVPCOG-CVCNQIOUFCVC+U CVC5GVVTWG ZUFEQORNGZ6[RG ZUFEJQKEGOCZ1EEWTUWPDQWPFGF   ZUFEJQKEG ZUFEQORNGZ6[RG ZUFGNGOGPV Ponieważ element 2TQFWMV zawiera inne elementy, więc zawiera również strukturę EQORNGZ6[RG. Ta z kolei sekwencję (UGSWGPEG) 0T2TQFWMVW i GPC5MNGRQYC. 0T2TQFWMVW i GPC5MNGRQYC nie zawierają dalszych elementów, więc w ich definicjach po prostu podajemy ich typ danych. Automatyczny generator nie poradził sobie ze zidentyfiko- waniem tekstu w elemencie GPC5MNGRQYC jako dziesiętnych danych liczbowych; prze- kształciliśmy typ danych na dziesiętny ręcznie. Listing 4.1. Catalog1.xsd ZUFUEJGOCKF-CVCNQI VCTIGV0COGURCEGJVVRVGORWTKQTI CVCNQIZUF ZONPUJVVRVGORWTKQTI CVCNQIZUF ZONPUZUFJVVRYYYYQTI:/.5EJGOC Rozdział 4. ♦ Typ dokumentu — kontrola poprawności 103 ZONPUOUFCVCWTPUEJGOCUOKETQUQHVEQOZONOUFCVC CVVTKDWVG(QTO GHCWNVSWCNKHKGFGNGOGPV(QTO GHCWNVSWCNUKHKGF ZUFGNGOGPVPCOG-CVCNQIOUFCVC+U CVC5GVVTWG OUFCVC PHQTEG QPUVTCKPVU(CNUG ZUFEQORNGZ6[RG ZUFEJQKEGOCZ1EEWTUWPDQWPFGF ZUFGNGOGPVPCOG2TQFWMV ZUFEQORNGZ6[RG ZUFUGSWGPEG ZUFGNGOGPVPCOG0T2TQUFWMVW V[RGZUFUVTKPIOKUP1EEWTU ZUFGNGOGPVPCOG0CYC2UTQFWMVW V[RGZUFUVTKPIOKUP1EEWTU ZUFGNGOGPVPCOG GPCU5MNGRQYC V[RGZUFUVTKPIOKUP1EEWTU ZUFUGSWGPEG ZUFEQORNGZ6[RG ZUFGNGOGPV ZUFEJQKEG ZUFEQORNGZ6[RG ZUFGNGOGPV ZUFUEJGOC Narzędzia i pułapki... Kontrola poprawności XML-a w VS.NET VS.NET udostępnia szereg narzędzi do pracy z dokumentami XML. Jedno z nich po- zwala sprawdzić, czy dany dokument XML jest poprawnie zbudowany. Pracując w wi- doku XML dokumentu XML, możemy z menu Main wybrać XML/Validate XML Data, aby sprawdzić, czy dokument jest poprawnie zbudowany. System wyświetla zdobyte informacje w lewym dolnym rogu paska stanu. Analogicznie możemy wykorzystać na- rzędzie Schema Validation, aby sprawdzić, czy schemat jest poprawnie zbudowany. W tym celu w widoku XML schematu wybierz z menu Main opcję Schema/Validate Schema. Jednakże żaden z powyższych testów nie gwarantuje poprawności danych w XML-u zgodnie z regułami określonymi w schemacie. Aby to sprawdzić, musimy najpierw skojarzyć dokument XML z określonym schematem, co pozwoli sprawdzić popraw- ność dokumentu. Aby przypisać schemat do dokumentu XML: 1. Wyświetl dokument XML w widoku XML (w programie XML Designer). 2. Wyświetl Property sheet (arkusz właściwości) — będzie on miał nagłówek DOCUMENT. 3. Otwórz rozwijaną listę wyboru po prawej stronie VCTIGV5EJGOC i wybierz odpowiedni schemat. 4. Teraz możesz sprawdzić poprawność dokumentu XML za pomocą XML/Validate XML Data w menu Main. Przy okazji, wiele pakietów oprogramowania innych producentów również potrafi sprawdzać, czy dokument XML jest poprawnie zbudowany oraz jego poprawność we- dług danego schematu. Stwierdziliśmy, iż w tym kontekście bardzo przydatne są pro- gramy XML Authority (firmy TIBCO) i XML Writer (Wattle Software). Doskonałe narzę- dzie o nazwie XSV jest też dostępne pod adresem http://www.w3.org/2000/09/ webdata/xsv. 104 Hack Proofing XML. Edycja polska Plik XSD jest sam w sobie poprawnie zbudowanym dokumentem XML. Typy danych w schemacie XSL Gdy plik XML odgrywa rolę bazy danych, zaś XSL i XPath rolę zapytań SQL tłuma- czących plik XML, potrzebujemy miejsca, gdzie zadeklarujemy zawartość pliku XML i związane z nią typy danych. Podobnie jak w każdej bazie danych, nieważne, czy jest to SQL Server czy Oracle, wszystkie kolumny posiadają zdefiniowane typy danych. Roz- wiązanie to prowadzi do konieczności wprowadzenia typów danych w schemacie XSL. Istnieją dwa typy typów danych: proste i pochodne. Proste typy danych nie są wy- prowadzane z żadnego innego typu danych (np. float — liczby zmiennoprzecinkowe). Pochodne typy danych opierają się na innych typach. Typ danych całkowitych (inte- ger), na przykład, pochodzi od danych dziesiętnych (decimal). Proste typy danych zdefiniowane na potrzeby schematu XML nie muszą być identyczne jak w specyfikacjach innych baz danych, podobnie jak definiowane przez użytkowni- ka typy danych przeznaczone dla schematu XML nie są przeznaczone dla innych za- sobów. Tabela 4.4 wymienia różnorodne typy danych, z których mogą korzystać sche- maty XML. Wprowadzenie do ataków tekstem jawnym Ataki tekstem jawnym są jednym z najbardziej podstępnych narzędzi służących hake- rom do infiltracji baz danych i aplikacji. Wykorzystują one wykorzystywanie przez XML standardowych znaków języka i fakt, iż znaki te w różnych miejscach aplikacji komputerowej i systemu różne reprezentowane są w różny sposób. Hakerzy wykorzy- stują niestandardowe kodowanie znaków sterujących (np. końca tekstu lub sterowania przepływem) i łańcuchy pozwalające na dostęp do ukrytych plików, nieosiągalny na inne sposoby, oraz na osadzanie w nich wprowadzanych łańcuchów i komunikatów. Zrozumienie, jak XML interpretuje tekst, jest pierwszym ważnym krokiem w kierun- ku ochrony baz danych, aplikacji i systemów przed tymi atakami. Gdy mówimy, że XML jest napisany i komunikuje się tekstem jawnym (zwykłym), mamy na myśli, iż wykorzystuje zestaw znaków ISO-Latin-1. Jest to zestaw znaków używany przez twórców oprogramowania w praktycznie wszystkich krajach Europy Zachodniej i angielskojęzycznych, znany również jako zestaw znaków ASCII (Ame- rican Standard Code for Information Interchange). Inna, bardziej rozszerzona grupa znaków, o ogólnej nazwie Unicode, zawiera znaki stosowane w większości znaczą- cych języków świata oraz w matematyce, logice i przy rysowaniu prostych obiektów. Zestaw znaków Unicode jest odwzorowany bezpośrednio na ISO-Latin-1, zaś oba ze- stawy znaków dają dostęp do liter, cyfr, znaków przestankowych oraz interesujących Rozdział 4. ♦ Typ dokumentu — kontrola poprawności 105 Tabela 4.4. Typy danych w schemacie XML Podstawowy typ danych 5VTKPI $QQNGCP GEKOCN (NQCV QWDNG WTCVKQP FCVG6KOG 6KOG CVG I;GCT/QPVJ I/QPVJ C[ ) C[ )/QPVJ JGZ$KPCT[ DCUG$KPCT[ #P[74+ 3PCOG 016#6+10 );GCT n/d n/d n/d n/d n/d n/d Pochodny typ danych PQTOCNKGF5VTKPI 6QMGP .CPIWCIG 0/61- 0 0/61- 05 0COG 0 0COG + + 4 ( + 4 (5 06+6; 06+6+ 5 +PVGIGT PQP2QUKVKXG+PVGIGT PGICVKXG+PVGIGT .QPI +PV UJQTV $[VG PQP0GICVKXG+PVGIGT WPUKIPGF.QPI WPUKIPGF+PV WPUKIPGF5JQTV WPUKIPGF$[VG RQUKVKXG+PVGIGT Podstawowe aspekty GSWCN QTFGTGF DQWPFGF ECTFKPCNKV[ PWOGTKE n/d n/d n/d n/d n/d n/d n/d n/d n/d n/d n/d n/d n/d n/d n/d n/d n/d n/d n/d n/d Ograniczenia NGPIVJ OKP.GPIVJ OCZ.GPIVJ RCVVGTP GPWOGTCVKQP YJKVG5RCEG OCZ+PENWUKXG OCZ ZENWUKXG OKP ZENWUKXG OKP+PENWUKXG VQVCN KIKVU HTCEVKQP KIKVU n/d n/d n/d n/d n/d n/d n/d n/d n/d n/d n/d n/d n/d znaków dodatkowych (na przykład, sterujących przepływem informacji przez aplikacje i wskazujących systemowi, czy łańcuch wejściowy został z powodzeniem odebrany). Dodatkowe informacje o możliwościach i atrybutach Unicode przedstawimy w dalszej części rozdziału. Bezpośrednie manipulowanie zestawem znaków wymaga umieszczenia liczbowej re- prezentacji znaku pomiędzy symbolami () i średnika (). Ta konwencja jest nieco od- mienna od stosowanej w HTML-u, gdzie wartość liczbowa jest umieszczana pomiędzy zestawem znaków  a średnikiem. Na przykład,  oznacza literę #. Cyfrę  w XML-u przedstawimy, używając:  106 Hack Proofing XML. Edycja polska Te przykłady są proste i oczywiste. Z drugiej strony, poniższy kod jest tłumaczony na „anuluj wiersz”:  Nagle możliwości ASCII zaczynają się wydawać nieco większe. Zarówno w HTML-u, jak i w XML-u znaki mogą być przekazywane jako element łańcucha wejściowego lub komunikatu na jeden z trzech sposobów. Do każdego dru- kowalnego znaku używanego przez XML możemy odwołać się na trzy sposoby: po- przez symbol (do którego jesteśmy przyzwyczajeni), nazwę i przez kod szesnastkowy. Najpowszechniejszym sposobem jest po prostu wpisanie znaku — na przykład sym- bol „mniejszy niż” jest zapisywany jako . Do znaku tego możemy też odwołać się przez jego nazwę, jeśli poprzedzimy ją znakiem . W tym przypadku „mniejszy niż” („less than”) zapiszemy: NV Trzecia metoda, najczęściej stosowana przez hakerów do przeprowadzenia ataku tek- stem jawnym, polega na wprowadzeniu reprezentacji dziesiętnej znaku. XML wyma- ga zamknięcia tej liczby pomiędzy symbolami  i . W tej metodzie „mniejszy niż” zapiszemy:  Ten zapis różni się nieco od stosowanego w HTML-u, gdzie reprezentacja liczbowa jest zamykana pomiędzy # a średnikiem, więc symbol „mniejszy niż” jest zapisywany:  Niektóre znaki w zestawach znaków używanych przez większość aplikacji posiadają jedynie dwie reprezentacje: nazwę i kod liczbowy, ponieważ są znakami niedrukowal- nymi — sterującymi. Znaków sterujących jest cała grupa, od znaku powrotu karetki () i spacji () zaczynając, a kończąc na znakach „koniec transmisji” () i „po- twierdzenie negatywne” (). Osadzanie znaków sterujących aplikacją lub systemem w strumieniu otwartego tekstu zwiększa użyteczność zestawów znaków, lecz zarazem zwiększa podatność na ataki. Ataki tekstem jawnym Programiści i twórcy baz danych najczęściej korzystają z reprezentacji liczbowej zna- ków ASCII do pracy ze znakami nieobecnymi na standardowej angielskiej klawiatu- rze. Na przykład, znaki spotykane w nazwach nordyckich i akcentowane znaki obecne w wielu słowach francuskich, hiszpańskich i niemieckich możemy łatwo wyrazić po- przez reprezentacje liczbowe. Nawet jeśli baza danych i jej interfejs używają jedynie języka angielskiego, reprezentacje numeryczne pozwalają na pewien poziom kontroli typograficznej przekraczający możliwości standardowej klawiatury. Na przykład, okre- ślone typy spacji (o różnej długości) i myślników są definiowane i dostępne w pełnym zestawie znaków ASCII, chociaż nie znajdziemy ich na standardowych klawiaturach komputerowych. Rozdział 4. ♦ Typ dokumentu — kontrola poprawności 107 Włamanie do Internet Information Services (IIS) Microsoftu poprzez niekanoniczny łańcuch wejściowy jest tylko jednym z wielu przykładów ataków tekstem jawnym. Na stronie WWW Computer Emergency Response Team (CERT) znajdziemy niemal 30 niezależnych ostrzeżeń o miejscach podatnych na atak tekstem jawnym, zaś przeszukując Internet, znajdziemy kolejne setki przykładów. Ostrzeżenia publikowa- ne przez CERT i inne serwisy WWW wskazują, iż niekanoniczne kodowanie znaków nie jest jedynym narzędziem, jakiego hakerzy mogą użyć do infiltracji aplikacji. Cza- sami sama objętość jawnego tekstu wystarcza, by przysporzyć problemów atakowa- nym systemom i aplikacjom. Wiele ataków tekstem jawnym wykorzystuje takie luki w zabezpieczeniach, jak np. bufory wejściowe aplikacji, które mogą ulec przepełnieniu i przekazać dane bez- pośrednio do strumieni wykonywanych, zamiast przez normalne zabezpieczające analizatory składniowe. Ograniczenia długości łańcuchów wejściowych w aplika- cjach są ważnymi narzędziami pomagającymi ograniczyć dostęp hakerów do tych najczęściej stosowanych metod włamań. Pełny zestaw znaków ASCII składa się z 256 odrębnych jednostek. Większość z nich stanowią litery, cyfry i inne znaki drukowalne, lecz dwa zakresy definicji nie klasyfiku- ją się jako normalne definicje znaków. Znaki o numerach od 0 do 31 są rozkazami dla drukowania lub urządzeń komunikacyjnych. Ich zakres rozciąga się od powrotu karetki (Carriage Return — ) aż do Device Control 3, znaku ogólnie zarezerwowanego dla komunikatu XOFF (). Znaki od 128 do 159 nie są zdefiniowane w standardzie i zostały zarezerwowane na przyszłe potrzeby lub dla indywidualnych implementacji. Oznacza to, że działanie znaków z tego zakresu jest zależne od przeglądarki, bazy da- nych lub innych aplikacji, które interpretują dokument. W najlepszym przypadku, je- śli definicja znaku nie została z góry ustalona, nie zdefiniowany znak będzie po prostu ignorowany. W najgorszym razie reakcja aplikacji może być nieprzewidywalna. Przykład: kody ucieczki HTML Dane przenoszone w znakowych komunikatach XML-a mogą zawierać znaki kodowa- ne w ASCII i Unicode, nazwy znaków XML i reprezentacje liczbowe oraz szesnast- kowe reprezentacje kodów znaków i ucieczki języka HTML. Kody ucieczki HTML stanowią ciekawą lukę w zabezpieczeniach, ponieważ bardzo rzadko uznawane są za niebezpieczne, a jednak możliwości zaszkodzenia za ich pomocą są olbrzymie. Jak można użyć zestawu znaków do ataku? Wiele luk w zabezpieczeniach ma zwią- zek z nieautoryzowanymi zmianami informacji wyświetlanych na ekranie. Weźmy na przykład stronę WWW zawierającą komunikat, który, aby był widoczny w jak naj- większej liczbie przeglądarek, używa kolorów nazwanych w języku HTML 4.0. Twór- ca strony bezpośrednio definiuje kolory: czarny () dla tekstów i żółty ((((() dla tła. Jeśli wstawimy do tekstu znaczniki definiujące określone fragmenty tekstu jako żółte, wówczas ten tekst będzie obecny, lecz niewidoczny dla użytkowników odwie- dzających stronę. W tym przypadku prosta kontrola, czy każde odwołanie do danych posiada własny wpis, nie wykaże żadnych problemów, podobnie proste sprawdzenie wygenerowanego kodu źródłowego strony również może nie wskazać ich istnienia. Inny przykład dotyczy znaków nie wyświetlanych. Należą do nich znaki sterujące takie jak Escape () i typograficzne, np. spacja (). Luki w bezpieczeństwie 108 Hack Proofing XML. Edycja polska związane z tymi znakami biorą się z faktu, iż reprezentacja ASCII pozostaje niezmien- na, zaś inne (np. zestaw Unicode, który omówimy za chwilę) mogą być różne w róż- nych językach. Jeden z godnych uwagi exploitów poprzez przepełnienie bufora tekstem jawnym dotyczył Oracle 9i i luki w bezpieczeństwie przekazywanej do tego oprogramowania przez Apache — program typu open source, którego Oracle używa jako serwera WWW dla swojego mechanizmu bazy danych. Apache Procedural Language/Struc- tured Query Language jest modułem instrukcji używanym przez Oracle. Okazało się, że prosty atak tekstem jawnym wykorzystujący łańcuchy dłuższe niż oczeki- wane przez aplikację, mógł spowodować przepełnienie bufora, co pozwalało na parsowanie i przesłanie tekstu, który przepełnił bufor, bez interwencji standardo- wego kodu zabezpieczeń. Zapisane w bazie danych procedury mogły być wykonane z uprawnieniami serwera Apache. Biorąc pod uwagę, iż serwer Apache w syste- mach opartych na Windows NT zwykle działa na poziomie systemu, haker wyko- rzystujący to podejście mógł zyskać pełną kontrolę nad atakowanym systemem. Firma Oracle wypuściła łatę, zaproponowano też techniki obejścia tej luki, lecz ata- ki tego typu są najczęściej spotykane i prędzej czy później uderzają we wszelkich producentów większych aplikacji, systemów operacyjnych i routerów sieciowych. Unicode Unicode jest szerokim zbiorem standardów dotyczących zestawów znaków używa- nych przez większość ważniejszych języków na świecie. Dla twórcy dokumentów XML elastyczność, jaką oferuje Unicode, jest istotna, lecz różnorodne sposoby, na ja- kie aplikacje mogą interpretować informacje niesione przez znaki Unicode powodują nieuniknione powstawanie miejsc podatnych na ataki. Pełną listę zestawów znaków Unicode i sposoby ich użycia znajdziemy pod adresem http://www.unicode.org. Gdy system używa jednocześnie zestawów znaków ASCII i Unicode, mogą pojawić się pewne problemy wynikające z podstawowych różnic w obu standardach kodowania. Tradycyjny zestaw ASCII stosuje kodowanie przy wykorzystaniu 8 bitów, przez które liczba znaków w standardzie jest ograniczona do 256. Ponieważ praktycznie wszystkie systemy operacyjne używają ASCII do kodowania informacji wyświetlanych i druko- wanych, zaś Unicode stosują jako rozszerzony kod odwzorowany na ASCII, więc pro- cedury zabezpieczeń szukające określonych „zakazanych” łańcuchów znaków ASCII mogą przepuścić potencjalnie szkodliwe instrukcje osadzone w adresie URL. Jedna z głównych luk w zabezpieczeniach wynika z wyboru metody odwzorowania Unicode na ASCII. Ponieważ Unicode musi radzić sobie z wieloma różnymi symbo- lami w wielu językach, znaki mogą mieć długość 16, 24, a nawet 32 bitów. Wszystkie znaki łacińskie (używane w języku angielskim) są 16-bitowe, lecz część z tych zna- ków (w tym przestankowe i sterujące) możemy znaleźć też w innych językach. W tych innych zestawach znaków ukośniki, kropki i znaki sterujące mogą mieć dłuższe repre- zentacje niż w zestawie znaków łacińskich. Unicode Consortium definiuje metody odwzorowania w UTF-8 (Unicode Transfor- mation Format-8). UTF-8 podaje, iż wszelkie oprogramowanie kodujące dane do Uni- code musi używać najkrótszej z możliwych implementacji. Standard pozostawia jednak Rozdział 4. ♦ Typ dokumentu — kontrola poprawności 109 otwartą możliwość użycia przez program dowolnej możliwej reprezentacji przy deko- dowaniu znaków. Ta niejednoznaczność może zostać wykorzystana do przepuszczenia przez proces zabezpieczający znaków zakazanych. W powszechnie znanym incydencie serwer IIS Microsoftu stał się podatny na żądanie dostępu do bezpiecznych plików. Standardowo łańcuch typu:  nie jest przepuszczany przez procedury bezpieczeństwa IIS, ponieważ poprzez adreso- wanie względne mógłby dać dostęp do katalogów. Gdy do adresu URL został w poniż- szej sekwencji wstawiony ciąg Unicode ECH, wówczas procedury kontrolne zabez- pieczeń, zaprogramowane do dekodowania najkrótszej implementacji, nie rozpoznały w nim ukośnika (). ECHECH Łańcuch był przekazywany do interpretera poleceń, który dekodował go w bardziej ela- styczny sposób jako adres względny, co pozwalało wykorzystać lukę w zabezpieczeniu. Sposoby kontroli poprawności XML-a Sprawdzanie poprawności XML-a jest formalnym procesem kontroli zgodności pli- ków XML z odpowiednimi DTD, schematami lub jednym i drugim. Najpierw musi- my jednak wyraźnie powiedzieć, że dokument XML do funkcjonowania nie wymaga DTD ani schematu. Dokument nie może zostać uznany za poprawny, o ile nie posiada odnośnika do przynajmniej jednego z dwóch powyższych dokumentów i jeśli popraw- ność tego odwołania nie została sprawdzona przez odpowiedni procesor (program do kontroli poprawności). Musimy wiedzieć, w jakiej kolejności DTD i schematy są sto- sowane przy kontroli poprawności dokumentu XML oraz co dokładnie jest kontrolo- wane, by móc prawidłowo wykorzystać wbudowane możliwości procesorów XML-a dla zapewnienia bezpieczeństwa. Musimy też wiedzieć, czego te mechanizmy nie ro- bią, aby utworzyć odpowiednie procedury wewnętrznej kontroli poprawności danych przekazywanych przez XML. Mechanizmy kontroli poprawności XML-a, zarówno DTD, jak i schematy, mają przede wszystkim na celu zachowanie jakości struktur, ograniczeń typów danych i wymusza- nie jednolitości w obrębie organizacji lub systemu aplikacji. Nie zostały one zapro- jektowane ani nie nadają się zbytnio do kontroli spójności danych i ich poprawności dla danej aplikacji. Jeśli wyobrazimy sobie te dwa mechanizmy kontroli poprawności jako sita, wówczas formalną kontrolę poprawności XML-a możemy uznać za sito o du- żych oczkach, które odsiewa poważne niespójności struktury i danych. Drobniejszym sitem, które zapewnia utrzymanie danych w granicach rozsądku (na przykład, aby ce- na gumy do żucia nie wynosiła 50 zł zamiast 0,50 zł), będą procedury weryfikacji da- nych pisane przez lokalnego programistę. W tych procedurach dane wejściowe muszą być kontrolowane pod względem poprawności, prawidłowo dekodowane, a następnie ich zawartość weryfikowana. Wszystko to musi odbywać się w sposób nie obciążają- cy serwera lub oprogramowanie klienta w niedopuszczalnym stopniu. 110 Hack Proofing XML. Edycja polska Zyski z właściwej kontroli poprawności są olbrzymie. Po pierwsze, dobra kontrola poprawności i weryfikacja uniemożliwiają przeprowadzenie większości popularnych typów ataków tekstem jawnym, jakie omawialiśmy do tej pory. Znaki kodowane w nie- typowy sposób lub o zdekodowanej wartości wykraczającej poza granice logicznych parametrów danych są filtrowane ze strumienia danych, zanim zostaną wykonane lub zapisane w bazie danych. Ponadto kontrola jakości danych jest lepsza, ponieważ wpi- sy wykraczające poza granice logiczne są odrzucane na etapie wejścia. Kontrola poprawności wprowadzanego tekstu Bardzo silna może być pokusa, by zdecydować, iż istniejące mechanizmy kontroli po- prawności XML-a powinny całkowicie wystarczyć do zabezpieczania danych wprowa- dzanych przez dokumenty XML. Jak, niestety, przekonaliśmy się, hakerzy zbyt łatwo mogą wykorzystać różnice pomiędzy zestawami znaków tekstu jawnego do zaatakowa- nia systemu używającego poprawnie zbudowanych i poprawnych dokumentów XML. Wobec tego twórca aplikacji musi zbudować niezależne procedury kontroli poprawno- ści danych, przechodzących do aplikacji przez dokument XML sprawdzony pod wzglę- dem poprawności. Odpowiednie podejście polega na rozbiciu problemu weryfikacji na szereg odrębnych kroków. Pierwszym w kolejności (aczkolwiek omówimy go na końcu) jest formalna kontrola poprawności dokumentów definiujących podstawowe dane poprzez analiza- tory składni DTD i schematu. Następnie odbywa się obróbka potoku wejściowego przy odbiorze przez aplikację. Kolejnym ważnym krokiem jest upewnienie się, czy każdy znak wejściowy jest poprawny w ramach definicji języka oraz czy każdy został zdekodowany zgodnie z odwzorowaniem uznanym przez wszystkie składniki aplika- cji. Na koniec zmuszenie, by każdy prawidłowo zdekodowany wpis mieścił się w lo- gicznych granicach aplikacji, pomaga w wyeliminowaniu zarówno celowo wprowa- dzonego złośliwego kodu, jak i niezamierzonych konsekwencji pomyłek ludzkich. Sprowadzenie do postaci kanonicznej Sprowadzenie do postaci kanonicznej oznacza zdolność do nadania dokumentowi naj- prostszej możliwej formy. Proces ten tworzy dokumenty równe sobie semantycznie z nierównych poprzez normalizację danych, analizę składniową i aranżację elemen- tów w formę neutralną składniowo. Sprowadzanie do postaci kanonicznej omówimy nieco bardziej szczegółowo w rozdziale 6., lecz obecnie musimy pokrótce opisać za- stosowanie tego procesu w podpisach cyfrowych XML. Sprowadzanie do postaci kanonicznej w podpisach cyfrowych XML Natura Unicode powoduje, iż niektóre najczęściej używane znaki (spacje, powrót karet- ki, koniec wiersza itp.) są reprezentowane w zestawach znaków o różnych długościach. W najnowszych wersjach standardów kodowania organizacja Unicode nakazała, by wszelkie oprogramowanie kodowało znaki do najkrótszych reprezentacji, jednakże oprogramowanie ma prawo dekodować wszelkie możliwe reprezentacje, aby utrzymać Rozdział 4. ♦ Typ dokumentu — kontrola poprawności 111 zgodność wstecz ze starszymi wersjami programów. Oznacza to, że istniejące anali- zatory składni XML sprowadzają kilka różnych reprezentacji szesnastkowych do tych samych znaków, co może stworzyć możliwości ataków wspomnianych wcześniej w niniejszym rozdziale. Twórcy dokumentów XML muszą też zdawać sobie sprawę z różnych poziomów ob- sługi kodów ASCII i Unicode w używanych przez siebie narzędziach programistycz- nych. Języki programowania takie jak Perl, Python czy Tcl oraz interfejsy typu Sim- ple API for XML (SAX) i Document Object Module (DOM) są powszechnie stosowane przy programowaniu mającym związek z XML-em. Każdy z nich obsługuje jedną lub kilka odmian znaków Unicode, lecz poszczególne języki i interfejsy różnią się zdecy- dowanie sposobami działania tej obsługi. Na przykład, Perl zwraca dane w formacie UTF-8, mimo że nie obsługuje pełnych implementacji Unicode. Jeśli potrzebne są znaki spoza UTF-8, wówczas muszą być bezpośrednio obsługiwane przez moduł 7PKEQFG5VTKPI. Niektóre procesory XML-a dostępne dla Perla, np. SAX i DOM, obsługują pełny standard Unicode. Ponieważ procesorów SAX i DOM jest kilka, a każdy z nich traktuje Unicode w nieco odmien- ny sposób, radzimy przejrzeć dokumentację używanego modułu, aby sprawdzić szcze- góły kodowania znaków. W przeciwieństwie do języka Perl, Python nie używa Unicode ani żadnej jego formy jako wewnętrznego formatu kodowania znaków. Zamiast tego udostępnia łańcuchy Unicode jako dostępny dla programisty typ obiektu danych. Każdy łańcuch znakowy może zostać zakodowany jako obiekt Unicode, jeśli umieścimy przed łańcuchem znak W. Na przykład: HCUVUJKR 9[U[NMCVGIQUCOGIQFPKC Powyższy łańcuch zostanie zakodowany w ASCII. Następny przykład koduje ten sam łańcuch w Unicode: HCUVUJKRW 9[U[NMCVGIQUCOGIQFPKC Tcl obsługuje Unicode bezpośrednio poprzez analizator składni TclXML. Jeśli chce- my obrabiać określony łańcuch znaków zakodowany w inny sposób, wówczas funkcja encoding pozwala na łatwe przejście z Unicode na ASCII, z UTF-8 na UTF-16 oraz pomiędzy dowolnymi innymi metodami kodowania znaków obsługiwanymi przez określony system. Powinno być oczywiste, że przy tak wielkiej liczbie sposobów kodowania danych zna- kowych zależnych od użytych narzędzi programistycznych spoczywa na programiście obowiązek opracowania procedur kontroli poprawności danych wprowadzanych do aplikacji poprzez XML. Aby ustrzec się ataków opartych na dłuższych niż minimalne reprezentacjach znaków, może okazać się konieczna obsługa wielu zestawów znaków Unicode poprzez bezpośrednie instrukcje w odpowiednich procesach. Zamiast tego możemy też zdecydować o obsłudze jedynie kodowania w UTF-8, zwłaszcza jeśli li- sta języków używanych w zbiorach danych dla aplikacji jest ograniczona. 112 Hack Proofing XML. Edycja polska Narzędzia i pułapki Narzędzia kontroli poprawności dokumentów XML Narzędzia służące do kontroli poprawności dokumentów XML i związanych z nimi da- nych możemy zaklasyfikować zgodnie z trzema podstawowymi etapami kontroli po- prawności, niezbędnymi do zminimalizowania możliwości wystąpienia niezamierzo- nych lub złośliwych szkód w systemie. Tymi trzema etapami są integralność XML-a, sprowadzenie danych wejściowych do postaci kanonicznej i kontrola poprawności w aplikacji. Dla dwóch pierwszych etapów dostępne są narzędzia pozwalające two- rzyć aplikacje odporne na ataki. We wszystkich trzech obszarach musimy znaleźć od- powiednią równowagę pomiędzy siłą metod kontroli poprawności a kosztem i poten- cjalnymi słabościami. Przyjrzyjmy się każdemu etapowi osobno:  Integralność XML-a — dokumenty XML poprawnie zbudowane i poprawne stanowią podstawę dla poprawnych danych. Zarówno DTD, jak i schematy są bardzo pomocne przy tworzeniu właściwych dokumentów, zaś do zapewnienia zgodności dokumentu ze standardami XML, DTD i schematami dostępne są odpowiednie narzędzia. O’Reilly, Brown University i W3C Consortium udostępniają narzędzia online, pozwalające na skanowanie i kontrolę poprawności dokumentów XML. Każde z tych narzędzi jest inne; Brown University oferuje najbardziej szczegółowe raporty, zaś O’Reilly najbardziej zwięzłe, lecz stosując dwa z nich lub więcej możemy upewnić się, czy nasz kod jest prawidłowo zbudowany i zgodny z załączonymi DTD i schematami. Narzędzia uruchamiane lokalnie również są dostępne. XML Spy firmy Altova jest wiodącym komercyjnym narzędziem służącym do tworzenia i kontroli poprawności dokumentów XML. Microsoft i Sun Microsystems udostępniają narzędzia kontroli poprawności do darmowego ściągnięcia, aczkolwiek narzędzie Microsoftu nie jest wspierane przez producenta, zaś często aktualizowany produkt firmy Sun jest podstawą dla narzędzia kontroli poprawności XML-a w oprogramowaniu open source Apache.  Dane wejściowe w postaci kanonicznej — istnieje wiele sposobów, na jakie znaki, zwłaszcza niedrukowalne i wspólne dla wszystkich języków, mogą być reprezentowane liczbowo w systemie. Właściwe stosowanie funkcji języków programowania, na przykład /WNVK$[VG9KFG6Q JCT Microsoftu, GPEQFG i WPKEQFGFCVC z języka Python oraz EQPXGTVHTQO i EQPXGTVVQ z języka Tcl pozwala zapewnić konwersję znaków z wielu różnych zestawów Unicode do wspólnej, najkrótszej reprezentacji, zanim rozpocznie się przetwarzanie zakodowanych danych.  Kontrola poprawności dla aplikacji — ostatnim krokiem przy zapewnianiu integralności
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

Hack Proofing XML. Edycja polska
Autor:

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: