SlideShare une entreprise Scribd logo

Hack Proofing XML. Edycja polska

•
•
Wydawnictwo Helion
Wydawnictwo Helion

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. * Dowiesz się, kim są hackerzy Poznasz wyjaśnienie terminów: haker, cracker, black hat, phreaker i script kiddies -- nauczysz się rozpoznawać prawdziwe zagrożenia * 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 * 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 * Poznasz atak "czystym tekstem" To potężna broń hakerów, zabezpiecz przed nią swój system * 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 * 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 * 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 * 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 * Dowiesz się, jak zgłaszać błędy Kogo, kiedy i w jaki sposób informować o wykrytych dziurach w zabezpieczeniach? Jak wiele informacji ujawniać?

1  sur  37
Télécharger pour lire hors ligne
IDZ DO PRZYK£ADOWY ROZDZIA£ SPIS TRE CI Hack Proofing XML. Edycja polska KATALOG KSI¥¯EK Autor: praca zbiorowa KATALOG ONLINE T³umaczenie: Adam Jarczyk ISBN: 83-7361-004-9 Tytu³ orygina³u: Hack Proofing XML ZAMÓW DRUKOWANY KATALOG Format: B5, stron: 324 Przyk³ady na ftp: 15 kB TWÓJ KOSZYK DODAJ DO KOSZYKA 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¹ CENNIK I INFORMACJE 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, ZAMÓW INFORMACJE które czyni¹ XML silnym i uniwersalnym narzêdziem sprawiaj¹, ¿e jest on podatny na O NOWO CIACH 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 ZAMÓW CENNIK zagro¿enie dla systemów. „Hack Proofing XML. Edycja polska” obja ni Ci wszystkie niuanse bezpieczeñstwa zwi¹zane z technologiami XML i .NET. CZYTELNIA 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................................................................................... 7 Autorzy.............................................................................................. 9 Wstęp ............................................................................................. 13 Rozdział 1. Zen obrony przed hakerami .............................................................. 17 Wprowadzenie........................................................................................................17 Tao hakera .............................................................................................................17 Haker...............................................................................................................18 Kraker .............................................................................................................19 Script Kiddie ....................................................................................................20 Phreaker ..........................................................................................................21 Black hat, white hat, co za ró nica? ..........................................................................22 Gray hat...........................................................................................................23 Rola hakera ............................................................................................................24 Przestępca........................................................................................................24 Sztukmistrz ......................................................................................................25 Specjalista od zabezpieczeń ...............................................................................26 Obrońca klientów..............................................................................................27 Aktywista praw obywatelskich ...........................................................................28 Cyberwojownik ................................................................................................29 Motywacje hakera ..................................................................................................29 Uznanie............................................................................................................29 Podziw.............................................................................................................30 Ciekawość........................................................................................................31 Władza i korzyści..............................................................................................31 Zemsta.............................................................................................................32 Kodeks hakera........................................................................................................34 Podsumowanie .......................................................................................................35 Rozwiązania w skrócie ............................................................................................36 Pytania i odpowiedzi ...............................................................................................37 Rozdział 2. Klasy ataków................................................................................... 39 Wprowadzenie........................................................................................................39 Identyfikacja i charakter klas ataków ........................................................................39 Odmowa usługi.................................................................................................40 Przecieki informacji ..........................................................................................47 Dostęp do systemu plików .................................................................................52 Dezinformacja ..................................................................................................54
4 Hack Proofing XML. Edycja polska Dostęp do plików specjalnych i baz danych.........................................................58 Zdalne uruchomienie dowolnego kodu................................................................60 Rozszerzenie uprawnień ....................................................................................62 Metody szukania punktów podatnych na atak............................................................65 Dowód poprawności idei ...................................................................................65 Standardowe techniki badawcze .........................................................................68 Podsumowanie .......................................................................................................76 Rozwiązania w skrócie ............................................................................................78 Pytania i odpowiedzi ...............................................................................................79 Rozdział 3. Podstawy języka XML ...................................................................... 81 Wprowadzenie........................................................................................................81 Wprowadzenie do języka XML................................................................................82 Zało enia XML-a..............................................................................................82 Jak wygląda dokument XML?............................................................................82 Tworzenie dokumentu XML..............................................................................83 Struktura dokumentu XML................................................................................87 Poprawnie zbudowane dokumenty XML ..................................................................87 Transformacja XML-a poprzez XSLT ......................................................................88 Wykorzystanie wzorców przez XSL ...................................................................91 XPath ....................................................................................................................93 Podsumowanie .......................................................................................................94 Rozwiązania w skrócie ............................................................................................94 Pytania i odpowiedzi ...............................................................................................95 Rozdział 4. Typ dokumentu — kontrola poprawności .......................................... 97 Wprowadzenie........................................................................................................97 Definicje typu dokumentu i poprawnie zbudowane dokumenty XML ..........................98 Schemat i poprawne dokumenty XML.................................................................... 101 Wprowadzenie do ataków tekstem jawnym............................................................. 104 Ataki tekstem jawnym..................................................................................... 106 Sposoby kontroli poprawności XML-a.................................................................... 109 Kontrola poprawności wprowadzanego tekstu ................................................... 110 Kontrola poprawności dokumentu lub komunikatu............................................. 115 Podsumowanie ..................................................................................................... 123 Rozwiązania w skrócie .......................................................................................... 126 Pytania i odpowiedzi ............................................................................................. 127 Rozdział 5. Podpisy cyfrowe w XML-u............................................................... 129 Wprowadzenie...................................................................................................... 129 Zasady działania podpisu cyfrowego....................................................................... 129 Podstawowe pojęcia podpisów cyfrowych i uwierzytelniania .............................. 130 Zabezpieczanie za pomocą podpisów cyfrowych XML ............................................ 134 Przykłady podpisów XML ............................................................................... 134 Podpisywanie części dokumentu....................................................................... 143 Przekształcanie dokumentu za pomocą XPath ......................................................... 144 Przekształcanie dokumentu za pomocą XSLT ......................................................... 145 Zarządzanie listami podpisanych elementów za pomocą manifestów ......................... 147 Ustalanie to samości za pomocą X.509............................................................. 149 Algorytmy wymagane i zalecane ...................................................................... 150 Ostrze enia i pułapki............................................................................................. 151 Zestawy narzędzi producentów ........................................................................ 152 Podsumowanie ..................................................................................................... 153 Rozwiązania w skrócie .......................................................................................... 154 Pytania i odpowiedzi ............................................................................................. 156
Spis treści 5 Rozdział 6. Szyfrowanie w XML-u ..................................................................... 157 Wprowadzenie...................................................................................................... 157 Rola szyfrowania w bezpieczeństwie przesyłanych wiadomości ................................ 158 Bezpieczeństwo wymagane przy przesyłaniu wiadomości................................... 158 Metody szyfrowania........................................................................................ 163 Jak stosować szyfrowanie w XML-u?..................................................................... 170 Transformacje XML-a przed zaszyfrowaniem ................................................... 173 Schemat procesu szyfrowania .......................................................................... 174 Praktyczne zastosowanie szyfrowania..................................................................... 175 Podpisywanie tekstu jawnego zamiast szyfrogramu............................................ 176 Szyfrogram nie pozwala na kontrolę poprawności jawnego tekstu ....................... 178 Szyfrowanie a odporność na kolizje .................................................................. 179 Podsumowanie ..................................................................................................... 179 Rozwiązania w skrócie .......................................................................................... 180 Pytania i odpowiedzi ............................................................................................. 180 Rozdział 7. Kontrola dostępu oparta na rolach.................................................. 183 Wprowadzenie...................................................................................................... 183 Mechanizm filtrowania z analizą stanu.................................................................... 183 Filtrowanie pakietów ....................................................................................... 184 Brama warstwy aplikacji.................................................................................. 185 Proces FTP .................................................................................................... 186 Technologie zapór sieciowych i XML............................................................... 187 Najpierw analiza stanu..................................................................................... 187 Ocena zmian stanu .......................................................................................... 189 Wpływ ustawień domyślnych na bezpieczeństwo............................................... 191 Kontrola dostępu oparta na rolach i implementacje wymuszania typu ........................ 192 NSA — architektura Flask ............................................................................... 194 SELinux......................................................................................................... 197 Wykorzystanie w XML-u technik kontroli dostępu opartej na rolach ......................... 202 Kiedy dokonywać oceny? ................................................................................ 205 Ochrona integralności danych .......................................................................... 206 RBAC i Java .................................................................................................. 207 Kontrola poprawności obiektów ActiveX .......................................................... 210 Narzędzia pomagające w implementacji mechanizmów RBAC ........................... 210 Podsumowanie ..................................................................................................... 215 Rozwiązania w skrócie .......................................................................................... 216 Pytania i odpowiedzi ............................................................................................. 217 Rozdział 8. .NET i bezpieczeństwo XML-a......................................................... 219 Wprowadzenie...................................................................................................... 219 Zagro enia związane z u ywaniem XML-a w .NET Framework ............................... 220 Problem poufności .......................................................................................... 220 Wewnętrzne zabezpieczenia .NET — realna alternatywa.......................................... 221 Uprawnienia ................................................................................................... 222 Uczestnik ....................................................................................................... 223 Uwierzytelnienie............................................................................................. 224 Autoryzacja .................................................................................................... 224 Zasady bezpieczeństwa.................................................................................... 224 Bezpieczeństwo typologiczne........................................................................... 224 Bezpieczeństwo dostępu kodu................................................................................ 225 Model bezpieczeństwa dostępu kodu w .NET.................................................... 225
6 Hack Proofing XML. Edycja polska Bezpieczeństwo oparte na rolach............................................................................ 240 Uczestnicy...................................................................................................... 241 Kontrola zabezpieczeń opartych na rolach ......................................................... 244 Zasady bezpieczeństwa ......................................................................................... 246 Tworzenie nowego zestawu uprawnień ............................................................. 248 Zmiany w strukturze grup kodu........................................................................ 253 Zabezpieczanie Remoting ................................................................................ 259 Kryptografia......................................................................................................... 259 Narzędzia zabezpieczeń......................................................................................... 262 Zabezpieczanie XML-a — najwa niejsze wskazówki............................................... 262 Szyfrowanie w XML-u.................................................................................... 262 Podpisy cyfrowe w XML-u.............................................................................. 267 Podsumowanie ..................................................................................................... 269 Rozwiązania w skrócie .......................................................................................... 271 Pytania i odpowiedzi ............................................................................................. 275 Rozdział 9. Zgłaszanie problemów związanych z bezpieczeństwem .................... 279 Wstęp .................................................................................................................. 279 Dlaczego nale y zgłaszać problemy związane z bezpieczeństwem? ........................... 280 Pełne ujawnienie ............................................................................................. 281 Kiedy i komu zgłosić problem? .............................................................................. 284 Komu zgłaszać problemy związane z bezpieczeństwem? .................................... 284 Jak wiele szczegółów publikować? ......................................................................... 287 Publikowanie kodu exploitu ............................................................................. 287 Problemy ....................................................................................................... 288 Podsumowanie ..................................................................................................... 290 Rozwiązania w skrócie .......................................................................................... 291 Pytania i odpowiedzi ............................................................................................. 292 Dodatek A Hack Proofing XML — rozwiązania w skrócie .................................. 295 Rozdział 1. Zen obrony przed hakerami .................................................................. 295 Rozdział 2. Klasy ataków ...................................................................................... 297 Rozdział 3. Podstawy języka XML......................................................................... 298 Rozdział 4. Typ dokumentu — kontrola poprawności .............................................. 299 Rozdział 5. Podpisy cyfrowe w XML-u .................................................................. 300 Rozdział 6. Szyfrowanie w XML-u ........................................................................ 302 Rozdział 7. Kontrola dostępu oparta na rolach ......................................................... 303 Rozdział 8. .NET i bezpieczeństwo XML-a............................................................. 303 Rozdział 9. Zgłaszanie problemów z bezpieczeństwem ............................................ 307 Skorowidz...................................................................................... 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: !ZON XGTUKQP ! 1%6;2' ECVCNQI = '.'/'06 -CVCNQI 2TQFWMV
'.'/'06 2TQFWMV 0T2TQFWMVW
0CYC2TQFWMVW
%GPC5MNGRQYC
'.'/'06 0T2TQFWMVW 2%#6# '.'/'06 0CYC2TQFWMVW 2%#6# '.'/'06 %GPC5MNGRQYC 2%#6# '06+6; EQOOGPVAQWVQHUVQEM 6GP VQYCT LGUV LW PKGFQUVGRP[ Y OCIC[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: !ZON XGTUKQP ! 1%6;2' ECVCNQI = '.'/'06 -CVCNQI 2TQFWMV
'.'/'06 2TQFWMV '/26; #66.+56 2TQFWMV 0T2TQFWMVW %#6# 4'37+4' 0CYC2TQFWMVW %#6# 4'37+4' %GPC5MNGRQYC %#6# 4'37+4' '06+6; EQOOGPVAQWVQHUVQEM 6GP VQYCT LGUV LW PKGFQUVGRP[ Y OCIC[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' ECVCNQI 5;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.+56 PCYC %#6# Dane znakowe. Mo e zawierać znaki (), znaki przedstawione jako nazwy ( NV) lub numery ( ) '06+6; '06+6; HQVQ 5;56'/ Odwołanie do obiektu, który nie będzie EHQVQLRI 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.+56 EGINC NKEQYMC ^ Lista atrybutów. Atrybuty rozdzielone przez znak ^ HCMVWTQYCPC 4'37+4' muszą być pobierane pojedynczo. + #66.+56 /NQVGM 5-7 + Wartość atrybutu musi być legalną nazwą XML. 4'37+4' Musi te być unikatowa w obrębie dokumentu. Przypomina to stosowanie atrybutu klucza w bazach danych. +4'( #66.+56 0CTGFKC Wartość atrybutu jest identyfikatorem innego /NQVGM5-7 +4'( 4'37+4' 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 +. 0/61-'0 #66.+56 MNWE 0/61-'0 Wartość atrybutu musi być legalną nazwą XML. 4'37+4' 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. 016#6+10 #66.+56 V[RQITCHKEP[ Kolejna metoda wskazania na plik lub inny zasób, 016#6+10 4'37+4' 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# Analizowane składniowo dane znakowe. Podobny do typu atrybutu %#6#. Musi zawierać jedynie znaki. #0; Oznacza, e element mo e zawierać dane dowolnego typu. %JQKEGU 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 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. +ORNKGF Atrybut opcjonalny. Zdefiniowany element mo e pozostać pusty bez skutków ubocznych. .KVGTCN Atrybut posiada wartość początkową (domyślną) podaną w deklaracji. Wartość ta mo e zostać zmieniona przez dane wejściowe lub działanie aplikacji. 4GSWKTGF 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).
102 Hack Proofing XML. Edycja polska 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: ZUFGNGOGPV PCOG -CVCNQI OUFCVC+UCVC5GV VTWG ZUFEQORNGZ6[RG ZUFEJQKEG OCZ1EEWTU WPDQWPFGF 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 ZUFUEJGOC KF -CVCNQI VCTIGV0COGURCEG JVVRVGORWTKQTI%CVCNQIZUF ZONPU JVVRVGORWTKQTI%CVCNQIZUF ZONPUZUF JVVRYYYYQTI:/.5EJGOC
Rozdział 4. ♦ Typ dokumentu — kontrola poprawności 103 ZONPUOUFCVC WTPUEJGOCUOKETQUQHVEQOZONOUFCVC CVVTKDWVG(QTOGHCWNV SWCNKHKGF GNGOGPV(QTOGHCWNV SWCNKHKGF ZUFGNGOGPV PCOG -CVCNQI OUFCVC+UCVC5GV VTWG OUFCVC'PHQTEG%QPUVTCKPVU (CNUG ZUFEQORNGZ6[RG ZUFEJQKEG OCZ1EEWTU WPDQWPFGF ZUFGNGOGPV PCOG 2TQFWMV ZUFEQORNGZ6[RG ZUFUGSWGPEG ZUFGNGOGPV PCOG 0T2TQFWMVW V[RG ZUFUVTKPI OKP1EEWTU ZUFGNGOGPV PCOG 0CYC2TQFWMVW V[RG ZUFUVTKPI OKP1EEWTU ZUFGNGOGPV PCOG %GPC5MNGRQYC V[RG ZUFUVTKPI OKP1EEWTU 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 Pochodny Podstawowe Ograniczenia typ danych typ danych aspekty 5VTKPI PQTOCNKGF5VTKPI GSWCN NGPIVJ $QQNGCP 6QMGP QTFGTGF OKP.GPIVJ GEKOCN .CPIWCIG DQWPFGF OCZ.GPIVJ (NQCV 0/61-'0 ECTFKPCNKV[ RCVVGTP QWDNG 0/61-'05 PWOGTKE GPWOGTCVKQP WTCVKQP 0COG n/d YJKVG5RCEG FCVG6KOG 0%0COG n/d OCZ+PENWUKXG 6KOG + n/d OCZ'ZENWUKXG CVG +4'( n/d OKP'ZENWUKXG I;GCT/QPVJ +4'(5 n/d OKP+PENWUKXG I/QPVJC[ '06+6; n/d VQVCNKIKVU )C[ '06+6+'5 n/d HTCEVKQPKIKVU )/QPVJ +PVGIGT n/d n/d JGZ$KPCT[ PQP2QUKVKXG+PVGIGT n/d n/d DCUG$KPCT[ PGICVKXG+PVGIGT n/d n/d #P[74+ .QPI n/d n/d 3PCOG +PV n/d n/d 016#6+10 UJQTV n/d n/d );GCT $[VG n/d n/d n/d PQP0GICVKXG+PVGIGT n/d n/d n/d WPUKIPGF.QPI n/d n/d n/d WPUKIPGF+PV n/d n/d n/d WPUKIPGF5JQTV n/d n/d n/d WPUKIPGF$[VG n/d n/d n/d RQUKVKXG+PVGIGT 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 E CH, wówczas procedury kontrolne zabez- pieczeń, zaprogramowane do dekodowania najkrótszej implementacji, nie rozpoznały w nim ukośnika (). E CH E CH Ł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[NMC VGIQ UCOGIQ FPKC Powy szy łańcuch zostanie zakodowany w ASCII. Następny przykład koduje ten sam łańcuch w Unicode: HCUVUJKR W 9[U[NMC VGIQ UCOGIQ FPKC 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 danych jest zagwarantowanie, by wszystkie dane wejściowe posiadały odpowiedni typ, konfigurację i zakres na potrzeby danej aplikacji. Dla tego procesu nie istnieją żadne „standardowe” narzędzia, ponieważ aplikacje różnią się między sobą, lecz twórcy oprogramowania muszą znać pewne zasady: 1. Schematy nie najlepiej nadają się do kontroli poprawności danych wejściowych w intensywnie używanych serwisach, ponieważ muszą być wywoływane i interpretowane dla każdego wprowadzenia danych. 2. Java jest dobrym narzędziem kontroli poprawności danych, ponieważ może pobrać schemat i na jego podstawie opracować model dla narzędzia kontrolującego poprawność. 3. Wszelka kontrola danych wejściowych jest kosztowna, ponieważ zajmuje zasoby systemowe i czas procesora. Popularna aplikacja może wywoływać program kontrolujący poprawność danych setki lub tysiące razy na minutę. Optymalizacja kodu jest tu niezbędna.
Rozdział 4. ♦ Typ dokumentu — kontrola poprawności 113 Kontrola poprawności Unicode Ochrona systemu przed atakami jawnym tekstem polega głównie na kontroli kodowa- nia stosowanej przy przekazywaniu znaków z jednego formatu do innego, zazwyczaj pomiędzy ASCII a jedną z postaci Unicode. Jako przykład sposobów, na jakie syste- my obsługują konwersję, przytoczymy funkcjonalność konwersji wejściowych łańcu- chów znakowych na Unicode udostępnianą przez Microsoft. Funkcja /WNVK$[VG6Q9KFG%JCT odwzorowuje wejściowy łańcuch znaków na łańcuch Unicode multibyte (wielobajtowy) niezale nie od tego, czy wprowadzane znaki wy- magają reprezentacji wielobajtowej czy nie. Z punktu widzenia kosztów funkcja zy- skuje pojedyncze, jednorodne odwzorowanie wszystkich znaków kosztem pamięci. Poniewa ataki tekstem jawnym zwykle wykorzystują ró nice w reprezentacji cha- rakterów kodowanych na ośmiu i szesnastu bitach, wyrównanie ustawień dla wszyst- kich łańcuchów wejściowych jest dobrym wstępem do eliminacji problemu. Struktura i argumenty /WNVK$[VG6Q9KFG%JCT są następujące: Listing 4.2. Struktura i argumenty MultiByteToWideChar +PV /WNVK$[VG6Q9KFG%JCT ] 7+06 %QFG2CIG 914 FY(NCIU .2%564 NR/WNVK$[VG5VT +PV ED/WNVK$[VG .29564 NR9KFG%JCT5VT +PV EEJ9KFG%JCT _ CodePage oznacza tutaj stronę kodową u ywaną przy konwersji. W chwili obecnej obsługiwane są dwie wartości. Przyjrzyjmy się bardziej szczegółowo tej funkcji: %2A#%2 — u ywa strony kodowej ANSI. %2A1'/%2 — odnosi się do strony kodowej OEM. FY(NCIU — ustala, czy znaki są zestawieniem, czy mają wartości proste (/$A24'%1/215') czy są zło one (/$A%1/215+6'); czy znaki powinny zostać przetłumaczone na kształty, a nie na znaki sterujące (/$A75').;2*%#45), oraz czy komunikat o błędzie powinien zostać zgłoszony przy napotkaniu niepoprawnego znaku (/$A'44A+08#.+A%*#45). NR/WNVK$[VG5VT — wskazuje na wejściowy łańcuch znaków. ED/WNVK$[VG — rozmiar łańcucha wejściowego w bajtach. Jeśli parametr ma wartość 1, wówczas długość obliczana jest automatycznie. NR9KFG%JCT5VT — bufor wyjściowy, w którym zostanie umieszczony łańcuch po translacji. EEJ9KFG%CT — rozmiar bufora wyjściowego w znakach wide character. Poza funkcją /WNVK$[VG6Q9KFG%JCT Microsoft obsługuje translację znaków poprzez sko- jarzone funkcje, na przykład 9KFG%JCT6Q/WNVK$[VG, która zasadniczo odwraca proces
114 Hack Proofing XML. Edycja polska /WNVK$[VG6Q9KFG%JCT, 6TCPUNCVG%JCTUGV+PHQ, która dokonuje translacji na podstawie określonego zestawu znaków i przydaje się, gdy napotkamy znane języki oparte na innym zestawie znaków ni łaciński, oraz +U$%5.GCF$[VG, która ustala, czy dany znak powinien zostać przetłumaczony jako znak jednobajtowy, czy te jako pierwszy bajt dwubajtowego znaku zło onego. Inne języki umo liwiają na zbli onym poziomie kontrolę nad translacją pomiędzy łańcuchami ASCII i Unicode. Widzieliśmy ju , na przykład, e Python pozwala na zakodowanie łańcucha wejściowego w Unicode poprzez dodanie prefiksu W. Python pozwala równie na bardziej precyzyjną kontrolę poprzez inne dostępne funkcje. Ko- dowanie w określonym zestawie językowym mo emy wyspecyfikować za pomocą metody GPEQFG . Weźmy poprzedni przykład: HCUVUJKR W 9[U[NMC VGIQ UCOGIQ FPKC Mo emy wymusić konwersję tego łańcucha z być mo e nieznanego formatu Unicode, właściwego dla systemu hosta, na format Unicode odpowiadający bezpośrednio tabli- cy 8-bitowych znaków ASCII w sposób następujący: HCUVUJKR 9[U[NMC VGIQ UCOGIQ FPKC HCUVUJKRGPEQFG NCVKP Podobne metody mogą posłu yć do translacji z formatu Unicode na inny. Translacja z innego formatu do Unicode wykorzystuje format WPKEQFG , który mo e przyjmować argumenty wymuszające określony kod Unicode. Na przykład: WPKEQFG 9[U[NMC VGIQ UCOGIQ FPKC WVH Ten wycinek programu koduje łańcuch w zestawie znaków dwubajtowych Unicode UTF-16. Podczas takich translacji mo liwa jest próba translacji znaku do zestawu, w którym znak ten nie jest reprezentowany. Python udostępnia trzy sposoby obsługi tego błędu wybierane przez programistę. Opcje te u ywane są w metodzie następująco: WPKEQFG 9[U[NMC VGIQ UCOGIQ FPKC WVH UVTKEV^KIPQTG^TGRNCEG Podanie UVTKEV spowoduje niepowodzenie metody, jeśli odwzorowanie będzie nie- mo liwe; KIPQTG prowadzi do usunięcia nie przekształconego znaku z łańcucha wyj- ściowego, zaś TGRNCEG zastępuje problematyczny znak przez W((( (oficjalny znak zastępczy w języku Python). W ka dym z dostępnych kodów znak W((( będzie de- finiowany indywidualnie. W przedstawionych przykładach system programistyczny udostępnia programiście narzędzia, pozwalające kontrolować sposób translacji. Niezale nie od u ywanego sys- temu najwa niejszą czynnością programisty będzie aktywny wybór i konsekwentne stosowanie metody translacji w dokumencie XML i w aplikacji. Konsekwentne stoso- wanie jednego schematu translacji minimalizuje prawdopodobieństwo niezamierzonych konsekwencji i nieumyślnych luk w zabezpieczeniach powodowanych przez niedopaso- wane reprezentacje znaków przy przekazywaniu danych z jednego komponentu opro- gramowania do innego.
Rozdział 4. ♦ Typ dokumentu — kontrola poprawności 115 Kontrola poprawności dokumentu lub komunikatu Gdy ju w rozsądnych granicach mo emy zało yć, e dane wprowadzane do systemu składają się z legalnych i nieszkodliwych znaków, wówczas zaczyna się etap procesu kontroli poprawności, który pochłania najwięcej zasobów komputera. Na tym etapie kontrolowane są dane i komunikaty w celu upewnienia się, czy wartości prawidłowo mieszczą się w określonych dla danej aplikacji granicach. Pomyślmy o aplikacji katalogu, do której odwoływaliśmy się w tym rozdziale. Na war- tości mo na przypuszczalnie nało yć kilka typów ograniczeń, aby zagwarantować, by dane były odpowiednie dla aplikacji. Na przykład, ceny będą danymi liczbowymi, a nie znakami alfabetu. Numery kart kredytowych u ytych do zapłaty będą mieścić się w zna- nym zakresie długości, podobnie jak numery telefonów i kody pocztowe. Ka da z tych wartości jest kandydatem do ścisłej kontroli poprawności. Poniewa pracujemy z XML-em, mo emy wykorzystać schemat jako narzędzie do ograniczania danych. W przypadku numerów telefonicznych łatwo jest zbudować elementy schematu zapewniające, by numer był zgodny z podstawowym systemem (przykład dotyczy numerów w USA). Fragment schematu dla aplikacji katalogu zo- stał przedstawiony poni ej. Fragment ten dopuszcza jedynie dane zgodne z formatem standardowych numerów telefonów w USA, aczkolwiek pozwala te na stosowanie maksymalnie pięciocyfrowych numerów wewnętrznych. Listing 4.3. Fragment schematu, ograniczający dane do postaci standardowych numerów telefonicznych USA ZUFUEJGOC KF %CVCNQI VCTIGV0COGURCEG JVVRVGORWTKQTI%CVCNQIZUF ZONPU JVVRVGORWTKQTI%CVCNQIZUF ZONPUZUF JVVRYYYYQTI:/.5EJGOC ZONPUOUFCVC WTPUEJGOCUOKETQUQHVEQOZONOUFCVC CVVTKDWVG(QTOGHCWNV SWCNKHKGF GNGOGPV(QTOGHCWNV SWCNKHKGF ZUFEQORNGZ6[RG PCOG VGNGRJQPG ZUFUGSWGPEG ZUFGNGOGPV PCOG CTGCEQFG ZUFUKORNG6[RG ZUFTGUVTKEVKQP DCUG ZUFUVTKPI ZUFRCVVGTP XCNWG FFF ZUFTGUVTKEVKQP ZUFUKORNG6[RG ZUFGNGOGPV ZUFGNGOGPV PCOG GZEJCPIG ZUFUKORNG6[RG ZUFTGUVTKEVKQP DCUG ZUFUVTKPI ZUFRCVVGTP XCNWG FFF ZUFTGUVTKEVKQP ZUFUKORNG6[RG ZUFGNGOGPV ZUFGNGOGPV PCOG PWODGT ZUFUKORNG6[RG ZUFTGUVTKEVKQP DCUG ZUFUVTKPI ZUFRCVVGTP XCNWG FFFF ZUFTGUVTKEVKQP
116 Hack Proofing XML. Edycja polska ZUFUKORNG6[RG ZUFGNGOGPV ZUFGNGOGPV PCOG GZVGPUKQP ZUFUKORNG6[RG ZUFTGUVTKEVKQP DCUG ZUFUVTKPI ZUFRCVVGTP XCNWG FFFFF ZUFTGUVTKEVKQP ZUFUKORNG6[RG ZUFGNGOGPV ZUFUGSWGPEG ZUFEQORNGZ6[RG Ten fragment, wykorzystujący dopasowanie do wzorca w celu wymuszenia sekwen- cji cyfr ::::::::::::::: (dopuszczającą pięciocyfrowy numer wewnętrzny), jest łatwy do napisania i zrozumienia. Proces pisania schematu nakładającego ogranicze- nia na wszystkie dane katalogowe byłby stosunkowo prosty, aczkolwiek nieco mud- ny. Wiedząc, e jesteśmy w stanie to uczynić, mo emy przemyśleć, czy naprawdę te- go chcemy. Mimo du ych mo liwości schematy XML trapi kilka problemów, z powodu których raczej nie warto u ywać ich jako jedynego mechanizmu kontroli poprawności danych dla naszej aplikacji. Po pierwsze, specyfikacja schematu XML nie została jeszcze ukończona i zatwierdzona. Jeśli zbudujemy kod aplikacji oparty na schemacie, ist- nieje realne prawdopodobieństwo, i drobne zmiany w ostatecznej specyfikacji będą mogły spowodować konieczność zmian kodu aplikacji. Drugi problem jest chyba po- wa niejszy, poniewa dotyczy bezpośrednio szybkości działania aplikacji. Schemat XML musi być wywoływany i parsowany za ka dym razem, gdy zaistnieje potrzeba kontroli poprawności. W przypadku cieszącej się popularnością aplikacji ka- talogu lub informacji telefonicznej mo e to oznaczać tysiące ądań kontroli poprawności danych na minutę. Mo liwa jest konwersja schematu na obiekt dokumentu DOM i za- pisanie w pamięci podręcznej, co zaoszczędzi czasu wymaganego do pobrania sche- matu z dysku przy ka dym wywołaniu, lecz wcią nie pozbędziemy się w ten sposób konieczności analizy składni schematu przy ka dym wywołaniu. Gdy spojrzymy na obcią enie systemu komputerowego przez powtarzające się przebiegi analizy składni schematu, stanie się oczywiste, i kontrola poprawności danych oparta jedynie na mo- delu schematu jest bardzo, bardzo kosztownym rozwiązaniem. Znacznie rozsądniejszą metodą jest zastosowanie schematu do zdefiniowania ograni- czeń danych, a następnie konwersja schematu na program w języku np. Tcl, Python lub Java. Taka metoda kontroli poprawności równie obcią a system, lecz w mniejszym stopniu ni poprzednia. Proces musi być jak najszybszy, co oznacza, e w tym miej- scu powinien być stosowany najwydajniejszy sprzęt, aby nie stał się wąskim gardłem. Tutaj te mo na u yć serwerów równoległych, rozkładając obcią enie obliczeniowe na kilka fizycznych komputerów. Czy XML jest poprawnie zbudowany? Pierwszym krokiem ochrony aplikacji przed atakami (lub nawet przed niezamierzony- mi powa nymi błędami prowadzącymi do katastrofy) jest zapewnienie, by struktura
Rozdział 4. ♦ Typ dokumentu — kontrola poprawności 117 i zawartość strumienia danych zachowywały się zgodnie z oczekiwaniami programi- sty. XML udostępnia do tego celu dwa narzędzia: DTD i schematy. Jak ju pokazali- śmy, DTD są narzędziami weryfikującymi poprawną budowę dokumentu XML, to znaczy zgodność z właściwą gramatyką i sposobem u ycia XML-a, oraz konsekwent- ne u ycie danych i struktur w całym dokumencie. Schematy mogą posłu yć do kon- troli poprawnej budowy dokumentu, lecz znacznie wychodzą poza zakres zagadnień strukturalnych, pozwalając programistom kontrolować typy i zawartość składników i samych struktur. Zarówno DTD, jak i schematy są cennymi narzędziami, zaś do jed- nego dokumentu mo emy zastosować jedne i drugie rozwiązanie. Znajomość ró nic pomiędzy nimi pomo e nam budować bezpieczniejsze dokumenty. Weryfikacja struktury za pomocą DTD DTD jest pierwszym etapem zapewniania jakości dokumentu XML. Kontrola popraw- ności poprzez DTD potwierdza, i dokument jest poprawnie zbudowany — to znaczy, e struktura dokumentu odpowiada strukturze zdefiniowanej w DTD. Kontrolę popraw- ności mo e przeprowadzić zewnętrzny analizator składni lub paser zawarty w edyto- rze lub systemach programowania, np. XML Spy czy VS.NET. DTD są starszą formą kontroli poprawności dokumentów XML obsługiwaną przez wszystkie parsery języka XML. Są analizowane składniowo i kontrolowane przed prze- tworzeniem schematów. Niestety, DTD posiadają te znacznie mniejsze mo liwości ni schematy. Nadal są jednak przydatne do wymuszania jednolitej struktury dokumen- tów. Znacząca część tej wartości bierze się ze zdolności zewnętrznych DTD do wy- muszania jednakowych struktur dokumentów XML tworzonych w ró nych miejscach organizacji lub u partnerów biznesowych. Niestety, ta wa na zaleta niesie ze sobą zna- czące zagro enia bezpieczeństwa, dodatkowo zwiększone w schemacie XML. W wielu przypadkach zewnętrzne DTD są przechowywane w serwerach poza zasię- giem kontroli lokalnych twórców dokumentów XML. W takich przypadkach wywoła- nie DTD oznacza korzystanie ze źródła, które niekoniecznie jest bezpieczne. Jeśli ta- kie nie jest, wówczas przechwycona przez hakera definicja DTD mo e lawinowo roz- przestrzenić luki w zabezpieczeniach w innych organizacjach. Dotyczy to zwłaszcza przypadków, gdy typy '06+6; i 016#6+10 są powszechnie u ywane — chocia by przy tworzeniu baz danych multimedialnych. Na przykład, zmiana typu jednostki z %#6# na '06+6; pozwoli na u ycie w niej danych znakowych bez generowania błędów. Jednak- e zarazem umo liwi to przeniesienie aplikacji wiersza poleceń przez system XML do komputera docelowego bez kontroli poprawności zabezpieczeń ze strony systemu XML. Kontrola spójności danych za pomocą schematu Pokazaliśmy, e sam schemat niekoniecznie jest najlepszym narzędziem do kontroli po- prawności jednolitości i przydatności danych wejściowych. Nie znaczy to, e schematy nie są przydatne. Nadal pozostają cennym narzędziem wymuszania zgodności doku- mentów XML ze standardami i jednolitości dokumentów w ró nych organizacjach. Jedną z zalet schematów jest fakt, i same w sobie są poprawnymi dokumentami XML. Gdy dokument zawierający schemat wywołuje analizator składni kontrolujący popraw- ność, wówczas schemat jest kontrolowany, zanim zostanie wykorzystany do kontroli
118 Hack Proofing XML. Edycja polska poprawności samego dokumentu. Poziom spójności osiągany przez taką kilkustopnio- wą kontrolę poprawności jest znaczący. Aktualny problem ze schematami polega na braku ostatecznego zatwierdzenia stan- dardów. W chwili obecnej u ywane są trzy główne odmiany schematów. Schematami XML są: XML Data Reduced (XDR) — u ywany w pierwszej wersji protokołu SOAP (Simple Object Access Protocol) i obsługiwany przez Microsoft. Regular Language description for XML (RELAX) — uproszczony schemat, zaprojektowany do łatwego przechodzenia pomiędzy DTD i schematami. Dodatkowe informacje znajdziemy pod adresem http://www.xml.gr.jp/relax. Schemat XML W3C — ten schemat mają na myśli wszyscy mówiący o „standardowym schemacie”. Na ostateczną wersję schemat XML organizacji W3C równie niecierpliwie oczekuje wielu programistów. Dodatkowe informacje znajdziemy pod adresem http://www.w3.org/TR/xmlschema-0. Wspólnym problemem DTD i schematów jest kwestia zewnętrznych odwołań. Podob- nie jak DTD, wiele schematów to zewnętrzne zasoby, z którymi łączy się du a liczba ró nych dokumentów XML. Poniewa schematy kontrolują dane i struktury o wiele bardziej rygorystycznie ni DTD, potencjalne zagro enie ze strony schematów przeję- tych przez hakerów jest większe. Z uwagi na to, na twórcach dokumentów spoczywa jeszcze większa odpowiedzialność za zapewnienie, by wszystkie u ywane schematy zewnętrzne pochodziły z bezpiecznych serwerów utrzymywanych przez zaufanych partnerów. Metody i mechanizmy kontroli poprawności online Gdy nadchodzi pora kontroli poprawności dokumentów XML, mo emy postąpić na jeden z wielu sposobów. Wszystkie opcje łączy jeden wymóg: kontrolujący popraw- ność parser (analizator składni) musi odczytać wszystkie wiersze dokumentu i zwrócić raport o wszelkich naruszeniach poprawności lub o dobrze skonstruowanej strukturze. Wszystkie dostępne narzędzia do kontroli poprawności XML-a spełniają to najprost- sze kryterium. Oprócz niego istnieje wiele opcji skorzystania z parsera sprawdzające- go poprawność. Mo e to być autonomiczny produkt lub składnik pakietu do edycji lub programowania. Praktycznie wszystkie narzędzia kontrolujące poprawność są w sta- nie opierać kontrolę na DTD, co stanowi jedną z zalet tego starszego mechanizmu. Poni sze podpunkty przedstawią kilka najłatwiej dostępnych narzędzi online pozwa- lających na kontrolę poprawności w oparciu o DTD i schematy. XML Spy 4.3 Program XML Spy 4.3, stworzony przez firmę Altova, jest środowiskiem programo- wania dla XML-a i obejmuje kontrolę poprawności na podstawie DTD i schematów, dostęp do baz danych ODBC (Open Database Connectivity) oraz całkowicie zinte- growane środowisko programowania. Darmową, 30-dniowa wersję próbną mo emy znaleźć pod adresem http://www.xmlspy.com.
Rozdział 4. ♦ Typ dokumentu — kontrola poprawności 119 W3C: Validator for XML Schema Udostępniony przez W3C program kontroli poprawności dokumentów XML na pod- stawie schematu mo emy znaleźć pod adresem http://www.w3.org/2001/03/webdata/ xsv. Serwis ten zapewnia mo liwość korzystania ze schematów dostępnych poprzez WWW, jak równie znajdujących się za zaporą firewall przedsiębiorstwa (patrz: ry- sunek 4.2). Rysunek 4.2. Ekran powitalny programu W3C Validator for XML Schema Programiści mogą przesyłać do niego dokumenty XML na dwa sposoby: podając ogól- nodostępny adres URI lub ładując plik z sieci lokalnej. Poprawnie zbudowany doku- ment zwróci jedynie prosty ekran z komunikatem, jak widać na rysunku 4.3. Rysunek 4.3. Notatka zwrócona dla poprawnie zbudowanego dokumentu Gdy program sprawdzający poprawność przeanalizuje dokument z błędami, otrzyma- my ekran z komunikatami o błędach, podający typ błędu i jego poło enie w pliku, jak pokazano na rysunku 4.4.
120 Hack Proofing XML. Edycja polska Rysunek 4.4. Dokument zawierający błędy powoduje wygenerowanie komunikatu o błędzie Powinniśmy zwrócić uwagę na jedną wa ną właściwość programu kontrolującego poprawność — podobnie jak wiele staroświeckich narzędzi tego typu, zatrzymuje się po natrafieniu na pierwszy błąd. Jeśli nasz dokument jest długi i zawiera ich sporo, wówczas zapewnienie poprawnej budowy dokumentu będzie wymagało wielokrotne- go jego uruchomienia. Formularz kontroli poprawności XML-a z Brown University Programiści z Brown University stworzyli formularz pozwalający kontrolować popraw- ność XML-a. Formularz ten jest dostępny online pod adresem http://www.stg.brown. edu/service/xmlvalid/. Krótkie dokumenty mo emy skopiować i wkleić bezpośrednio na stronie; większe dokumenty są wywoływane poprzez adres. Gdy po raz pierwszy otworzymy formularz kontroli poprawności z Brown University, zobaczymy prosty ekran interfejsu jak przedstawiono na rysunku 4.5. Od razu widać, e grupa programistów z Brown podeszła do kontroli poprawności zupełnie inaczej ni w przypadku innych takich serwisów online, poniewa dokument zaakceptowany przez programy W3C i RUWF zwraca w przypadku Brown University wyniki jak te z rysunku 4.6. Jak widzimy, dokument został surowo oceniony. Większość błędów wyszczególnionych przez ten formularz dla innych narzędzi było- by co najwy ej ostrze eniami. Jeśli potrzebujemy absolutnej pewności, e dokument będzie działać, wówczas narzędzie z Brown University pozwoli nam tę pewność uzy- skać, lecz inne narzędzia powiedzą, czy dokument będzie działać czy nie przy wyko- rzystaniu znacznie mniejszej liczby wierszy komentarza. Jednym z problemów, jakie napotyka się w przypadku takiego podejścia, jakie zastosowano w Brown University, jest kontrola plików zawierających znane problemy. Plik, który spowodował wygene- rowanie błędów w narzędziach W3C i RUWF, w narzędziu z Brown zwrócił ekran przestawiony na rysunku 4.7. Proszę zwrócić uwagę, e wyniki dla pliku poprawnego i niepoprawnego są do siebie podobne. Raporty generowane przez dwa wprowadzone pliki niewiele się od siebie ró nią. W wy- nikach dla „złego” pliku błędy znalezione przez inne narzędzia kontroli poprawności
Rozdział 4. ♦ Typ dokumentu — kontrola poprawności 121 Rysunek 4.5. Formularz kontroli poprawności online z Brown University Rysunek 4.6. Plik zaakceptowany przez inne programy kontrolujące poprawność został mocno skrytykowany w Brown
Hack Proofing XML. Edycja polska
Hack Proofing XML. Edycja polska

Recommandé

ABC ochrony komputera przed atakami hakera
ABC ochrony komputera przed atakami hakeraABC ochrony komputera przed atakami hakera
ABC ochrony komputera przed atakami hakeraWydawnictwo Helion
 
Internet. Ilustrowany przewodnik
Internet. Ilustrowany przewodnikInternet. Ilustrowany przewodnik
Internet. Ilustrowany przewodnikWydawnictwo Helion
 
Windows XP PL. Ilustrowany przewodnik
Windows XP PL. Ilustrowany przewodnikWindows XP PL. Ilustrowany przewodnik
Windows XP PL. Ilustrowany przewodnikWydawnictwo Helion
 
Flash CS3 Professional PL. Techniki zaawansowane. Klatka po klatce
Flash CS3 Professional PL. Techniki zaawansowane. Klatka po klatceFlash CS3 Professional PL. Techniki zaawansowane. Klatka po klatce
Flash CS3 Professional PL. Techniki zaawansowane. Klatka po klatceWydawnictwo Helion
 
Bezpieczeństwo aplikacji tworzonych w technologii Ajax
Bezpieczeństwo aplikacji tworzonych w technologii AjaxBezpieczeństwo aplikacji tworzonych w technologii Ajax
Bezpieczeństwo aplikacji tworzonych w technologii AjaxWydawnictwo Helion
 
Cracking bez tajemnic
Cracking bez tajemnicCracking bez tajemnic
Cracking bez tajemnicWydawnictwo Helion
 
Hack Proofing Your Web Applications. Edycja polska
Hack Proofing Your Web Applications. Edycja polskaHack Proofing Your Web Applications. Edycja polska
Hack Proofing Your Web Applications. Edycja polskaWydawnictwo Helion
 
Biblia Q3
Biblia Q3Biblia Q3
Biblia Q3ontheteam
 

Recommandé

ABC ochrony komputera przed atakami hakera
ABC ochrony komputera przed atakami hakeraABC ochrony komputera przed atakami hakera
ABC ochrony komputera przed atakami hakeraWydawnictwo Helion
 
Internet. Ilustrowany przewodnik
Internet. Ilustrowany przewodnikInternet. Ilustrowany przewodnik
Internet. Ilustrowany przewodnikWydawnictwo Helion
 
Windows XP PL. Ilustrowany przewodnik
Windows XP PL. Ilustrowany przewodnikWindows XP PL. Ilustrowany przewodnik
Windows XP PL. Ilustrowany przewodnikWydawnictwo Helion
 
Flash CS3 Professional PL. Techniki zaawansowane. Klatka po klatce
Flash CS3 Professional PL. Techniki zaawansowane. Klatka po klatceFlash CS3 Professional PL. Techniki zaawansowane. Klatka po klatce
Flash CS3 Professional PL. Techniki zaawansowane. Klatka po klatceWydawnictwo Helion
 
Bezpieczeństwo aplikacji tworzonych w technologii Ajax
Bezpieczeństwo aplikacji tworzonych w technologii AjaxBezpieczeństwo aplikacji tworzonych w technologii Ajax
Bezpieczeństwo aplikacji tworzonych w technologii AjaxWydawnictwo Helion
 
Cracking bez tajemnic
Cracking bez tajemnicCracking bez tajemnic
Cracking bez tajemnicWydawnictwo Helion
 
Hack Proofing Your Web Applications. Edycja polska
Hack Proofing Your Web Applications. Edycja polskaHack Proofing Your Web Applications. Edycja polska
Hack Proofing Your Web Applications. Edycja polskaWydawnictwo Helion
 
Biblia Q3
Biblia Q3Biblia Q3
Biblia Q3ontheteam
 
Java. Techniki zaawansowane. Wydanie VIII
Java. Techniki zaawansowane. Wydanie VIIIJava. Techniki zaawansowane. Wydanie VIII
Java. Techniki zaawansowane. Wydanie VIIIWydawnictwo Helion
 
Windows PowerShell. Podstawy
Windows PowerShell. PodstawyWindows PowerShell. Podstawy
Windows PowerShell. PodstawyWydawnictwo Helion
 
ActionScript. Przewodnik encyklopedyczny
ActionScript. Przewodnik encyklopedycznyActionScript. Przewodnik encyklopedyczny
ActionScript. Przewodnik encyklopedycznyWydawnictwo Helion
 
Co potrafi Twój iPhone? Podręcznik użytkownika. Wydanie II
Co potrafi Twój iPhone? Podręcznik użytkownika. Wydanie IICo potrafi Twój iPhone? Podręcznik użytkownika. Wydanie II
Co potrafi Twój iPhone? Podręcznik użytkownika. Wydanie IIWydawnictwo Helion
 
SQL. Szybki start
SQL. Szybki startSQL. Szybki start
SQL. Szybki startWydawnictwo Helion
 
Po prostu Java 2
Po prostu Java 2Po prostu Java 2
Po prostu Java 2Wydawnictwo Helion
 
Hardware Hacking. Edycja polska
Hardware Hacking. Edycja polskaHardware Hacking. Edycja polska
Hardware Hacking. Edycja polskaWydawnictwo Helion
 
Master Thesis - Comparative analysis of programming Environments based on Rub...
Master Thesis - Comparative analysis of programming Environments based on Rub...Master Thesis - Comparative analysis of programming Environments based on Rub...
Master Thesis - Comparative analysis of programming Environments based on Rub...Adam Skołuda
 
Uczta programistów
Uczta programistówUczta programistów
Uczta programistówWydawnictwo Helion
 
Microsoft Visual C++ 2008. Tworzenie aplikacji dla Windows
Microsoft Visual C++ 2008. Tworzenie aplikacji dla WindowsMicrosoft Visual C++ 2008. Tworzenie aplikacji dla Windows
Microsoft Visual C++ 2008. Tworzenie aplikacji dla WindowsWydawnictwo Helion
 
Flash MX. Ćwiczenia zaawansowane
Flash MX. Ćwiczenia zaawansowaneFlash MX. Ćwiczenia zaawansowane
Flash MX. Ćwiczenia zaawansowaneWydawnictwo Helion
 
100 sposobów na Windows XP PL
100 sposobów na Windows XP PL100 sposobów na Windows XP PL
100 sposobów na Windows XP PLWydawnictwo Helion
 
Flash MX 2004. Tworzenie gier
Flash MX 2004. Tworzenie gierFlash MX 2004. Tworzenie gier
Flash MX 2004. Tworzenie gierWydawnictwo Helion
 
Po prostu Mac OS X 10.5 Leopard PL
Po prostu Mac OS X 10.5 Leopard PLPo prostu Mac OS X 10.5 Leopard PL
Po prostu Mac OS X 10.5 Leopard PLWydawnictwo Helion
 
Flash MX. ActionScript. Leksykon kieszonkowy
Flash MX. ActionScript. Leksykon kieszonkowyFlash MX. ActionScript. Leksykon kieszonkowy
Flash MX. ActionScript. Leksykon kieszonkowyWydawnictwo Helion
 
Bezpieczeństwo w sieciach Windows
Bezpieczeństwo w sieciach WindowsBezpieczeństwo w sieciach Windows
Bezpieczeństwo w sieciach WindowsWydawnictwo Helion
 
100 sposobów na serwery Windows
100 sposobów na serwery Windows100 sposobów na serwery Windows
100 sposobów na serwery WindowsWydawnictwo Helion
 
Witryny nie do ukrycia. Jak zbudować stronę, którą znajdzie każda wyszukiwarka
Witryny nie do ukrycia. Jak zbudować stronę, którą znajdzie każda wyszukiwarkaWitryny nie do ukrycia. Jak zbudować stronę, którą znajdzie każda wyszukiwarka
Witryny nie do ukrycia. Jak zbudować stronę, którą znajdzie każda wyszukiwarkaWydawnictwo Helion
 
Jak działa Linux
Jak działa LinuxJak działa Linux
Jak działa LinuxWydawnictwo Helion
 
Access w biurze i nie tylko
Access w biurze i nie tylkoAccess w biurze i nie tylko
Access w biurze i nie tylkoWydawnictwo Helion
 
Oracle9i. Przewodnik dla początkujących
Oracle9i. Przewodnik dla początkującychOracle9i. Przewodnik dla początkujących
Oracle9i. Przewodnik dla początkującychWydawnictwo Helion
 
MySQL. Szybki start
MySQL. Szybki startMySQL. Szybki start
MySQL. Szybki startWydawnictwo Helion
 

Contenu connexe

Tendances

Java. Techniki zaawansowane. Wydanie VIII
Java. Techniki zaawansowane. Wydanie VIIIJava. Techniki zaawansowane. Wydanie VIII
Java. Techniki zaawansowane. Wydanie VIIIWydawnictwo Helion
 
ActionScript. Przewodnik encyklopedyczny
ActionScript. Przewodnik encyklopedycznyActionScript. Przewodnik encyklopedyczny
ActionScript. Przewodnik encyklopedycznyWydawnictwo Helion
 
Co potrafi Twój iPhone? Podręcznik użytkownika. Wydanie II
Co potrafi Twój iPhone? Podręcznik użytkownika. Wydanie IICo potrafi Twój iPhone? Podręcznik użytkownika. Wydanie II
Co potrafi Twój iPhone? Podręcznik użytkownika. Wydanie IIWydawnictwo Helion
 
Hardware Hacking. Edycja polska
Hardware Hacking. Edycja polskaHardware Hacking. Edycja polska
Hardware Hacking. Edycja polskaWydawnictwo Helion
 
Master Thesis - Comparative analysis of programming Environments based on Rub...
Master Thesis - Comparative analysis of programming Environments based on Rub...Master Thesis - Comparative analysis of programming Environments based on Rub...
Master Thesis - Comparative analysis of programming Environments based on Rub...Adam Skołuda
 
Microsoft Visual C++ 2008. Tworzenie aplikacji dla Windows
Microsoft Visual C++ 2008. Tworzenie aplikacji dla WindowsMicrosoft Visual C++ 2008. Tworzenie aplikacji dla Windows
Microsoft Visual C++ 2008. Tworzenie aplikacji dla WindowsWydawnictwo Helion
 
Flash MX. Ćwiczenia zaawansowane
Flash MX. Ćwiczenia zaawansowaneFlash MX. Ćwiczenia zaawansowane
Flash MX. Ćwiczenia zaawansowaneWydawnictwo Helion
 
100 sposobów na Windows XP PL
100 sposobów na Windows XP PL100 sposobów na Windows XP PL
100 sposobów na Windows XP PLWydawnictwo Helion
 
Po prostu Mac OS X 10.5 Leopard PL
Po prostu Mac OS X 10.5 Leopard PLPo prostu Mac OS X 10.5 Leopard PL
Po prostu Mac OS X 10.5 Leopard PLWydawnictwo Helion
 
Flash MX. ActionScript. Leksykon kieszonkowy
Flash MX. ActionScript. Leksykon kieszonkowyFlash MX. ActionScript. Leksykon kieszonkowy
Flash MX. ActionScript. Leksykon kieszonkowyWydawnictwo Helion
 
Bezpieczeństwo w sieciach Windows
Bezpieczeństwo w sieciach WindowsBezpieczeństwo w sieciach Windows
Bezpieczeństwo w sieciach WindowsWydawnictwo Helion
 
100 sposobów na serwery Windows
100 sposobów na serwery Windows100 sposobów na serwery Windows
100 sposobów na serwery WindowsWydawnictwo Helion
 
Witryny nie do ukrycia. Jak zbudować stronę, którą znajdzie każda wyszukiwarka
Witryny nie do ukrycia. Jak zbudować stronę, którą znajdzie każda wyszukiwarkaWitryny nie do ukrycia. Jak zbudować stronę, którą znajdzie każda wyszukiwarka
Witryny nie do ukrycia. Jak zbudować stronę, którą znajdzie każda wyszukiwarkaWydawnictwo Helion
 

Tendances (20)

Java. Techniki zaawansowane. Wydanie VIII
Java. Techniki zaawansowane. Wydanie VIIIJava. Techniki zaawansowane. Wydanie VIII
Java. Techniki zaawansowane. Wydanie VIII
 
Windows PowerShell. Podstawy
Windows PowerShell. PodstawyWindows PowerShell. Podstawy
Windows PowerShell. Podstawy
 
ActionScript. Przewodnik encyklopedyczny
ActionScript. Przewodnik encyklopedycznyActionScript. Przewodnik encyklopedyczny
ActionScript. Przewodnik encyklopedyczny
 
Co potrafi Twój iPhone? Podręcznik użytkownika. Wydanie II
Co potrafi Twój iPhone? Podręcznik użytkownika. Wydanie IICo potrafi Twój iPhone? Podręcznik użytkownika. Wydanie II
Co potrafi Twój iPhone? Podręcznik użytkownika. Wydanie II
 
SQL. Szybki start
SQL. Szybki startSQL. Szybki start
SQL. Szybki start
 
Po prostu Java 2
Po prostu Java 2Po prostu Java 2
Po prostu Java 2
 
Hardware Hacking. Edycja polska
Hardware Hacking. Edycja polskaHardware Hacking. Edycja polska
Hardware Hacking. Edycja polska
 
Master Thesis - Comparative analysis of programming Environments based on Rub...
Master Thesis - Comparative analysis of programming Environments based on Rub...Master Thesis - Comparative analysis of programming Environments based on Rub...
Master Thesis - Comparative analysis of programming Environments based on Rub...
 
Uczta programistów
Uczta programistówUczta programistów
Uczta programistów
 
Microsoft Visual C++ 2008. Tworzenie aplikacji dla Windows
Microsoft Visual C++ 2008. Tworzenie aplikacji dla WindowsMicrosoft Visual C++ 2008. Tworzenie aplikacji dla Windows
Microsoft Visual C++ 2008. Tworzenie aplikacji dla Windows
 
Flash MX. Ćwiczenia zaawansowane
Flash MX. Ćwiczenia zaawansowaneFlash MX. Ćwiczenia zaawansowane
Flash MX. Ćwiczenia zaawansowane
 
100 sposobów na Windows XP PL
100 sposobów na Windows XP PL100 sposobów na Windows XP PL
100 sposobów na Windows XP PL
 
Flash MX 2004. Tworzenie gier
Flash MX 2004. Tworzenie gierFlash MX 2004. Tworzenie gier
Flash MX 2004. Tworzenie gier
 
Po prostu Mac OS X 10.5 Leopard PL
Po prostu Mac OS X 10.5 Leopard PLPo prostu Mac OS X 10.5 Leopard PL
Po prostu Mac OS X 10.5 Leopard PL
 
Flash MX. ActionScript. Leksykon kieszonkowy
Flash MX. ActionScript. Leksykon kieszonkowyFlash MX. ActionScript. Leksykon kieszonkowy
Flash MX. ActionScript. Leksykon kieszonkowy
 
Bezpieczeństwo w sieciach Windows
Bezpieczeństwo w sieciach WindowsBezpieczeństwo w sieciach Windows
Bezpieczeństwo w sieciach Windows
 
100 sposobów na serwery Windows
100 sposobów na serwery Windows100 sposobów na serwery Windows
100 sposobów na serwery Windows
 
Witryny nie do ukrycia. Jak zbudować stronę, którą znajdzie każda wyszukiwarka
Witryny nie do ukrycia. Jak zbudować stronę, którą znajdzie każda wyszukiwarkaWitryny nie do ukrycia. Jak zbudować stronę, którą znajdzie każda wyszukiwarka
Witryny nie do ukrycia. Jak zbudować stronę, którą znajdzie każda wyszukiwarka
 
Jak działa Linux
Jak działa LinuxJak działa Linux
Jak działa Linux
 
Access w biurze i nie tylko
Access w biurze i nie tylkoAccess w biurze i nie tylko
Access w biurze i nie tylko
 

En vedette

Oracle9i. Przewodnik dla początkujących
Oracle9i. Przewodnik dla początkującychOracle9i. Przewodnik dla początkujących
Oracle9i. Przewodnik dla początkującychWydawnictwo Helion
 
Rozbudowa i naprawa komputerów PC. Wydanie drugie
Rozbudowa i naprawa komputerów PC. Wydanie drugieRozbudowa i naprawa komputerów PC. Wydanie drugie
Rozbudowa i naprawa komputerów PC. Wydanie drugieWydawnictwo Helion
 
Hack Proofing Linux. Edycja polska
Hack Proofing Linux. Edycja polskaHack Proofing Linux. Edycja polska
Hack Proofing Linux. Edycja polskaWydawnictwo Helion
 
Java. Usługi WWW. Vademecum profesjonalisty
Java. Usługi WWW. Vademecum profesjonalistyJava. Usługi WWW. Vademecum profesjonalisty
Java. Usługi WWW. Vademecum profesjonalistyWydawnictwo Helion
 
Tworzenie stron WWW w praktyce
Tworzenie stron WWW w praktyceTworzenie stron WWW w praktyce
Tworzenie stron WWW w praktyceWydawnictwo Helion
 
CorelDRAW 11. Vademecum profesjonalisty. Tom 1
CorelDRAW 11. Vademecum profesjonalisty. Tom 1CorelDRAW 11. Vademecum profesjonalisty. Tom 1
CorelDRAW 11. Vademecum profesjonalisty. Tom 1Wydawnictwo Helion
 
Adobe Illustrator 10. Ćwiczenia
Adobe Illustrator 10. ĆwiczeniaAdobe Illustrator 10. Ćwiczenia
Adobe Illustrator 10. ĆwiczeniaWydawnictwo Helion
 

En vedette (12)

Oracle9i. Przewodnik dla początkujących
Oracle9i. Przewodnik dla początkującychOracle9i. Przewodnik dla początkujących
Oracle9i. Przewodnik dla początkujących
 
MySQL. Szybki start
MySQL. Szybki startMySQL. Szybki start
MySQL. Szybki start
 
ABC grafiki komputerowej
ABC grafiki komputerowejABC grafiki komputerowej
ABC grafiki komputerowej
 
Photoshop 7/7 CE. Biblia
Photoshop 7/7 CE. BibliaPhotoshop 7/7 CE. Biblia
Photoshop 7/7 CE. Biblia
 
Rozbudowa i naprawa komputerów PC. Wydanie drugie
Rozbudowa i naprawa komputerów PC. Wydanie drugieRozbudowa i naprawa komputerów PC. Wydanie drugie
Rozbudowa i naprawa komputerów PC. Wydanie drugie
 
Hack Proofing Linux. Edycja polska
Hack Proofing Linux. Edycja polskaHack Proofing Linux. Edycja polska
Hack Proofing Linux. Edycja polska
 
Java. Usługi WWW. Vademecum profesjonalisty
Java. Usługi WWW. Vademecum profesjonalistyJava. Usługi WWW. Vademecum profesjonalisty
Java. Usługi WWW. Vademecum profesjonalisty
 
Tworzenie stron WWW w praktyce
Tworzenie stron WWW w praktyceTworzenie stron WWW w praktyce
Tworzenie stron WWW w praktyce
 
CorelDRAW 11. Vademecum profesjonalisty. Tom 1
CorelDRAW 11. Vademecum profesjonalisty. Tom 1CorelDRAW 11. Vademecum profesjonalisty. Tom 1
CorelDRAW 11. Vademecum profesjonalisty. Tom 1
 
Po prostu InDesign 2 CE
Po prostu InDesign 2 CEPo prostu InDesign 2 CE
Po prostu InDesign 2 CE
 
Bluetooth
BluetoothBluetooth
Bluetooth
 
Adobe Illustrator 10. Ćwiczenia
Adobe Illustrator 10. ĆwiczeniaAdobe Illustrator 10. Ćwiczenia
Adobe Illustrator 10. Ćwiczenia
 

Similaire à Hack Proofing XML. Edycja polska

PHP. Praktyczne skrypty, które oszczędzą Twój czas
PHP. Praktyczne skrypty, które oszczędzą Twój czasPHP. Praktyczne skrypty, które oszczędzą Twój czas
PHP. Praktyczne skrypty, które oszczędzą Twój czasWydawnictwo Helion
 
Asembler. Sztuka programowania
Asembler. Sztuka programowaniaAsembler. Sztuka programowania
Asembler. Sztuka programowaniaWydawnictwo Helion
 
Hack I.T. Testy bezpieczeństwa danych
Hack I.T. Testy bezpieczeństwa danychHack I.T. Testy bezpieczeństwa danych
Hack I.T. Testy bezpieczeństwa danychWydawnictwo Helion
 
Access 2002/XP PL dla każdego
Access 2002/XP PL dla każdegoAccess 2002/XP PL dla każdego
Access 2002/XP PL dla każdegoWydawnictwo Helion
 
Anti-Hacker Tool Kit. Edycja polska
Anti-Hacker Tool Kit. Edycja polskaAnti-Hacker Tool Kit. Edycja polska
Anti-Hacker Tool Kit. Edycja polskaWydawnictwo Helion
 
Ajax. Wzorce i najlepsze rozwiązania
Ajax. Wzorce i najlepsze rozwiązaniaAjax. Wzorce i najlepsze rozwiązania
Ajax. Wzorce i najlepsze rozwiązaniaWydawnictwo Helion
 
The Shellcoders Handbook. Edycja polska
The Shellcoders Handbook. Edycja polskaThe Shellcoders Handbook. Edycja polska
The Shellcoders Handbook. Edycja polskaWydawnictwo Helion
 
.Net. Najpilniej strzeżone tajemnice
.Net. Najpilniej strzeżone tajemnice.Net. Najpilniej strzeżone tajemnice
.Net. Najpilniej strzeżone tajemniceWydawnictwo Helion
 
100 sposobów na tworzenie robotów sieciowych
100 sposobów na tworzenie robotów sieciowych100 sposobów na tworzenie robotów sieciowych
100 sposobów na tworzenie robotów sieciowychWydawnictwo Helion
 
Czytanie kodu. Punkt widzenia twórców oprogramowania open source
Czytanie kodu. Punkt widzenia twórców oprogramowania open sourceCzytanie kodu. Punkt widzenia twórców oprogramowania open source
Czytanie kodu. Punkt widzenia twórców oprogramowania open sourceWydawnictwo Helion
 
Znajdź błąd. Sztuka analizowania kodu
Znajdź błąd. Sztuka analizowania koduZnajdź błąd. Sztuka analizowania kodu
Znajdź błąd. Sztuka analizowania koduWydawnictwo Helion
 
Po prostu PHP. Techniki zaawansowane
Po prostu PHP. Techniki zaawansowanePo prostu PHP. Techniki zaawansowane
Po prostu PHP. Techniki zaawansowaneWydawnictwo Helion
 
Ajax, JavaScript i PHP. Intensywny trening
Ajax, JavaScript i PHP. Intensywny treningAjax, JavaScript i PHP. Intensywny trening
Ajax, JavaScript i PHP. Intensywny treningWydawnictwo Helion
 
Po prostu JavaScript i Ajax. Wydanie VI
Po prostu JavaScript i Ajax. Wydanie VIPo prostu JavaScript i Ajax. Wydanie VI
Po prostu JavaScript i Ajax. Wydanie VIWydawnictwo Helion
 

Similaire à Hack Proofing XML. Edycja polska (20)

Cisza w sieci
Cisza w sieciCisza w sieci
Cisza w sieci
 
PHP. Praktyczne skrypty, które oszczędzą Twój czas
PHP. Praktyczne skrypty, które oszczędzą Twój czasPHP. Praktyczne skrypty, które oszczędzą Twój czas
PHP. Praktyczne skrypty, które oszczędzą Twój czas
 
Asembler. Sztuka programowania
Asembler. Sztuka programowaniaAsembler. Sztuka programowania
Asembler. Sztuka programowania
 
Hack I.T. Testy bezpieczeństwa danych
Hack I.T. Testy bezpieczeństwa danychHack I.T. Testy bezpieczeństwa danych
Hack I.T. Testy bezpieczeństwa danych
 
Access 2002/XP PL dla każdego
Access 2002/XP PL dla każdegoAccess 2002/XP PL dla każdego
Access 2002/XP PL dla każdego
 
Anti-Hacker Tool Kit. Edycja polska
Anti-Hacker Tool Kit. Edycja polskaAnti-Hacker Tool Kit. Edycja polska
Anti-Hacker Tool Kit. Edycja polska
 
Ajax. Wzorce i najlepsze rozwiązania
Ajax. Wzorce i najlepsze rozwiązaniaAjax. Wzorce i najlepsze rozwiązania
Ajax. Wzorce i najlepsze rozwiązania
 
XSLT dla każdego
XSLT dla każdegoXSLT dla każdego
XSLT dla każdego
 
The Shellcoders Handbook. Edycja polska
The Shellcoders Handbook. Edycja polskaThe Shellcoders Handbook. Edycja polska
The Shellcoders Handbook. Edycja polska
 
.Net. Najpilniej strzeżone tajemnice
.Net. Najpilniej strzeżone tajemnice.Net. Najpilniej strzeżone tajemnice
.Net. Najpilniej strzeżone tajemnice
 
100 sposobów na tworzenie robotów sieciowych
100 sposobów na tworzenie robotów sieciowych100 sposobów na tworzenie robotów sieciowych
100 sposobów na tworzenie robotów sieciowych
 
Po prostu HTML 4. Wydanie III
Po prostu HTML 4. Wydanie IIIPo prostu HTML 4. Wydanie III
Po prostu HTML 4. Wydanie III
 
Czytanie kodu. Punkt widzenia twórców oprogramowania open source
Czytanie kodu. Punkt widzenia twórców oprogramowania open sourceCzytanie kodu. Punkt widzenia twórców oprogramowania open source
Czytanie kodu. Punkt widzenia twórców oprogramowania open source
 
JSP i XML
JSP i XMLJSP i XML
JSP i XML
 
Linux. Komendy i polecenia
Linux. Komendy i poleceniaLinux. Komendy i polecenia
Linux. Komendy i polecenia
 
Znajdź błąd. Sztuka analizowania kodu
Znajdź błąd. Sztuka analizowania koduZnajdź błąd. Sztuka analizowania kodu
Znajdź błąd. Sztuka analizowania kodu
 
Po prostu PHP. Techniki zaawansowane
Po prostu PHP. Techniki zaawansowanePo prostu PHP. Techniki zaawansowane
Po prostu PHP. Techniki zaawansowane
 
Ajax, JavaScript i PHP. Intensywny trening
Ajax, JavaScript i PHP. Intensywny treningAjax, JavaScript i PHP. Intensywny trening
Ajax, JavaScript i PHP. Intensywny trening
 
ABC sieci komputerowych
ABC sieci komputerowychABC sieci komputerowych
ABC sieci komputerowych
 
Po prostu JavaScript i Ajax. Wydanie VI
Po prostu JavaScript i Ajax. Wydanie VIPo prostu JavaScript i Ajax. Wydanie VI
Po prostu JavaScript i Ajax. Wydanie VI
 

Plus de Wydawnictwo Helion

Tworzenie filmów w Windows XP. Projekty
Tworzenie filmów w Windows XP. ProjektyTworzenie filmów w Windows XP. Projekty
Tworzenie filmów w Windows XP. ProjektyWydawnictwo Helion
 
Blog, więcej niż internetowy pamiętnik
Blog, więcej niż internetowy pamiętnikBlog, więcej niż internetowy pamiętnik
Blog, więcej niż internetowy pamiętnikWydawnictwo Helion
 
Pozycjonowanie i optymalizacja stron WWW. Ćwiczenia praktyczne
Pozycjonowanie i optymalizacja stron WWW. Ćwiczenia praktycznePozycjonowanie i optymalizacja stron WWW. Ćwiczenia praktyczne
Pozycjonowanie i optymalizacja stron WWW. Ćwiczenia praktyczneWydawnictwo Helion
 
E-wizerunek. Internet jako narzędzie kreowania image'u w biznesie
E-wizerunek. Internet jako narzędzie kreowania image'u w biznesieE-wizerunek. Internet jako narzędzie kreowania image'u w biznesie
E-wizerunek. Internet jako narzędzie kreowania image'u w biznesieWydawnictwo Helion
 
Makrofotografia. Magia szczegółu
Makrofotografia. Magia szczegółuMakrofotografia. Magia szczegółu
Makrofotografia. Magia szczegółuWydawnictwo Helion
 
Java. Efektywne programowanie. Wydanie II
Java. Efektywne programowanie. Wydanie IIJava. Efektywne programowanie. Wydanie II
Java. Efektywne programowanie. Wydanie IIWydawnictwo Helion
 
PowerPoint 2007 PL. Seria praktyk
PowerPoint 2007 PL. Seria praktykPowerPoint 2007 PL. Seria praktyk
PowerPoint 2007 PL. Seria praktykWydawnictwo Helion
 
Serwisy społecznościowe. Budowa, administracja i moderacja
Serwisy społecznościowe. Budowa, administracja i moderacjaSerwisy społecznościowe. Budowa, administracja i moderacja
Serwisy społecznościowe. Budowa, administracja i moderacjaWydawnictwo Helion
 
Serwer SQL 2008. Administracja i programowanie
Serwer SQL 2008. Administracja i programowanieSerwer SQL 2008. Administracja i programowanie
Serwer SQL 2008. Administracja i programowanieWydawnictwo Helion
 
USB. Praktyczne programowanie z Windows API w C++
USB. Praktyczne programowanie z Windows API w C++USB. Praktyczne programowanie z Windows API w C++
USB. Praktyczne programowanie z Windows API w C++Wydawnictwo Helion
 
Microsoft Visual Studio 2008. Księga eksperta
Microsoft Visual Studio 2008. Księga ekspertaMicrosoft Visual Studio 2008. Księga eksperta
Microsoft Visual Studio 2008. Księga ekspertaWydawnictwo Helion
 
Rewizor GT. Prowadzenie ewidencji księgowej
Rewizor GT. Prowadzenie ewidencji księgowejRewizor GT. Prowadzenie ewidencji księgowej
Rewizor GT. Prowadzenie ewidencji księgowejWydawnictwo Helion
 
Fotografia cyfrowa. Poradnik bez kantów
Fotografia cyfrowa. Poradnik bez kantówFotografia cyfrowa. Poradnik bez kantów
Fotografia cyfrowa. Poradnik bez kantówWydawnictwo Helion
 

Plus de Wydawnictwo Helion (20)

Tworzenie filmów w Windows XP. Projekty
Tworzenie filmów w Windows XP. ProjektyTworzenie filmów w Windows XP. Projekty
Tworzenie filmów w Windows XP. Projekty
 
Blog, więcej niż internetowy pamiętnik
Blog, więcej niż internetowy pamiętnikBlog, więcej niż internetowy pamiętnik
Blog, więcej niż internetowy pamiętnik
 
Pozycjonowanie i optymalizacja stron WWW. Ćwiczenia praktyczne
Pozycjonowanie i optymalizacja stron WWW. Ćwiczenia praktycznePozycjonowanie i optymalizacja stron WWW. Ćwiczenia praktyczne
Pozycjonowanie i optymalizacja stron WWW. Ćwiczenia praktyczne
 
E-wizerunek. Internet jako narzędzie kreowania image'u w biznesie
E-wizerunek. Internet jako narzędzie kreowania image'u w biznesieE-wizerunek. Internet jako narzędzie kreowania image'u w biznesie
E-wizerunek. Internet jako narzędzie kreowania image'u w biznesie
 
Makrofotografia. Magia szczegółu
Makrofotografia. Magia szczegółuMakrofotografia. Magia szczegółu
Makrofotografia. Magia szczegółu
 
Java. Efektywne programowanie. Wydanie II
Java. Efektywne programowanie. Wydanie IIJava. Efektywne programowanie. Wydanie II
Java. Efektywne programowanie. Wydanie II
 
JavaScript. Pierwsze starcie
JavaScript. Pierwsze starcieJavaScript. Pierwsze starcie
JavaScript. Pierwsze starcie
 
PowerPoint 2007 PL. Seria praktyk
PowerPoint 2007 PL. Seria praktykPowerPoint 2007 PL. Seria praktyk
PowerPoint 2007 PL. Seria praktyk
 
Excel 2007 PL. Seria praktyk
Excel 2007 PL. Seria praktykExcel 2007 PL. Seria praktyk
Excel 2007 PL. Seria praktyk
 
Access 2007 PL. Seria praktyk
Access 2007 PL. Seria praktykAccess 2007 PL. Seria praktyk
Access 2007 PL. Seria praktyk
 
Word 2007 PL. Seria praktyk
Word 2007 PL. Seria praktykWord 2007 PL. Seria praktyk
Word 2007 PL. Seria praktyk
 
Serwisy społecznościowe. Budowa, administracja i moderacja
Serwisy społecznościowe. Budowa, administracja i moderacjaSerwisy społecznościowe. Budowa, administracja i moderacja
Serwisy społecznościowe. Budowa, administracja i moderacja
 
AutoCAD 2008 i 2008 PL
AutoCAD 2008 i 2008 PLAutoCAD 2008 i 2008 PL
AutoCAD 2008 i 2008 PL
 
Bazy danych. Pierwsze starcie
Bazy danych. Pierwsze starcieBazy danych. Pierwsze starcie
Bazy danych. Pierwsze starcie
 
Inventor. Pierwsze kroki
Inventor. Pierwsze krokiInventor. Pierwsze kroki
Inventor. Pierwsze kroki
 
Serwer SQL 2008. Administracja i programowanie
Serwer SQL 2008. Administracja i programowanieSerwer SQL 2008. Administracja i programowanie
Serwer SQL 2008. Administracja i programowanie
 
USB. Praktyczne programowanie z Windows API w C++
USB. Praktyczne programowanie z Windows API w C++USB. Praktyczne programowanie z Windows API w C++
USB. Praktyczne programowanie z Windows API w C++
 
Microsoft Visual Studio 2008. Księga eksperta
Microsoft Visual Studio 2008. Księga ekspertaMicrosoft Visual Studio 2008. Księga eksperta
Microsoft Visual Studio 2008. Księga eksperta
 
Rewizor GT. Prowadzenie ewidencji księgowej
Rewizor GT. Prowadzenie ewidencji księgowejRewizor GT. Prowadzenie ewidencji księgowej
Rewizor GT. Prowadzenie ewidencji księgowej
 
Fotografia cyfrowa. Poradnik bez kantów
Fotografia cyfrowa. Poradnik bez kantówFotografia cyfrowa. Poradnik bez kantów
Fotografia cyfrowa. Poradnik bez kantów
 

Hack Proofing XML. Edycja polska

  • 1. IDZ DO PRZYK£ADOWY ROZDZIA£ SPIS TRE CI Hack Proofing XML. Edycja polska KATALOG KSI¥¯EK Autor: praca zbiorowa KATALOG ONLINE T³umaczenie: Adam Jarczyk ISBN: 83-7361-004-9 Tytu³ orygina³u: Hack Proofing XML ZAMÓW DRUKOWANY KATALOG Format: B5, stron: 324 Przyk³ady na ftp: 15 kB TWÓJ KOSZYK DODAJ DO KOSZYKA 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¹ CENNIK I INFORMACJE 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, ZAMÓW INFORMACJE które czyni¹ XML silnym i uniwersalnym narzêdziem sprawiaj¹, ¿e jest on podatny na O NOWO CIACH 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 ZAMÓW CENNIK zagro¿enie dla systemów. „Hack Proofing XML. Edycja polska” obja ni Ci wszystkie niuanse bezpieczeñstwa zwi¹zane z technologiami XML i .NET. CZYTELNIA FRAGMENTY KSI¥¯EK ONLINE Wydawnictwo Helion ul. Chopina 6 44-100 Gliwice tel. (32)230-98-63 e-mail: helion@helion.pl
  • 2. Spis treści Podziękowania................................................................................... 7 Autorzy.............................................................................................. 9 Wstęp ............................................................................................. 13 Rozdział 1. Zen obrony przed hakerami .............................................................. 17 Wprowadzenie........................................................................................................17 Tao hakera .............................................................................................................17 Haker...............................................................................................................18 Kraker .............................................................................................................19 Script Kiddie ....................................................................................................20 Phreaker ..........................................................................................................21 Black hat, white hat, co za ró nica? ..........................................................................22 Gray hat...........................................................................................................23 Rola hakera ............................................................................................................24 Przestępca........................................................................................................24 Sztukmistrz ......................................................................................................25 Specjalista od zabezpieczeń ...............................................................................26 Obrońca klientów..............................................................................................27 Aktywista praw obywatelskich ...........................................................................28 Cyberwojownik ................................................................................................29 Motywacje hakera ..................................................................................................29 Uznanie............................................................................................................29 Podziw.............................................................................................................30 Ciekawość........................................................................................................31 Władza i korzyści..............................................................................................31 Zemsta.............................................................................................................32 Kodeks hakera........................................................................................................34 Podsumowanie .......................................................................................................35 Rozwiązania w skrócie ............................................................................................36 Pytania i odpowiedzi ...............................................................................................37 Rozdział 2. Klasy ataków................................................................................... 39 Wprowadzenie........................................................................................................39 Identyfikacja i charakter klas ataków ........................................................................39 Odmowa usługi.................................................................................................40 Przecieki informacji ..........................................................................................47 Dostęp do systemu plików .................................................................................52 Dezinformacja ..................................................................................................54
  • 3. 4 Hack Proofing XML. Edycja polska Dostęp do plików specjalnych i baz danych.........................................................58 Zdalne uruchomienie dowolnego kodu................................................................60 Rozszerzenie uprawnień ....................................................................................62 Metody szukania punktów podatnych na atak............................................................65 Dowód poprawności idei ...................................................................................65 Standardowe techniki badawcze .........................................................................68 Podsumowanie .......................................................................................................76 Rozwiązania w skrócie ............................................................................................78 Pytania i odpowiedzi ...............................................................................................79 Rozdział 3. Podstawy języka XML ...................................................................... 81 Wprowadzenie........................................................................................................81 Wprowadzenie do języka XML................................................................................82 Zało enia XML-a..............................................................................................82 Jak wygląda dokument XML?............................................................................82 Tworzenie dokumentu XML..............................................................................83 Struktura dokumentu XML................................................................................87 Poprawnie zbudowane dokumenty XML ..................................................................87 Transformacja XML-a poprzez XSLT ......................................................................88 Wykorzystanie wzorców przez XSL ...................................................................91 XPath ....................................................................................................................93 Podsumowanie .......................................................................................................94 Rozwiązania w skrócie ............................................................................................94 Pytania i odpowiedzi ...............................................................................................95 Rozdział 4. Typ dokumentu — kontrola poprawności .......................................... 97 Wprowadzenie........................................................................................................97 Definicje typu dokumentu i poprawnie zbudowane dokumenty XML ..........................98 Schemat i poprawne dokumenty XML.................................................................... 101 Wprowadzenie do ataków tekstem jawnym............................................................. 104 Ataki tekstem jawnym..................................................................................... 106 Sposoby kontroli poprawności XML-a.................................................................... 109 Kontrola poprawności wprowadzanego tekstu ................................................... 110 Kontrola poprawności dokumentu lub komunikatu............................................. 115 Podsumowanie ..................................................................................................... 123 Rozwiązania w skrócie .......................................................................................... 126 Pytania i odpowiedzi ............................................................................................. 127 Rozdział 5. Podpisy cyfrowe w XML-u............................................................... 129 Wprowadzenie...................................................................................................... 129 Zasady działania podpisu cyfrowego....................................................................... 129 Podstawowe pojęcia podpisów cyfrowych i uwierzytelniania .............................. 130 Zabezpieczanie za pomocą podpisów cyfrowych XML ............................................ 134 Przykłady podpisów XML ............................................................................... 134 Podpisywanie części dokumentu....................................................................... 143 Przekształcanie dokumentu za pomocą XPath ......................................................... 144 Przekształcanie dokumentu za pomocą XSLT ......................................................... 145 Zarządzanie listami podpisanych elementów za pomocą manifestów ......................... 147 Ustalanie to samości za pomocą X.509............................................................. 149 Algorytmy wymagane i zalecane ...................................................................... 150 Ostrze enia i pułapki............................................................................................. 151 Zestawy narzędzi producentów ........................................................................ 152 Podsumowanie ..................................................................................................... 153 Rozwiązania w skrócie .......................................................................................... 154 Pytania i odpowiedzi ............................................................................................. 156
  • 4. Spis treści 5 Rozdział 6. Szyfrowanie w XML-u ..................................................................... 157 Wprowadzenie...................................................................................................... 157 Rola szyfrowania w bezpieczeństwie przesyłanych wiadomości ................................ 158 Bezpieczeństwo wymagane przy przesyłaniu wiadomości................................... 158 Metody szyfrowania........................................................................................ 163 Jak stosować szyfrowanie w XML-u?..................................................................... 170 Transformacje XML-a przed zaszyfrowaniem ................................................... 173 Schemat procesu szyfrowania .......................................................................... 174 Praktyczne zastosowanie szyfrowania..................................................................... 175 Podpisywanie tekstu jawnego zamiast szyfrogramu............................................ 176 Szyfrogram nie pozwala na kontrolę poprawności jawnego tekstu ....................... 178 Szyfrowanie a odporność na kolizje .................................................................. 179 Podsumowanie ..................................................................................................... 179 Rozwiązania w skrócie .......................................................................................... 180 Pytania i odpowiedzi ............................................................................................. 180 Rozdział 7. Kontrola dostępu oparta na rolach.................................................. 183 Wprowadzenie...................................................................................................... 183 Mechanizm filtrowania z analizą stanu.................................................................... 183 Filtrowanie pakietów ....................................................................................... 184 Brama warstwy aplikacji.................................................................................. 185 Proces FTP .................................................................................................... 186 Technologie zapór sieciowych i XML............................................................... 187 Najpierw analiza stanu..................................................................................... 187 Ocena zmian stanu .......................................................................................... 189 Wpływ ustawień domyślnych na bezpieczeństwo............................................... 191 Kontrola dostępu oparta na rolach i implementacje wymuszania typu ........................ 192 NSA — architektura Flask ............................................................................... 194 SELinux......................................................................................................... 197 Wykorzystanie w XML-u technik kontroli dostępu opartej na rolach ......................... 202 Kiedy dokonywać oceny? ................................................................................ 205 Ochrona integralności danych .......................................................................... 206 RBAC i Java .................................................................................................. 207 Kontrola poprawności obiektów ActiveX .......................................................... 210 Narzędzia pomagające w implementacji mechanizmów RBAC ........................... 210 Podsumowanie ..................................................................................................... 215 Rozwiązania w skrócie .......................................................................................... 216 Pytania i odpowiedzi ............................................................................................. 217 Rozdział 8. .NET i bezpieczeństwo XML-a......................................................... 219 Wprowadzenie...................................................................................................... 219 Zagro enia związane z u ywaniem XML-a w .NET Framework ............................... 220 Problem poufności .......................................................................................... 220 Wewnętrzne zabezpieczenia .NET — realna alternatywa.......................................... 221 Uprawnienia ................................................................................................... 222 Uczestnik ....................................................................................................... 223 Uwierzytelnienie............................................................................................. 224 Autoryzacja .................................................................................................... 224 Zasady bezpieczeństwa.................................................................................... 224 Bezpieczeństwo typologiczne........................................................................... 224 Bezpieczeństwo dostępu kodu................................................................................ 225 Model bezpieczeństwa dostępu kodu w .NET.................................................... 225
  • 5. 6 Hack Proofing XML. Edycja polska Bezpieczeństwo oparte na rolach............................................................................ 240 Uczestnicy...................................................................................................... 241 Kontrola zabezpieczeń opartych na rolach ......................................................... 244 Zasady bezpieczeństwa ......................................................................................... 246 Tworzenie nowego zestawu uprawnień ............................................................. 248 Zmiany w strukturze grup kodu........................................................................ 253 Zabezpieczanie Remoting ................................................................................ 259 Kryptografia......................................................................................................... 259 Narzędzia zabezpieczeń......................................................................................... 262 Zabezpieczanie XML-a — najwa niejsze wskazówki............................................... 262 Szyfrowanie w XML-u.................................................................................... 262 Podpisy cyfrowe w XML-u.............................................................................. 267 Podsumowanie ..................................................................................................... 269 Rozwiązania w skrócie .......................................................................................... 271 Pytania i odpowiedzi ............................................................................................. 275 Rozdział 9. Zgłaszanie problemów związanych z bezpieczeństwem .................... 279 Wstęp .................................................................................................................. 279 Dlaczego nale y zgłaszać problemy związane z bezpieczeństwem? ........................... 280 Pełne ujawnienie ............................................................................................. 281 Kiedy i komu zgłosić problem? .............................................................................. 284 Komu zgłaszać problemy związane z bezpieczeństwem? .................................... 284 Jak wiele szczegółów publikować? ......................................................................... 287 Publikowanie kodu exploitu ............................................................................. 287 Problemy ....................................................................................................... 288 Podsumowanie ..................................................................................................... 290 Rozwiązania w skrócie .......................................................................................... 291 Pytania i odpowiedzi ............................................................................................. 292 Dodatek A Hack Proofing XML — rozwiązania w skrócie .................................. 295 Rozdział 1. Zen obrony przed hakerami .................................................................. 295 Rozdział 2. Klasy ataków ...................................................................................... 297 Rozdział 3. Podstawy języka XML......................................................................... 298 Rozdział 4. Typ dokumentu — kontrola poprawności .............................................. 299 Rozdział 5. Podpisy cyfrowe w XML-u .................................................................. 300 Rozdział 6. Szyfrowanie w XML-u ........................................................................ 302 Rozdział 7. Kontrola dostępu oparta na rolach ......................................................... 303 Rozdział 8. .NET i bezpieczeństwo XML-a............................................................. 303 Rozdział 9. Zgłaszanie problemów z bezpieczeństwem ............................................ 307 Skorowidz...................................................................................... 309
  • 6. 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.
  • 7. 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: !ZON XGTUKQP ! 1%6;2' ECVCNQI = '.'/'06 -CVCNQI 2TQFWMV
  • 8. '.'/'06 2TQFWMV 0T2TQFWMVW
  • 11. '.'/'06 0T2TQFWMVW 2%#6# '.'/'06 0CYC2TQFWMVW 2%#6# '.'/'06 %GPC5MNGRQYC 2%#6# '06+6; EQOOGPVAQWVQHUVQEM 6GP VQYCT LGUV LW PKGFQUVGRP[ Y OCIC[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: !ZON XGTUKQP ! 1%6;2' ECVCNQI = '.'/'06 -CVCNQI 2TQFWMV
  • 12. '.'/'06 2TQFWMV '/26; #66.+56 2TQFWMV 0T2TQFWMVW %#6# 4'37+4' 0CYC2TQFWMVW %#6# 4'37+4' %GPC5MNGRQYC %#6# 4'37+4' '06+6; EQOOGPVAQWVQHUVQEM 6GP VQYCT LGUV LW PKGFQUVGRP[ Y OCIC[PKG ?
  • 13. 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' ECVCNQI 5;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.+56 PCYC %#6# Dane znakowe. Mo e zawierać znaki (), znaki przedstawione jako nazwy ( NV) lub numery ( ) '06+6; '06+6; HQVQ 5;56'/ Odwołanie do obiektu, który nie będzie EHQVQLRI analizowany składniowo. Poprzez deklaracje 'PVKV[ są często tworzone odwołania do plików graficznych lub multimedialnych.
  • 14. 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.+56 EGINC NKEQYMC ^ Lista atrybutów. Atrybuty rozdzielone przez znak ^ HCMVWTQYCPC 4'37+4' muszą być pobierane pojedynczo. + #66.+56 /NQVGM 5-7 + Wartość atrybutu musi być legalną nazwą XML. 4'37+4' Musi te być unikatowa w obrębie dokumentu. Przypomina to stosowanie atrybutu klucza w bazach danych. +4'( #66.+56 0CTGFKC Wartość atrybutu jest identyfikatorem innego /NQVGM5-7 +4'( 4'37+4' 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 +. 0/61-'0 #66.+56 MNWE 0/61-'0 Wartość atrybutu musi być legalną nazwą XML. 4'37+4' 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. 016#6+10 #66.+56 V[RQITCHKEP[ Kolejna metoda wskazania na plik lub inny zasób, 016#6+10 4'37+4' 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# Analizowane składniowo dane znakowe. Podobny do typu atrybutu %#6#. Musi zawierać jedynie znaki. #0; Oznacza, e element mo e zawierać dane dowolnego typu. %JQKEGU 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 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. +ORNKGF Atrybut opcjonalny. Zdefiniowany element mo e pozostać pusty bez skutków ubocznych. .KVGTCN Atrybut posiada wartość początkową (domyślną) podaną w deklaracji. Wartość ta mo e zostać zmieniona przez dane wejściowe lub działanie aplikacji. 4GSWKTGF Do atrybutu musi być przypisana wartość.
  • 15. 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).
  • 16. 102 Hack Proofing XML. Edycja polska 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: ZUFGNGOGPV PCOG -CVCNQI OUFCVC+UCVC5GV VTWG ZUFEQORNGZ6[RG ZUFEJQKEG OCZ1EEWTU WPDQWPFGF 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 ZUFUEJGOC KF -CVCNQI VCTIGV0COGURCEG JVVRVGORWTKQTI%CVCNQIZUF ZONPU JVVRVGORWTKQTI%CVCNQIZUF ZONPUZUF JVVRYYYYQTI:/.5EJGOC
  • 17. Rozdział 4. ♦ Typ dokumentu — kontrola poprawności 103 ZONPUOUFCVC WTPUEJGOCUOKETQUQHVEQOZONOUFCVC CVVTKDWVG(QTOGHCWNV SWCNKHKGF GNGOGPV(QTOGHCWNV SWCNKHKGF ZUFGNGOGPV PCOG -CVCNQI OUFCVC+UCVC5GV VTWG OUFCVC'PHQTEG%QPUVTCKPVU (CNUG ZUFEQORNGZ6[RG ZUFEJQKEG OCZ1EEWTU WPDQWPFGF ZUFGNGOGPV PCOG 2TQFWMV ZUFEQORNGZ6[RG ZUFUGSWGPEG ZUFGNGOGPV PCOG 0T2TQFWMVW V[RG ZUFUVTKPI OKP1EEWTU ZUFGNGOGPV PCOG 0CYC2TQFWMVW V[RG ZUFUVTKPI OKP1EEWTU ZUFGNGOGPV PCOG %GPC5MNGRQYC V[RG ZUFUVTKPI OKP1EEWTU 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.
  • 18. 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
  • 19. Rozdział 4. ♦ Typ dokumentu — kontrola poprawności 105 Tabela 4.4. Typy danych w schemacie XML Podstawowy Pochodny Podstawowe Ograniczenia typ danych typ danych aspekty 5VTKPI PQTOCNKGF5VTKPI GSWCN NGPIVJ $QQNGCP 6QMGP QTFGTGF OKP.GPIVJ GEKOCN .CPIWCIG DQWPFGF OCZ.GPIVJ (NQCV 0/61-'0 ECTFKPCNKV[ RCVVGTP QWDNG 0/61-'05 PWOGTKE GPWOGTCVKQP WTCVKQP 0COG n/d YJKVG5RCEG FCVG6KOG 0%0COG n/d OCZ+PENWUKXG 6KOG + n/d OCZ'ZENWUKXG CVG +4'( n/d OKP'ZENWUKXG I;GCT/QPVJ +4'(5 n/d OKP+PENWUKXG I/QPVJC[ '06+6; n/d VQVCNKIKVU )C[ '06+6+'5 n/d HTCEVKQPKIKVU )/QPVJ +PVGIGT n/d n/d JGZ$KPCT[ PQP2QUKVKXG+PVGIGT n/d n/d DCUG$KPCT[ PGICVKXG+PVGIGT n/d n/d #P[74+ .QPI n/d n/d 3PCOG +PV n/d n/d 016#6+10 UJQTV n/d n/d );GCT $[VG n/d n/d n/d PQP0GICVKXG+PVGIGT n/d n/d n/d WPUKIPGF.QPI n/d n/d n/d WPUKIPGF+PV n/d n/d n/d WPUKIPGF5JQTV n/d n/d n/d WPUKIPGF$[VG n/d n/d n/d RQUKVKXG+PVGIGT 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:
  • 20. 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.
  • 21. 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
  • 22. 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
  • 23. 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 E CH, wówczas procedury kontrolne zabez- pieczeń, zaprogramowane do dekodowania najkrótszej implementacji, nie rozpoznały w nim ukośnika (). E CH E CH Ł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.
  • 24. 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ć
  • 25. 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[NMC VGIQ UCOGIQ FPKC Powy szy łańcuch zostanie zakodowany w ASCII. Następny przykład koduje ten sam łańcuch w Unicode: HCUVUJKR W 9[U[NMC VGIQ UCOGIQ FPKC 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.
  • 26. 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 danych jest zagwarantowanie, by wszystkie dane wejściowe posiadały odpowiedni typ, konfigurację i zakres na potrzeby danej aplikacji. Dla tego procesu nie istnieją żadne „standardowe” narzędzia, ponieważ aplikacje różnią się między sobą, lecz twórcy oprogramowania muszą znać pewne zasady: 1. Schematy nie najlepiej nadają się do kontroli poprawności danych wejściowych w intensywnie używanych serwisach, ponieważ muszą być wywoływane i interpretowane dla każdego wprowadzenia danych. 2. Java jest dobrym narzędziem kontroli poprawności danych, ponieważ może pobrać schemat i na jego podstawie opracować model dla narzędzia kontrolującego poprawność. 3. Wszelka kontrola danych wejściowych jest kosztowna, ponieważ zajmuje zasoby systemowe i czas procesora. Popularna aplikacja może wywoływać program kontrolujący poprawność danych setki lub tysiące razy na minutę. Optymalizacja kodu jest tu niezbędna.
  • 27. Rozdział 4. ♦ Typ dokumentu — kontrola poprawności 113 Kontrola poprawności Unicode Ochrona systemu przed atakami jawnym tekstem polega głównie na kontroli kodowa- nia stosowanej przy przekazywaniu znaków z jednego formatu do innego, zazwyczaj pomiędzy ASCII a jedną z postaci Unicode. Jako przykład sposobów, na jakie syste- my obsługują konwersję, przytoczymy funkcjonalność konwersji wejściowych łańcu- chów znakowych na Unicode udostępnianą przez Microsoft. Funkcja /WNVK$[VG6Q9KFG%JCT odwzorowuje wejściowy łańcuch znaków na łańcuch Unicode multibyte (wielobajtowy) niezale nie od tego, czy wprowadzane znaki wy- magają reprezentacji wielobajtowej czy nie. Z punktu widzenia kosztów funkcja zy- skuje pojedyncze, jednorodne odwzorowanie wszystkich znaków kosztem pamięci. Poniewa ataki tekstem jawnym zwykle wykorzystują ró nice w reprezentacji cha- rakterów kodowanych na ośmiu i szesnastu bitach, wyrównanie ustawień dla wszyst- kich łańcuchów wejściowych jest dobrym wstępem do eliminacji problemu. Struktura i argumenty /WNVK$[VG6Q9KFG%JCT są następujące: Listing 4.2. Struktura i argumenty MultiByteToWideChar +PV /WNVK$[VG6Q9KFG%JCT ] 7+06 %QFG2CIG 914 FY(NCIU .2%564 NR/WNVK$[VG5VT +PV ED/WNVK$[VG .29564 NR9KFG%JCT5VT +PV EEJ9KFG%JCT _ CodePage oznacza tutaj stronę kodową u ywaną przy konwersji. W chwili obecnej obsługiwane są dwie wartości. Przyjrzyjmy się bardziej szczegółowo tej funkcji: %2A#%2 — u ywa strony kodowej ANSI. %2A1'/%2 — odnosi się do strony kodowej OEM. FY(NCIU — ustala, czy znaki są zestawieniem, czy mają wartości proste (/$A24'%1/215') czy są zło one (/$A%1/215+6'); czy znaki powinny zostać przetłumaczone na kształty, a nie na znaki sterujące (/$A75').;2*%#45), oraz czy komunikat o błędzie powinien zostać zgłoszony przy napotkaniu niepoprawnego znaku (/$A'44A+08#.+A%*#45). NR/WNVK$[VG5VT — wskazuje na wejściowy łańcuch znaków. ED/WNVK$[VG — rozmiar łańcucha wejściowego w bajtach. Jeśli parametr ma wartość 1, wówczas długość obliczana jest automatycznie. NR9KFG%JCT5VT — bufor wyjściowy, w którym zostanie umieszczony łańcuch po translacji. EEJ9KFG%CT — rozmiar bufora wyjściowego w znakach wide character. Poza funkcją /WNVK$[VG6Q9KFG%JCT Microsoft obsługuje translację znaków poprzez sko- jarzone funkcje, na przykład 9KFG%JCT6Q/WNVK$[VG, która zasadniczo odwraca proces
  • 28. 114 Hack Proofing XML. Edycja polska /WNVK$[VG6Q9KFG%JCT, 6TCPUNCVG%JCTUGV+PHQ, która dokonuje translacji na podstawie określonego zestawu znaków i przydaje się, gdy napotkamy znane języki oparte na innym zestawie znaków ni łaciński, oraz +U$%5.GCF$[VG, która ustala, czy dany znak powinien zostać przetłumaczony jako znak jednobajtowy, czy te jako pierwszy bajt dwubajtowego znaku zło onego. Inne języki umo liwiają na zbli onym poziomie kontrolę nad translacją pomiędzy łańcuchami ASCII i Unicode. Widzieliśmy ju , na przykład, e Python pozwala na zakodowanie łańcucha wejściowego w Unicode poprzez dodanie prefiksu W. Python pozwala równie na bardziej precyzyjną kontrolę poprzez inne dostępne funkcje. Ko- dowanie w określonym zestawie językowym mo emy wyspecyfikować za pomocą metody GPEQFG . Weźmy poprzedni przykład: HCUVUJKR W 9[U[NMC VGIQ UCOGIQ FPKC Mo emy wymusić konwersję tego łańcucha z być mo e nieznanego formatu Unicode, właściwego dla systemu hosta, na format Unicode odpowiadający bezpośrednio tabli- cy 8-bitowych znaków ASCII w sposób następujący: HCUVUJKR 9[U[NMC VGIQ UCOGIQ FPKC HCUVUJKRGPEQFG NCVKP Podobne metody mogą posłu yć do translacji z formatu Unicode na inny. Translacja z innego formatu do Unicode wykorzystuje format WPKEQFG , który mo e przyjmować argumenty wymuszające określony kod Unicode. Na przykład: WPKEQFG 9[U[NMC VGIQ UCOGIQ FPKC WVH Ten wycinek programu koduje łańcuch w zestawie znaków dwubajtowych Unicode UTF-16. Podczas takich translacji mo liwa jest próba translacji znaku do zestawu, w którym znak ten nie jest reprezentowany. Python udostępnia trzy sposoby obsługi tego błędu wybierane przez programistę. Opcje te u ywane są w metodzie następująco: WPKEQFG 9[U[NMC VGIQ UCOGIQ FPKC WVH UVTKEV^KIPQTG^TGRNCEG Podanie UVTKEV spowoduje niepowodzenie metody, jeśli odwzorowanie będzie nie- mo liwe; KIPQTG prowadzi do usunięcia nie przekształconego znaku z łańcucha wyj- ściowego, zaś TGRNCEG zastępuje problematyczny znak przez W((( (oficjalny znak zastępczy w języku Python). W ka dym z dostępnych kodów znak W((( będzie de- finiowany indywidualnie. W przedstawionych przykładach system programistyczny udostępnia programiście narzędzia, pozwalające kontrolować sposób translacji. Niezale nie od u ywanego sys- temu najwa niejszą czynnością programisty będzie aktywny wybór i konsekwentne stosowanie metody translacji w dokumencie XML i w aplikacji. Konsekwentne stoso- wanie jednego schematu translacji minimalizuje prawdopodobieństwo niezamierzonych konsekwencji i nieumyślnych luk w zabezpieczeniach powodowanych przez niedopaso- wane reprezentacje znaków przy przekazywaniu danych z jednego komponentu opro- gramowania do innego.
  • 29. Rozdział 4. ♦ Typ dokumentu — kontrola poprawności 115 Kontrola poprawności dokumentu lub komunikatu Gdy ju w rozsądnych granicach mo emy zało yć, e dane wprowadzane do systemu składają się z legalnych i nieszkodliwych znaków, wówczas zaczyna się etap procesu kontroli poprawności, który pochłania najwięcej zasobów komputera. Na tym etapie kontrolowane są dane i komunikaty w celu upewnienia się, czy wartości prawidłowo mieszczą się w określonych dla danej aplikacji granicach. Pomyślmy o aplikacji katalogu, do której odwoływaliśmy się w tym rozdziale. Na war- tości mo na przypuszczalnie nało yć kilka typów ograniczeń, aby zagwarantować, by dane były odpowiednie dla aplikacji. Na przykład, ceny będą danymi liczbowymi, a nie znakami alfabetu. Numery kart kredytowych u ytych do zapłaty będą mieścić się w zna- nym zakresie długości, podobnie jak numery telefonów i kody pocztowe. Ka da z tych wartości jest kandydatem do ścisłej kontroli poprawności. Poniewa pracujemy z XML-em, mo emy wykorzystać schemat jako narzędzie do ograniczania danych. W przypadku numerów telefonicznych łatwo jest zbudować elementy schematu zapewniające, by numer był zgodny z podstawowym systemem (przykład dotyczy numerów w USA). Fragment schematu dla aplikacji katalogu zo- stał przedstawiony poni ej. Fragment ten dopuszcza jedynie dane zgodne z formatem standardowych numerów telefonów w USA, aczkolwiek pozwala te na stosowanie maksymalnie pięciocyfrowych numerów wewnętrznych. Listing 4.3. Fragment schematu, ograniczający dane do postaci standardowych numerów telefonicznych USA ZUFUEJGOC KF %CVCNQI VCTIGV0COGURCEG JVVRVGORWTKQTI%CVCNQIZUF ZONPU JVVRVGORWTKQTI%CVCNQIZUF ZONPUZUF JVVRYYYYQTI:/.5EJGOC ZONPUOUFCVC WTPUEJGOCUOKETQUQHVEQOZONOUFCVC CVVTKDWVG(QTOGHCWNV SWCNKHKGF GNGOGPV(QTOGHCWNV SWCNKHKGF ZUFEQORNGZ6[RG PCOG VGNGRJQPG ZUFUGSWGPEG ZUFGNGOGPV PCOG CTGCEQFG ZUFUKORNG6[RG ZUFTGUVTKEVKQP DCUG ZUFUVTKPI ZUFRCVVGTP XCNWG FFF ZUFTGUVTKEVKQP ZUFUKORNG6[RG ZUFGNGOGPV ZUFGNGOGPV PCOG GZEJCPIG ZUFUKORNG6[RG ZUFTGUVTKEVKQP DCUG ZUFUVTKPI ZUFRCVVGTP XCNWG FFF ZUFTGUVTKEVKQP ZUFUKORNG6[RG ZUFGNGOGPV ZUFGNGOGPV PCOG PWODGT ZUFUKORNG6[RG ZUFTGUVTKEVKQP DCUG ZUFUVTKPI ZUFRCVVGTP XCNWG FFFF ZUFTGUVTKEVKQP
  • 30. 116 Hack Proofing XML. Edycja polska ZUFUKORNG6[RG ZUFGNGOGPV ZUFGNGOGPV PCOG GZVGPUKQP ZUFUKORNG6[RG ZUFTGUVTKEVKQP DCUG ZUFUVTKPI ZUFRCVVGTP XCNWG FFFFF ZUFTGUVTKEVKQP ZUFUKORNG6[RG ZUFGNGOGPV ZUFUGSWGPEG ZUFEQORNGZ6[RG Ten fragment, wykorzystujący dopasowanie do wzorca w celu wymuszenia sekwen- cji cyfr ::::::::::::::: (dopuszczającą pięciocyfrowy numer wewnętrzny), jest łatwy do napisania i zrozumienia. Proces pisania schematu nakładającego ogranicze- nia na wszystkie dane katalogowe byłby stosunkowo prosty, aczkolwiek nieco mud- ny. Wiedząc, e jesteśmy w stanie to uczynić, mo emy przemyśleć, czy naprawdę te- go chcemy. Mimo du ych mo liwości schematy XML trapi kilka problemów, z powodu których raczej nie warto u ywać ich jako jedynego mechanizmu kontroli poprawności danych dla naszej aplikacji. Po pierwsze, specyfikacja schematu XML nie została jeszcze ukończona i zatwierdzona. Jeśli zbudujemy kod aplikacji oparty na schemacie, ist- nieje realne prawdopodobieństwo, i drobne zmiany w ostatecznej specyfikacji będą mogły spowodować konieczność zmian kodu aplikacji. Drugi problem jest chyba po- wa niejszy, poniewa dotyczy bezpośrednio szybkości działania aplikacji. Schemat XML musi być wywoływany i parsowany za ka dym razem, gdy zaistnieje potrzeba kontroli poprawności. W przypadku cieszącej się popularnością aplikacji ka- talogu lub informacji telefonicznej mo e to oznaczać tysiące ądań kontroli poprawności danych na minutę. Mo liwa jest konwersja schematu na obiekt dokumentu DOM i za- pisanie w pamięci podręcznej, co zaoszczędzi czasu wymaganego do pobrania sche- matu z dysku przy ka dym wywołaniu, lecz wcią nie pozbędziemy się w ten sposób konieczności analizy składni schematu przy ka dym wywołaniu. Gdy spojrzymy na obcią enie systemu komputerowego przez powtarzające się przebiegi analizy składni schematu, stanie się oczywiste, i kontrola poprawności danych oparta jedynie na mo- delu schematu jest bardzo, bardzo kosztownym rozwiązaniem. Znacznie rozsądniejszą metodą jest zastosowanie schematu do zdefiniowania ograni- czeń danych, a następnie konwersja schematu na program w języku np. Tcl, Python lub Java. Taka metoda kontroli poprawności równie obcią a system, lecz w mniejszym stopniu ni poprzednia. Proces musi być jak najszybszy, co oznacza, e w tym miej- scu powinien być stosowany najwydajniejszy sprzęt, aby nie stał się wąskim gardłem. Tutaj te mo na u yć serwerów równoległych, rozkładając obcią enie obliczeniowe na kilka fizycznych komputerów. Czy XML jest poprawnie zbudowany? Pierwszym krokiem ochrony aplikacji przed atakami (lub nawet przed niezamierzony- mi powa nymi błędami prowadzącymi do katastrofy) jest zapewnienie, by struktura
  • 31. Rozdział 4. ♦ Typ dokumentu — kontrola poprawności 117 i zawartość strumienia danych zachowywały się zgodnie z oczekiwaniami programi- sty. XML udostępnia do tego celu dwa narzędzia: DTD i schematy. Jak ju pokazali- śmy, DTD są narzędziami weryfikującymi poprawną budowę dokumentu XML, to znaczy zgodność z właściwą gramatyką i sposobem u ycia XML-a, oraz konsekwent- ne u ycie danych i struktur w całym dokumencie. Schematy mogą posłu yć do kon- troli poprawnej budowy dokumentu, lecz znacznie wychodzą poza zakres zagadnień strukturalnych, pozwalając programistom kontrolować typy i zawartość składników i samych struktur. Zarówno DTD, jak i schematy są cennymi narzędziami, zaś do jed- nego dokumentu mo emy zastosować jedne i drugie rozwiązanie. Znajomość ró nic pomiędzy nimi pomo e nam budować bezpieczniejsze dokumenty. Weryfikacja struktury za pomocą DTD DTD jest pierwszym etapem zapewniania jakości dokumentu XML. Kontrola popraw- ności poprzez DTD potwierdza, i dokument jest poprawnie zbudowany — to znaczy, e struktura dokumentu odpowiada strukturze zdefiniowanej w DTD. Kontrolę popraw- ności mo e przeprowadzić zewnętrzny analizator składni lub paser zawarty w edyto- rze lub systemach programowania, np. XML Spy czy VS.NET. DTD są starszą formą kontroli poprawności dokumentów XML obsługiwaną przez wszystkie parsery języka XML. Są analizowane składniowo i kontrolowane przed prze- tworzeniem schematów. Niestety, DTD posiadają te znacznie mniejsze mo liwości ni schematy. Nadal są jednak przydatne do wymuszania jednolitej struktury dokumen- tów. Znacząca część tej wartości bierze się ze zdolności zewnętrznych DTD do wy- muszania jednakowych struktur dokumentów XML tworzonych w ró nych miejscach organizacji lub u partnerów biznesowych. Niestety, ta wa na zaleta niesie ze sobą zna- czące zagro enia bezpieczeństwa, dodatkowo zwiększone w schemacie XML. W wielu przypadkach zewnętrzne DTD są przechowywane w serwerach poza zasię- giem kontroli lokalnych twórców dokumentów XML. W takich przypadkach wywoła- nie DTD oznacza korzystanie ze źródła, które niekoniecznie jest bezpieczne. Jeśli ta- kie nie jest, wówczas przechwycona przez hakera definicja DTD mo e lawinowo roz- przestrzenić luki w zabezpieczeniach w innych organizacjach. Dotyczy to zwłaszcza przypadków, gdy typy '06+6; i 016#6+10 są powszechnie u ywane — chocia by przy tworzeniu baz danych multimedialnych. Na przykład, zmiana typu jednostki z %#6# na '06+6; pozwoli na u ycie w niej danych znakowych bez generowania błędów. Jednak- e zarazem umo liwi to przeniesienie aplikacji wiersza poleceń przez system XML do komputera docelowego bez kontroli poprawności zabezpieczeń ze strony systemu XML. Kontrola spójności danych za pomocą schematu Pokazaliśmy, e sam schemat niekoniecznie jest najlepszym narzędziem do kontroli po- prawności jednolitości i przydatności danych wejściowych. Nie znaczy to, e schematy nie są przydatne. Nadal pozostają cennym narzędziem wymuszania zgodności doku- mentów XML ze standardami i jednolitości dokumentów w ró nych organizacjach. Jedną z zalet schematów jest fakt, i same w sobie są poprawnymi dokumentami XML. Gdy dokument zawierający schemat wywołuje analizator składni kontrolujący popraw- ność, wówczas schemat jest kontrolowany, zanim zostanie wykorzystany do kontroli
  • 32. 118 Hack Proofing XML. Edycja polska poprawności samego dokumentu. Poziom spójności osiągany przez taką kilkustopnio- wą kontrolę poprawności jest znaczący. Aktualny problem ze schematami polega na braku ostatecznego zatwierdzenia stan- dardów. W chwili obecnej u ywane są trzy główne odmiany schematów. Schematami XML są: XML Data Reduced (XDR) — u ywany w pierwszej wersji protokołu SOAP (Simple Object Access Protocol) i obsługiwany przez Microsoft. Regular Language description for XML (RELAX) — uproszczony schemat, zaprojektowany do łatwego przechodzenia pomiędzy DTD i schematami. Dodatkowe informacje znajdziemy pod adresem http://www.xml.gr.jp/relax. Schemat XML W3C — ten schemat mają na myśli wszyscy mówiący o „standardowym schemacie”. Na ostateczną wersję schemat XML organizacji W3C równie niecierpliwie oczekuje wielu programistów. Dodatkowe informacje znajdziemy pod adresem http://www.w3.org/TR/xmlschema-0. Wspólnym problemem DTD i schematów jest kwestia zewnętrznych odwołań. Podob- nie jak DTD, wiele schematów to zewnętrzne zasoby, z którymi łączy się du a liczba ró nych dokumentów XML. Poniewa schematy kontrolują dane i struktury o wiele bardziej rygorystycznie ni DTD, potencjalne zagro enie ze strony schematów przeję- tych przez hakerów jest większe. Z uwagi na to, na twórcach dokumentów spoczywa jeszcze większa odpowiedzialność za zapewnienie, by wszystkie u ywane schematy zewnętrzne pochodziły z bezpiecznych serwerów utrzymywanych przez zaufanych partnerów. Metody i mechanizmy kontroli poprawności online Gdy nadchodzi pora kontroli poprawności dokumentów XML, mo emy postąpić na jeden z wielu sposobów. Wszystkie opcje łączy jeden wymóg: kontrolujący popraw- ność parser (analizator składni) musi odczytać wszystkie wiersze dokumentu i zwrócić raport o wszelkich naruszeniach poprawności lub o dobrze skonstruowanej strukturze. Wszystkie dostępne narzędzia do kontroli poprawności XML-a spełniają to najprost- sze kryterium. Oprócz niego istnieje wiele opcji skorzystania z parsera sprawdzające- go poprawność. Mo e to być autonomiczny produkt lub składnik pakietu do edycji lub programowania. Praktycznie wszystkie narzędzia kontrolujące poprawność są w sta- nie opierać kontrolę na DTD, co stanowi jedną z zalet tego starszego mechanizmu. Poni sze podpunkty przedstawią kilka najłatwiej dostępnych narzędzi online pozwa- lających na kontrolę poprawności w oparciu o DTD i schematy. XML Spy 4.3 Program XML Spy 4.3, stworzony przez firmę Altova, jest środowiskiem programo- wania dla XML-a i obejmuje kontrolę poprawności na podstawie DTD i schematów, dostęp do baz danych ODBC (Open Database Connectivity) oraz całkowicie zinte- growane środowisko programowania. Darmową, 30-dniowa wersję próbną mo emy znaleźć pod adresem http://www.xmlspy.com.
  • 33. Rozdział 4. ♦ Typ dokumentu — kontrola poprawności 119 W3C: Validator for XML Schema Udostępniony przez W3C program kontroli poprawności dokumentów XML na pod- stawie schematu mo emy znaleźć pod adresem http://www.w3.org/2001/03/webdata/ xsv. Serwis ten zapewnia mo liwość korzystania ze schematów dostępnych poprzez WWW, jak równie znajdujących się za zaporą firewall przedsiębiorstwa (patrz: ry- sunek 4.2). Rysunek 4.2. Ekran powitalny programu W3C Validator for XML Schema Programiści mogą przesyłać do niego dokumenty XML na dwa sposoby: podając ogól- nodostępny adres URI lub ładując plik z sieci lokalnej. Poprawnie zbudowany doku- ment zwróci jedynie prosty ekran z komunikatem, jak widać na rysunku 4.3. Rysunek 4.3. Notatka zwrócona dla poprawnie zbudowanego dokumentu Gdy program sprawdzający poprawność przeanalizuje dokument z błędami, otrzyma- my ekran z komunikatami o błędach, podający typ błędu i jego poło enie w pliku, jak pokazano na rysunku 4.4.
  • 34. 120 Hack Proofing XML. Edycja polska Rysunek 4.4. Dokument zawierający błędy powoduje wygenerowanie komunikatu o błędzie Powinniśmy zwrócić uwagę na jedną wa ną właściwość programu kontrolującego poprawność — podobnie jak wiele staroświeckich narzędzi tego typu, zatrzymuje się po natrafieniu na pierwszy błąd. Jeśli nasz dokument jest długi i zawiera ich sporo, wówczas zapewnienie poprawnej budowy dokumentu będzie wymagało wielokrotne- go jego uruchomienia. Formularz kontroli poprawności XML-a z Brown University Programiści z Brown University stworzyli formularz pozwalający kontrolować popraw- ność XML-a. Formularz ten jest dostępny online pod adresem http://www.stg.brown. edu/service/xmlvalid/. Krótkie dokumenty mo emy skopiować i wkleić bezpośrednio na stronie; większe dokumenty są wywoływane poprzez adres. Gdy po raz pierwszy otworzymy formularz kontroli poprawności z Brown University, zobaczymy prosty ekran interfejsu jak przedstawiono na rysunku 4.5. Od razu widać, e grupa programistów z Brown podeszła do kontroli poprawności zupełnie inaczej ni w przypadku innych takich serwisów online, poniewa dokument zaakceptowany przez programy W3C i RUWF zwraca w przypadku Brown University wyniki jak te z rysunku 4.6. Jak widzimy, dokument został surowo oceniony. Większość błędów wyszczególnionych przez ten formularz dla innych narzędzi było- by co najwy ej ostrze eniami. Jeśli potrzebujemy absolutnej pewności, e dokument będzie działać, wówczas narzędzie z Brown University pozwoli nam tę pewność uzy- skać, lecz inne narzędzia powiedzą, czy dokument będzie działać czy nie przy wyko- rzystaniu znacznie mniejszej liczby wierszy komentarza. Jednym z problemów, jakie napotyka się w przypadku takiego podejścia, jakie zastosowano w Brown University, jest kontrola plików zawierających znane problemy. Plik, który spowodował wygene- rowanie błędów w narzędziach W3C i RUWF, w narzędziu z Brown zwrócił ekran przestawiony na rysunku 4.7. Proszę zwrócić uwagę, e wyniki dla pliku poprawnego i niepoprawnego są do siebie podobne. Raporty generowane przez dwa wprowadzone pliki niewiele się od siebie ró nią. W wy- nikach dla „złego” pliku błędy znalezione przez inne narzędzia kontroli poprawności
  • 35. Rozdział 4. ♦ Typ dokumentu — kontrola poprawności 121 Rysunek 4.5. Formularz kontroli poprawności online z Brown University Rysunek 4.6. Plik zaakceptowany przez inne programy kontrolujące poprawność został mocno skrytykowany w Brown