Architektura CORBA. Przegląd technologii dla komponentowych,, rozproszonych aplikacji internetowych J2EE

Transkrypt

1 Architektura CORBA 314 Przegląd technologii dla komponentowych,, rozproszonych aplikacji internetowych CORBA: Common Object Request Broker Architecture Jedna z pierwszych architektur budowy heterogenicznych rozproszonych aplikacji komponentowych Specyfikacja obejmuje architekturę oraz język opisu interfejsów - IDL (Interface Description Language) Aplikacje CORBA składają się z programu klienta, współpracującego z programami serwerów poprzez warstwę komunikacyjną ORB (Object Request Broker) Serwer Klient Client Proxy wg IDL Szkielet serwera wg IDL Object Adapter Object Request Broker J2EE 315 Enterprise JavaBeans (EJB) 316 J2EE (Java2 Enterprise Edition) to platforma tworzenia i uruchamiania rozproszonych aplikacji wielowarstwowych, zwykle wykorzystywanych przez użytkowników przy użyciu przeglądarki WWW W skład J2EE wchodzą: zbiór specyfikacji dla poszczególnych technologii składowych: Servlet, JavaServer Pages, Enterprise JavaBeans, JDBC, JNDI, RMI-IIOP, JMS, JTA, JAAS,... zbiór bibliotek standardowych języka Java służących do tworzenia różnych typów programów zbiór zasad projektowania, implementowania i instalowania aplikacji J2EE, m.in. umożliwiających wyraźny rozdział ról członków zespołu projektowego serwer aplikacji J2EE, stanowiący środowisko uruchomieniowe dla aplikacji J2EE Specyfikacja Enterprise JavaBeans definiuje architekturę i metodę budowy rozproszonych komponentów obiektowych uruchamianych po stronie serwera aplikacji Komponenty EJB są wykorzystywane do budowy złożonych aplikacji rozproszonych na zasadzie składania z klocków typowo stanowią warstwę logiki biznesowej dla aplikacji J2EE, w której za logikę prezentacji odpowiadają serwlety i JSP przeglądarka aplikacja klienta żądanie http dokument HTML wywołania metod wyniki metod serwer aplikacji (serwer J2EE) kontener serwletów JSP kontener EJB komponent EJB

2 Typy komponentów EJB 317 Usługi sieciowe (Web Services) 318 Specyfikacja Enterprise JavaBeans 2.0 definiuje trzy typy komponentów EJB: sesyjne (Session Bean): sesyjny komponent EJB to krótkotrwały obiekt wykorzystywany przez pojedynczą aplikację klienta i nie współdzielony z innymi aplikacjami, stanowiący logiczne rozszerzenie kodu aplikacji klienta umieszczone po stronie serwera aplikacji encyjne (Entity Bean): encyjny komponent EJB reprezentuje dane, które są trwale przechowywane w systemie bazy danych; cechuje się długim czasem życia, pozwala na atomowe, transakcyjne modyfikacje bazy danych, współdzielony przez wielu klientów, dostępny dla wielu sesji komunikatowe (Message-Driven Bean): komunikatowy komponent EJB jest asynchronicznym konsumentem komunikatów JMS (Java Messaging Service) pochodzących ze środowisk kolejkowych; uruchamiany wtedy, kiedy nadchodzi komunikat od klienta, wykonywany asynchronicznie, może modyfikować zawartość bazy danych, bezstanowy Web Services to technologia budowania rozproszonych, heterogenicznych, komunikujących się ze sobą aplikacji Usługi sieciowe samodzielnie się opisują są zorientowane na świadczenie usług są oparte o standardy (HTTP, SMTP, XML, SOAP, WSDL, UDDI) opisują komunikację między aplikacjami są niezależne od platformy i języka implementacji Architektura zorientowana na usługi opublikuj dostawca usługi rejestr usług wywołaj znajdź klient usługi Elementy usług sieciowych (1/2) 319 Elementy usług sieciowych (2/2) 320 Komunikacja: podstawą funkcjonowania usług sieciowych są tradycyjne protokoły internetowe (HTTP, FTP) za pomocą których usługi sieciowe komunikują się ze sobą Uniwersalny format danych: usługi sieciowe korzystają z XML w celu wymiany danych oraz w celu opisu funkcjonalności poszczególnych usług Simple Object Access Protocol (SOAP): usługi sieciowe wykorzystują protokół SOAP do wymiany komunikatów XML. Protokół SOAP funkcjonuje jako wrapper dla komunikatów XML, zamykając je w tzw. Kopertach (ang. SOAP envelope) Web Services Description Language (WSDL): dokumenty WSDL to samoopisujące się specyfikacje prezentujące funkcjonalność danej usługi. Dokumenty WSDL są zgodne z XML i zawierają informację w jaki sposób należy korzystać z danej usługi sieciowej Dokumenty WSDL mogą być automatycznie przetłumaczone na język programowania wykorzystywany przez programistę (Client Proxy) Universal Description, Discovery and Integration (UDDI): rejestry usług UDDI przechowują dokumenty WSDL opisujące usługi. Rejestry te są przeszukiwane w celu zlokalizowania odpowiedniej usługi. Rejestry UDDI są wykorzystywane przez dostawców usług do publikowania usług

3 Architektura SOAP 321 SOAP, WSDL, UDDI - Podsumowanie 322 metoda(par1,par2) klient SOAP wynik wynik serwer SOAP usługa SOAP (klasa) metoda(par1,par2) wyszukiwanie usługi WSDL UDDI serializacja wywołania deserializacja wyniku serializacja wyniku deserializacja wywołania WSDL Client Proxy XML XML HTTP XML XML aplikacja klienta Wywołanie metody przez klienta jest konwertowane do dokumentu XML. Argumenty wywołania są serializowane (konwertowane do ciągu bajtów reprezentowanego heksadecymalnie). Dokument XML, nazywany komunikatem SOAP, jest przekazywany poprzez HTTP POST do usługi, która po dokonaniu deserializacji argumentów wywołania metody, uruchamia żądaną metodę i przekazuje zwrotnie jej rezultat, korzystając z analogicznego algorytmu. aplikacja klienta wywołanie usługi wyniki usługa SOAP Platforma Microsoft.NET 323.NET Framework 324.NET Framework umożliwia tworzenie i uruchamianie: aplikacji klienckich aplikacji webowych usług sieciowych Narzędzia programistyczne: Microsoft Visual Studio.NET zintegrowane środowisko programistyczne (IDE) wizualno-zdarzeniowe projektowanie aplikacji klienckich i webowych duża produktywność programisty Serwery: Microsoft Windows Server 2003 Microsoft SQL Server Microsoft BizTalk Server Oprogramowanie klienckie: WindowsXP, WindowsCE, OfficeXP Umożliwia tworzenie i uruchamianie nowoczesnych aplikacji i usług sieciowych Wspiera ponad 20 języków programowania najważniejsze to: Visual Basic.NET, C++, C#, J# Implementuje typową funkcjonalność aplikacji, pozwalając twórcom aplikacji skupić się na specyficznej logice konkretnej aplikacji Podstawowe cele.net Framework: łatwość tworzenia bezpiecznych i wydajnych aplikacji łatwość instalacji aplikacji i administrowania nimi Składniki.NET Framework: wspólne środowisko uruchomieniowe Common Language Runtime (CLR) biblioteki klas

4 Architektura.NET Framework 325 ASP.NET 326 Usługi Web Services ASP.NET Klasy Web Forms Klasy Windows Forms Dostęp do danych (ADO.NET), biblioteki XML Podstawowe biblioteki klas: I/O, łańcuchy znaków, sieć,... Wspólne środowisko uruchomieniowe (CLR) Aplikacje są kompilowane do języka pośredniego Microsoft Intermediate Language (MSIL) i w tej postaci mogą być dystrybuowane Przy pierwszym uruchomieniu aplikacji kod pośredni jest kompilowany do kodu maszynowego przez CLR Technologia tworzenia dynamicznych stron internetowych dla platformy.net i środowiska uruchomieniowego CLR Umożliwia korzystnie ze wszystkich języków obsługiwanych przez CLR Kod kompilowany - wydajność i wykrywanie błędów (postęp w stosunku do interpretowanych ASP) Umożliwia tworzenie aplikacji dwóch typów: aplikacje Web Forms (strony internetowe) usługi Web Services Programowanie zdarzeniowe Dodawanie kontrolek do formularzy i pisanie kodu do obsługi zdarzeń związanych z kontrolkami AJAX 327 Model aplikacji internetowej AJAX 328 AJAX = Asynchronous JavaScript And XML Jesse James Garrett, luty 2005 AJAX nie jest nową samodzielną technologią AJAX jest nową techniką tworzenia aplikacji internetowych w oparciu o znane technologie, które ostatnio osiągnęły dojrzałość: (X)HTML, CSS, JavaScript, DOM, XML Programowanie w AJAX nie wymaga uczenia się nowych technologii, ale wymaga zmiany sposobu myślenia o tworzeniu aplikacji internetowych Przyczyna popularności AJAX: Poziom interaktywności aplikacji zbliżony do aplikacji desktopowych, dotychczas niespotykany w aplikacjach internetowych Rich Internet Applications, Web 2.0 Asynchroniczna komunikacja z serwerem z poziomu kodu JavaScript w przeglądarce Poprzez obiekt XMLHttpRequest Serwer wysyła dane, fragmenty dokumentu, kodu JS i CSS, a nie całe strony Dokument w przeglądarce (interfejs użytkownika) jest modyfikowany programowo poprzez interfejs DOM Przeglądarka Interfejs użytkownika Żądanie HTTP Wywołania JavaScript Engine AJAX Serwer WWW Serwer bazy danych HTML + CSS XML

5 Przykład aplikacji AJAX: Google Suggest 329 Zagrożenia bezpieczeństwa aplikacji internetowych Zagrożenia trywialne 331 Parametry ukryte 332 Rozwiązania charakterystyczne dla fazy rozwoju opisy rozpoznanych błędów, debugging, komentarze poprzednie wersje plików (cp plik.jsp plik.jsp.old) znaczniki <META>: autor, wersja oprogramowania developerskiego Często stosowaną praktyką jest zapisywanie zmiennych w ukrytych polach formularzy <input name="x type="hidden value=1> Jeśli zapamiętują istotne dane, to ich modyfikacja może prowadzić do skutecznego ataku

6 Modyfikowanie parametrów wywołania Parametry mogą być przekazywane za pomocą metody GET lub POST 1. Zapisać plik HTML na dysku, zmienić wartość zmiennej i lokalnie otworzyć plik w przeglądarce 2. Zastosować oprogramowanie typu Local Proxy, potrafiące modyfikować komunikację HTTP (Stake WebProxy, Odysseus) 333 Dołączanie nowych parametrów W niektórych językach skryptowych (PHP, JSP) parametry pobierane od użytkownika są automatycznie rejestrowane jako zmienne globalne Powszechnym błędem jest brak inicjalizacji zmiennych Jeżeli intruz przewidzi nazwę zmiennej i nada jej wartość, to będzie w stanie zmienić sposób działania aplikacji: if (sprawdz_w_bazie($login,$pass)) { $state="ok"; // ustawienie flagi }... if ($state == "OK") { // sprawdzenie flagi UWIERZYTELNIENIE OK } else { BŁĄD! } Dołączanie nowego parametru - JSP 335 Brak obsługi sytuacji specjalnych 336 Danych reprezentowane przez obiekt JavaBean Wartości parametrów z formularza HTML są przekazywane przy użyciu znaku * <jsp:usebean id="mybasket" class="basketbean"> <jsp:setproperty name="mybasket" property="*"/> <jsp:usebean> Wszystkie sytuacje specjalne (błędy) powinny zostać świadomie obsłużone przez aplikacje Sytuacja specjalna (np. brak parametru, którego spodziewa się aplikacja) może doprowadzić do zmiany sposobu działania aplikacji <html> <head><title>your Basket</title></head> <body> <p> You have added the item <jsp:getproperty name="mybasket" property="newitem"/> to your basket. <br/> Your total is $ <jsp:getproperty name="mybasket" property="balance"/> Proceed to <a href="checkout.jsp">checkout</a> Atak:

7 Parametry zapisywane w zmiennych Cookies 337 Path traversal 338 Do modyfikowania wartości zmiennych Cookie można wykorzystać Local Proxy Typowe cele ataku: zmiana identyfikatora sesji zmiana znacznika (flagi np. oznaczającej stan uwierzytelnienia) lang=en-us; AUTHORIZED=yes; y=1 ; time=12:30gmt; Klasa ataków polegająca na uzyskaniu dostępu do standardowo niedostępnego pliku/katalogu na serwerze WWW Zagrożenie wiąże się z wykorzystywaniem przez aplikacje parametrów pobieranych ze środowiska użytkownika do konstruowania nazwy pliku Przykład: atak poprzez modyfikację nagłówka HTTP nagłówek Accept-Language jest ustawiany przez przeglądarkę wykorzystywany do skonstruowania nazwy pliku z odpowiednią wersją językową atakujący modyfikując ten nagłówek może pozyskać dowolny plik Path traversal - Oracle 9iAS 339 OS Command Injection 340 Tego typu błąd istniał np. w 9iAS w module mod_plsql %25 % %5C / w rezultacie: /../plsql.conf Aplikacja przekazuje parametry ze środowiska użytkownika do wywołania systemowego funkcja API wywołanie komendy Jeżeli parametry te nie są weryfikowane, to możliwe jest: dołączenie własnych parametrów wywołanie innej komendy systemowej

8 SQL Injection 341 SQL Injection - konsekwencje 342 Brak weryfikacji parametrów przekazywanych przez użytkownika Konstrukcja zapytań SQL przez sklejanie statycznego SQL ze specjalnie przygotowanymi wartościami parametrów, np: String query = "SELECT * FROM USER_RECORDS WHERE USER = " + request.getparameter("username"); ResultSet result = Statement.executeQuery(query); Doklejenie do parametru swojego kodu, np: username = x or 1=1 SELECT * FROM USER_RECORDS WHERE USER = x or 1=1 username = x union select * from all_users SELECT * FROM USER_RECORDS WHERE USER = x UNION SELECT * FROM all_users Niekontrolowany dostęp do danych... UNION SELECT... Zmiana sposobu działania aplikacji... OR 1=1 W wielu interpreterach SQL jest możliwe wykonanie kilku działań w jednej linii... ; DELETE * FROM... Modyfikacja danych String query = UPDATE users SET password = + haslo + WHERE username = + uzytkownik + ; haslo: 'moje' uzytkownik: x' OR username LIKE 'admin Przejęcie sesji 343 Przewidywalny token 344 HTTP jest protokołem bezstanowym i każde jego żądanie jest traktowane niezależnie Aplikacje WWW wymagają obsługi sesji (kojarzenia wielu odwołań w jedną sesje) Aplikacja implementuje sesję przy pomocy identyfikatora sesji (tokena), zwykle zapisywanego w zmiennej Cookie Aby podszyć się pod inną sesję wystarczy znać jej token Jak poznać token sesji? Podsłuchać Przewidzieć - jeżeli algorytm pozwala na przewidzenie wartości tokena (nie jest losowy) Wykraść Token powinien być generowany silnym algorytmem losowym Przestrzeń możliwych tokenów powinna być bardzo duża Złe praktyki: Token sekwencyjny Zależny od parametrów użytkownika Nieograniczony czasowo

9 Przewidywalny token (c.d.) 345 Wykradnięcie tokena 346 Zwykle serwer aplikacji dba o nadawanie tokenów, a aplikacja korzysta z jego API Nie zawsze można polegać na serwerze aplikacji Przykład: IBM WebSphere 4.0 TWGYLZIAAACVDQ3UUSZQV2I 10:27:12 TWGY0WYAAACVFQ3UUSZQV2I 10:27:13 TWGZNZAAAACVHQ3UUSZQV2I 10:27:14 TWG0BUYAAACVJQ3UUSZQV2I 10:27:15 TWG0VIAAAACVLQ3UUSZQV2I 10:27:16 TWG1ICIAAACVNQ3UUSZQV2I 10:27:17 TWG111YAAACVPQ3UUSZQV2I 10:27:18 Algorytm łatwy do odgadnięcia Możliwość przeszukania całej przestrzeni tokena Słabości: Przeglądarek - standardowo cookie jest dostępne tylko dla serwera który je wydał Serwerów Np: PHP4 zapisywało tokeny w katalogu /tmp na serwerze Cross-site scripting Cross-Site Scripting (XSS) 347 Cele ataków XSS 348 Atak na użytkownika za pomocą aplikacji (nosiciela) Istota ataku: Wykonanie kodu HTML na przeglądarce ofiary (bez jej wiedzy) za pomocą podatnej aplikacji (nosiciela) Przykład: aplikacja WWW obsługuje chat-room intruz w nowej wiadomości umieszcza znaczniki HTML i skrypt kliencki (JavaScript, VBS) ofiara przegląda wiadomość za pośrednictwem przeglądarki HTML jest interpretowany i wykonywany po stronie klienta Załadowanie strony z innego serwera: <script>document.write('<img src=" )</script> Wykradnięcie informacji np. cookie: <script>document.write('<img src=" </script> Wykradnięta informacja znajdzie się w logach serwera zly.com

10 XSS - metody ataku 349 Buffer Overflow 350 Generalna zasada: aplikacja nosiciela wyświetla na generowanych stronach parametr pobierany od użytkownika nie sprawdzając go Chat-room i inne aplikacje pobierające tekst od użytkownika XSS w parametrach GET link w u link na stronie www Buffer Overflow Dotyczy języków niekontrolujących pamięci operacyjnej (np. C, C++) Jedna z najpopularniejszych metod ataku na różne aplikacje Zagrożenie: brak sprawdzania przez aplikacje długości wprowadzonego przez użytkownika ciągu, przepełnienie bufora i nadpisanie pamięci