Uwierzytelnianie a aplikacja GWT

Przypomnijmy sobie najpierw jak przebiega typowy proces uwierzytelnienia i jakie role w nim występują. Po pierwsze, mamy użytkownika, który wypełnia pola interfejsu aplikacji, przeznaczone na wprowadzenie loginu i hasła. Po drugie, mamy procedurę weryfikacji tych danych, najprawdopodobniej odpytującą warstwę trwałości – a więc pewną bazę – w celu skonfrontowania wartości dostarczonych przez użytkownika z tymi, przyjmowanymi za prawidłowe. Hasła użytkowników powinny być przechowywane w warstwie trwałości w postaci zaszyfrowanej, aby nie ujawnić prawdziwego hasła nawet w przypadku wycieku danych z bazy. W tym celu możemy skorzystać z jednej z bibliotek Java do szyfrowania (np. jBCrypt) lub szyfrowania realizowanego przez bazę danych.

Specyfiką aplikacji napisanej w GWT jest działanie interfejsu całkowicie po stronie klienta, pod kontrolą przeglądarki internetowej. Informacje podane przez użytkownika muszą zatem być przekazane przez sieć, do zdalnego serwera, gdzie nastąpi weryfikacja. Czy proces uwierzytelnienia mógłby być przeprowadzony w aplikacji klienckiej? Oczywiście nie, bo kod działający lokalnie w przeglądarce użytkownika można łatwo zmodyfikować i obejść jakiekolwiek zabezpieczenia, pomijając sprawdzenie poprawności danych.

Pierwsze pytanie jakie rodzi nam się w głowie, to w jaki sposób zabezpieczyć dane przesyłane przez sieć. Wysyłamy kombinację login i hasło, czy nie powinny być one w jakiś sposób zaszyfrowane? Nie jest to niestety proste, bo jak pamiętamy, nasza aplikacja po kompilacji staje się kodem JavaScriptowym, działającym w przeglądarce internetowej. Działamy więc w dużo bardziej ograniczonym środowisku – ze względu na język i platformę uruchomieniową – niż, chociażby aplikacje standalone w Javie. W szczególności, mamy zawężone możliwości wykonywania bardziej skomplikowanych operacji matematycznych, a co za tym idzie większość bibliotek kryptograficznych jest bezużyteczna w aplikacjach GWT. Poza tym należy pamiętać, że zaszyfrowanie hasła po stronie klienta i przesłanie go otwartym kanałem niewiele nam daje. Po pierwsze, kod kliencki jest całkowicie modyfikowalny, więc algorytm szyfrowania można zmienić, usunąć lub zasymulować we własnej aplikacji atakującego. Po drugie, podsłuchanie zaszyfrowanego hasła jest tak samo wartościowe dla atakującego, co podsłuchanie hasła niezaszyfrowanego – w pierwszym przypadku serwer weryfikuje przecież poprawność na podstawie wartości zaszyfrowanej.

Cóż nam pozostaje? Możemy pozostać przy przesyłaniu hasła otwartym tekstem do serwera (pamiętając jednak o szyfrowaniu w bazie), możemy wykorzystać komunikację SSL, ażeby uniemożliwić podsłuch lub – w końcu – możemy całkowicie zrezygnować z uwierzytelniania w aplikacji GWT i przeprowadzić ją bezpośrednio na serwerze. Aplikacja GWT zostanie załadowana dopiero po uwierzytelnieniu i przyjmować będzie, że zawsze działa w kontekście pewnego uwierzytelnionego użytkownika.

Formularz logowania a automatyczne zapisywanie hasła

W tym artykule nie będę się zajmował szczegółowo kwestiami bezpieczeństwa, chciałbym jednak zwrócić uwagę na mechanizm, który od pewnego czasu bardzo ułatwia nam życie jako użytkownikom systemów. Mianowicie każda chyba z istniejących obecnie przeglądarek umożliwia zapisywanie hasła po pierwszym wpisaniu ich w odpowiednie pola aplikacji internetowej i automatyczne wypełnianie przy każdym kolejnym włączeniu owej aplikacji. Skąd przeglądarka wie, że pola tekstowe, które widnieją na stronie służą do “zalogowania się” użytkownika? Reguły nieco różnią się pomiędzy przeglądarkami, ale generalnie na stronie musi znajdować się pole tekstowe i pole typu password w formularzu z przyciskiem “submit”, a formularz ten nie może być generowany dynamicznie przez JavaScript (musi istnieć w oryginalnym HTMLu). Pamiętając, że aplikacja GWT tworzy swój interfejs po stronie klienta dynamicznie, poprzez modyfikację dokumentu za pomocą JavaScriptu, widzimy od razu, że w przypadku formularza zrealizowanego w GWT automatyczne zapisywanie hasła nie zadziała.

Co możemy zatem zrobić? Chciałbym przedstawić trzy rozwiązania, które różnią się rezultatem, a wybór jednego z nich powinien nastąpić po zastanowieniu się, czy najbardziej zależy nam na kompatybilności ze wszystkimi przeglądarkami, czy na łatwości oprogramowania procesu uwierzytelnienia, czy też na możliwości utworzenia formularza z kodu GWT.

Podejście pierwsze

W skrócie pomysł można opisać następująco: na stronie, będącej kontenerem naszej aplikacji tworzymy ukryty formularz do wpisywania loginu i hasła przez użytkowników (w statycznym HTMLu), natomiast w kodzie GWT pokazujemy ów formularz wtedy, kiedy jest potrzebny i niskopoziomowymi instrukcjami, umożliwiającymi dostęp do elementów HTML pobieramy dane z pól tekstowych i przesyłamy na serwer. Po odebraniu i pozytywnym zinterpretowaniu odpowiedzi ukrywamy formularz i umożliwiamy dalsze działanie aplikacji. Podejście takie zaproponowane zostało w oficjalnym FAQu GWT i można zaimplementować je w następujący sposób (MyApp.html):

<div id="hiddenDiv" style="visibility:hidden">
 <form id="loginForm" action="/myApp/login">
  <h1>Proszę się zalogować</h1>
  <center>
  <table>
   <tr><td>Login:</td>
    <td><input type="text" id="login" /></td></tr>
   <tr><td>Hasło:</td>
    <td><input type="password" id="password" /></td></tr>
   <tr><td><input type="submit" id="submit" /></td>
    <td><input type="reset" /></td></tr>
  </table></center>
 </form>
</div>

W kodzie aplikacji, z formularza skorzystalibyśmy następująco (opakowujemy formularz HTML w komponent GWT i sygnalizujemy, że chcemy, żeby akcja formularza była wykonana w iframie zagnieżdżonym na stronie – drugi argument metody FormPanel.wrap jest ustawiony na true):

Element formElement = Document.get().getElementById("loginForm");
if (formElement != null) {
 Element formDiv = Document.get().getElementById("hiddenDiv");
 if (formDiv != null) {
  formDiv.setAttribute("style", "visibility:visible");
 }
 FormPanel form = FormPanel.wrap(formElement, true);
 form.addSubmitCompleteHandler(new SubmitCompleteHandler() {
  @Override
  public void onSubmitComplete(SubmitCompleteEvent event) {
   zinterpretuj(event.getResults());
  }
 });
}

W tym podejściu na serwerze musimy wygenerować odpowiedź w postaci tekstowej (Content-Type: text/html) – np. JSON i zinterpretować po stronie klienta, w celu podjęcia decyzji, czy dopuścić użytkownika do dalszej części aplikacji. Można do formularza również dodać słuchacza SubmitHandler, w którym zaimplementujemy wstępną walidację wprowadzonych wartości przed wysłaniem na serwer.

Drugie podejście

W tym podejściu chcemy wykorzystać standardową dla GWT komunikację z serwerem na zasadzie zdalnego wywoływania metod, a nie samodzielnego generowania odpowiedzi na serwerze w postaci tekstowej. Rozwiązanie, zaproponowane w tym wątku, opiera się pomyśle, aby akcją wykonywaną przy wysłaniu formularza nie było fizyczne przesłanie danych na serwer, a wywołanie pośredniej metody JavaScriptowej, która dopiero zawoła zdalną metodę, tak jak zwykle robi się to w GWT. Nasz plik .html wygląda analogicznie jak poprzednio, z różnicą dotyczącą domyślnej akcji po wysłaniu formularza:

<div id="hiddenDiv" style="visibility:hidden">
 <form id="loginForm" action="javascript:__gwt_login()">
 ...

Natomiast w kodzie wykonujemy następujące operacje (tym razem formularz nie musi znajdować się w zagnieżdżonym iframie):

injectLoginFunction(this);
Element formElement = Document.get().getElementById("loginForm");
if (formElement != null) {
 Element formDiv = Document.get().getElementById("hiddenDiv");
 if (formDiv != null) {
  formDiv.setAttribute("style", "visibility:visible");
 }
 FormPanel form = FormPanel.wrap(formElement, false);
}

Metoda injectLoginFunction dodaje do strony funkcję JavaScriptową, która pośredniczy w wywołaniu RPC:

private native void injectLoginFunction(LoginViewImpl inst) /*-{
 $wnd.__gwt_login = function() {
  inst.@pl.com.sages.client.view.LoginViewImpl::doLogin()();
 }
}-*/;

public void doLogin() {
 loginValue = InputElement.as(Document.get()
  .getElementById("login")).getValue();
 passwordValue = InputElement.as(Document.get()
  .getElementById("password")).getValue();
 rpcService.verifyUser(login, password, new AsyncCallback< ...
 // zdalne wywołanie metody na serwerze i rejestracja słuchacza,
 // interpretującego odpowiedź
}

To podejście nie działa niestety w przeglądarkach opartych na WebKicie, np. w Chrome.

Trzecie podejście

Ten sposób rozwiązania formularza do identyfikacji użytkownika został zaproponowany na blogu Matta Raible. Założenie było takie, żeby wykorzystać komponenty GWT jakie pola do wpisywania loginu i hasła (również z zewnętrznych bibliotek – np. GXT), a nie poprzestawać na standardowych kontrolkach HTML. W tym wypadku akcją przypisaną do ukrytego formularza HTML musi być prawidłowy URL, np. /myApp/login, inaczej (przynajmniej w moich testach) zapamiętywania hasła nie działa. W naszym kodzie przepisujemy wartości podane przez użytkownika (wprowadzone do naszych komponentów GWT) do owego ukrytego formularza:

Document.get().getElementById("login").setAttribute("value",
 loginField.getValue());
Document.get().getElementById("password").setAttribute("value",
 passwordField.getValue());

Element formElement = Document.get().getElementById("loginForm");
FormPanel form = FormPanel.wrap(formElement, true);
form.submit();

Wysłanie formularza powoduje pojawienie się pytania o zgodę na zapisania hasła w przeglądarce. Pozostaje jeszcze kwestia przepisania wartości pól z automatycznie wypełnionego przez przeglądarkę formularza HTML na nasze komponenty GWT. Matt Raible proponuje wykorzystanie klasy Timer, żeby opóźnić przepisanie wartości pól, aż będą one dostępne dla skryptu, ale w moich testach nie było to potrzebne:

loginField.setValue(((InputElement)Document.get()
 .getElementById("login")).getValue());
passwordField.setValue(((InputElement)Document.get()
 .getElementById("password")).getValue());

Również i to podejście nie działa niestety w Chrome.

Rozpatrzmy prostą funkcję zaprezentowaną poniżej:

void VulnFunc(char *ptr)
{
  char buffer[32];
  int i;

  for(i=0;(*ptr)!='&';i++)
    buffer[i]=*(ptr++);

  //dalsze instrukcje działające na buforze, nie zmieniające jego
  //zawartości, przykładowo liczące wartość skrótu MD5 z zawartości
  //bufora, nieistotne jeśli chodzi o atak buffer overflow
}

Możemy łatwo wyobrazić sobie i podać zadanie tej funkcji, która pobiera pewne dane, kopiuje je do bufora oraz wykonuje z jego pomocą pewne operacje. Łatwo możemy wskazać widoczny od razu błąd: dane kopiujemy do bufora bez sprawdzania czy go nie przepełnimy. Warunkiem zakończenia kopiowania jest natrafienie na znak &. Właśnie taki błąd, o ile możemy podać dowolne dane wejściowe może zostać wykorzystany.

Nim przejdziemy do preparowania odpowiedniego ciągu znaków będących exploitem obejrzyjmy stos podczas normalnego wywołania funkcji, zaprezentowany na rysunku nr 1.

Stos podczas normalnego wywołania funkcji

W lewej części rysunku przedstawiona jest zawartość pamięci wykorzystywanej na stos. Wyróżnione na czerwono obszary to zmienna i oraz bufor, z przepisaną zawartością, w tym przypadku tekstem „Ala”. Wyróżniony na niebiesko fragment to wskaźnik ptr przekazywany jako parametr. Wszystkie te informacje można skonfrontować z zawartością zmiennych podczas wykonania programu zaprezentowanych po prawej stronie rysunku.

Wróćmy na chwilę do wyróżnionego na niebiesko adresu, będącego parametrem. W takim przypadku nasze zainteresowanie powinny dotyczyć 32 bitowy adres znajdujący się bezpośrednio przed nim. Adres ten, jest adresem powrotu z funkcji. Jeśli uda nam się go zmienić, w momencie powrotu z funkcji … wykonamy inny kod, nieprzewidziany przez programistę.

Aby prześledzić taki przypadek rozpatrzmy sytuację, kiedy do funkcji zostanie podany ciąg znaków postaci (liczby hexadecymalne):


0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x83,0xec,0x80,0xbe,
0xe6,0x10,0x41,0x00,0x68,0x41,0x6c,0x61,0x00,0x8b,0xdc,0x6a,0x40,0x53,
0x53,0x33,0xc0,0x50,0xff,0xd6,0xff,0x15,0xe6,0x6c,0x41,0x00,0x68,
0xfd,0x12,0x00,0x26

… i podobnie jak w poprzednim wywołaniu funkcji prześledźmy zawartość stosu.

Stos przy próbie ataku

Na zaprezentowanym rysunku możemy zaobserwować, że do bufora zostało przepisane dużo więcej danych niż poprzednio. Dokładnie 44 bajty (wartość hexadecymalna 2c w obszarze pamięci zmiennej i). Wartość ta jest większa niż zadeklarowany na 32 bajty bufor. Jednak co najważniejsze, czy – powinniśmy powiedzieć – najgroźniejsze, został nadpisany adres powrotu z funkcji (fragment wyróżniony na niebiesko), gdzie teraz znajdują się instrukcje które zostaną wykonane przez program. Pamiętając iż zmienne na maszynach z procesorem Intel są przechowywane „od końca” możemy odkodować adres powrotu. Skok nastąpi do instrukcji znajdującej się pod adresem 0×0012fd68. Jeśli przyjrzymy się dokładnie obszarowi pamięci stosu, możemy zauważyć, że skoczymy w zaprezentowany na rysunku obszar pamięci. Dokładniej wykonanie nowego kodu zaczniemy od instrukcji o kodzie 0×90. Dalej możemy zaobserwować jeszcze kilka instrukcji o tym samym kodzie. Taka sekwencja jest często spotykana w exploitach. Kod 0×90 ma instrukcja NOP – no operation. Instrukcja która nic nie robi, ale ma długość jednego bajta. Taka sekwencją zwana poduszeczką NOP ( jest przydatna, jeśli okazało by się, iż nie trafimy dokładnie w początek kodu exploita). Dalszą analizę tego kodu zostawmy na później … i zobaczmy co się stanie jak wykonamy ten kod. Wyniki przedstawia rysunek.

Wykonanie kodu

Co robi kod na stosie … trochę assemblera

Znaczenie instrukcji o kodzie 0×90 zostało już wyjaśnione wcześniej, teraz przyjrzyjmy się reszcie kodu.
. . .

Co robi ten kod? Pierwsza instrukcja odejmuje 128 od rejestru esp – stack pointer, robiąc miejsce na stosie dla dalszego kodu. W dalszej części przypisujemy do rejestru esi adres funkcji MessageBox. Później odkładamy 5 wartości na stos, najpierw pewne dane, które już wcześniej widzieliśmy na stosie (co dokładnie … zostawiam czytelnikowi do zgadnięcia). Nim odłożymy kolejne 4 wartości zapamiętujemy zawartość rejestru esp w rejestrze ebx. Adres ten odpowiada początkowi stosu, czyli aktualnie danym załadowanym na stos przed chwila. W dalszej części odkładamy na stos liczbę 0×40, dwa razy wskaźnik wskazujący na pewne dane znajdujące się na stosie oraz wartość 0. Potem dokonujemy wywołania funkcji MessageBoxA. Co robiliśmy wcześniej na stosie? – odkładaliśmy parametry – handle do okna (0 – NULL, czyli okno bez powiązania z innym oknem), dalej dwa razy wskaźnik na zawartość okna i jego tytuł (czy już wiadomo jakie dane były wkładane na stos? ) i na końcu typ okna, w naszym przypadku okno informacyjne. Na uwagę zasługuje jeszcze ostatnia wartość – 0×26 czyli w reprezentacji ASCII znak & – warunek stopu pętli kopiującej dane do bufora.

Oczywiście zaprezentowany w tym przykładzie kod nie robi nic groźnego, jedynie wyświetla okienko. Jednak mając więcej miejsca na stosie można spreparować naprawdę groźną funkcję. Ale to już temat na kolejny wpis …

Kilka wyjaśnień

Wykorzystywane w przykładowym kodzie exploita adresy zostały wcześniej odkryte poprzez analizę kodu działającego programu za pomocą debuggera. Architektura systemu Windows (no może z wyjątkiem Visty i dalszych) powoduje, że w tym samym środowisku (te same zainstalowane programy) wykonujący się program zawsze będzie posiadał te same adresy funkcji oraz stosu. Dzięki temu w środowisku testowym można je poznać … i wykorzystywać do ataku na inne identyczne lub podobne (patrz poduszeczkę NOP) systemy. Analogicznie ma się sprawa z adresem wykorzystywanej funkcji MessageBoxA.

Lekkie aplikacje w JEE i to bez dodatkowych szkieletów?

Wprowadzenie koncepcji Komponentu Zarządzanego (Managed Bean – dalej MB)

Wyodrębnienie specyfikacji Interceptors

Wprowadzenie możliwości wstrzykiwania zależności (Dependency Injction)

Wprowadzenie kontekstów

Wprowadzenie koncepcji profilu

Co dalej?

DODATEK 1 – Wymagania Specyfikacji Managed Beans.

Wymagania podstawowe:


@ManagedBean(“myName“),
public class MyClass{

@PostConstruct
public void init(){}

@PreDestroy
public void destroy(){};

//inne metody

}

Rozszerzenie wymagań:

DODATEK 2 – Lista specyfikacja wymagana dla serwera umożliwiającego udostępnianie aplikacji zgodnej z Web Profile

DODATEK 3 – EJB vs. EJB Light

Wykorzystanie podatności wstrzyknięcia (ang. Injection Flaw) jest częstą przyczyną włamań do aplikacji internetowych. Problemy związane z bezpieczeństwem aplikacji dotyczące wstrzyknięcia niepoprawnych danych na stronach z polami testowymi są powszechne (w szczególności ataki typu Cross Site Scripting, XSS). Jednak możliwość wykorzystania podatności wstrzyknięcia na stronach bez pól tekstowych nie jest już tak oczywista.

Injection Flaw

Rozpatrzmy prostą funkcjonalność aplikacji obsługującej sklep internetowy, służącą do przedstawienia statusu złożonych zamówień. Przykładowy wygląd takiej aplikacji przedstawiony jest na rysunku 1.

Jak można przypuszczać, informacja uzyskana od użytkownika, związana z wyborem interesującego statusu przesyłki służy do sparametryzowania zapytania SQL do bazy danych. Z dużym prawdopodobieństwem można założyć, że wykorzystane zapytanie SQL będzie zbliżone do zapytania w następującej postaci:

SELECT id, towar, adres FROM zamowienia WHERE klient_id = ...
and status = ...

Jeśli założy się, że programista aplikacji kleił ręcznie zapytanie oraz nie zapewnił walidacji dostarczanych danych, łatwo można się domyśleć jaki tekst trzeba umieścić w zapytaniu aby uzyskać informację o wszystkich zamówieniach.

Rozważyć można sytuację, kiedy zamiast spodziewanego identyfikatora statusu podstawiony zostanie fragment zapytania SQL postaci:

4 or 1=1

W takim przypadku warunek w zapytaniu będzie zawsze prawdziwy, co w efekcie spowoduje wyszukanie wszystkich rekordów z tabeli.

Ponieważ aplikacja wysyła dane użytkownika za pomocą metody GET, w wysyłanym URLu możemy zaobserwować wszystkie parametry. Wystarczy, że w odpowiednim miejscu zostanie wklejony spreparowany fragment danych a cały URL ponownie wysłany. Na rysunku 2 można zaobserwować wynik wykonania za pomocą zwykłej przeglądarki takiego złośliwego zapytania.

Jak można było się spodziewać, w wyniku tego zapytania została ujawniona cała zawartość tabeli. W tym przypadku poznano wszystkich adresatów do których sklep wysłał paczki. Jednak jeśli byłby to system bankowy i “dziurawa” funkcjonalność dotyczyłaby kodów jednorazowych – ujawnione zostałyby adresy, pod które zostały one wysłane. Jeśli w tablicy znajdowały by się adresy mailowe, to ich poznanie mogło by posłużyć do wysyłania SPAMu lub wiadomości związanych z phishingiem. Taki atak byłby o tyle groźny, że dotyczył rzeczywistych klientów danej organizacji.

W omawianym powyżej przykładzie aplikacja wykorzystywała do komunikacje metodę GET, więc atak można przeprowadzić nawet za pomocą przeglądarki. Jednak wykorzystanie metody POST, chociaż ukrywa część informacji przed zwykłym użytkownikiem oraz umożliwia szyfrowanie przesyłanych danych w przypadku protokołu HTTPS, nie jest zabezpieczeniem (patrz paradygmat security by obscurity). W takim przypadku pomocne może być narzędzie WebScarab. WebScarab jest specjalnym rodzajem serwera proxy. Każde żądanie przechodzące przez niego jest przechwytywane i może zostać dowolnie zmodyfikowane. Program ten jest często wykorzystywany przy testach bezpieczeństwa aplikacji webowych.

Jak przeprowadzić atak wykorzystując program WebScarab

Pierwszym krokiem jest ustawienie proxy w używanej przeglądarce na adres wykorzystywany przez program WebScarab (standardowo nasłuchuje na porcie 8008). Następnym krokiem jest wejście na stronę, której ewentualne podatności chcemy sprawdzić. Podczas wywołania zapytania zostanie ono przechwycone i zaprezentowane użytkownikowi. W tym miejscu można dokonać dowolnych modyfikacji nagłówków a także danych przesyłanych za pomocą metody POST. Przykład takiej modyfikacji dobrze znanym fragmentem zapytania SQL zaprezentowany jest na rysunku 3.

Efekt przeprowadzonych działań widoczny jest na rysunku 4.

Zgodnie z oczekiwaniami po zatwierdzeniu zmiany dokonanej w programie WebScarab uzyskany zostaje dostęp do wszystkich danych znajdujących się w tabeli.

Podsumowanie

Jak można zabezpieczyć się przed tego typu atakiem

• Nie kleić ręcznie zapytań, zamiast tego skorzystać ze specjalnych funkcji lub obiektów służących do tego (ale nie zawsze się da, np. zapytanie XPath). Dla przykładu, w JDBC mamy do dospozycji PreparedStatement:

  . . .
  PreparedStatement ps;
  c = ds.getConnection();
  ps = c.prepareStatement("SELECT id, towar, adres FROM zamowienia
     WHERE klient_id = ? and status = ?");
  ps.setString(1, klient_id);
  ps.setString(2, status);
  ps.execute();
  . . .
  

• Nie ufać w żadne dane wysłane od klienta, zawsze dokonywać walidacji albo choćby procesu escapowania danych

  . . .
  
  try {
     Integer val = null;
     val = val.parseInt(request.getParameter("status"));
     if (val <= 0 || val > 4)
        throw new NumberValidationException(); //własna klasa wyjątku
     . . .
  } catch(NumberFormatException ex) {
     out.println("Parameter problem, try once again");
  } catch(NumberValidationException ex) {
     out.println("Parameter problem, try once again");
  } catch(...) ...
  

]]> http://blog.sages.com.pl/2010/03/atak-wstrzykniecia-na-stronach-bez-pol-tekstowych/feed/ 0 http://blog.sages.com.pl/2010/03/optymalizacja-zapytan-z-podzapytaniami/ http://blog.sages.com.pl/2010/03/optymalizacja-zapytan-z-podzapytaniami/#comments Tue, 02 Mar 2010 12:38:32 +0000 Piotr Kołaczkowski http://blog.sages.com.pl/?p=17 Współczesne systemy relacyjnych baz danych, również te z otwartym kodem źródłowym, umożliwiają tworzenie bardzo złożonych zapytań SQL. Poprzez umieszczanie podzapytań w seksji SELECT, FROM oraz WHERE, jak również przez łączenie zapytań za pomocą operatorów takich jak UNION czy INTERSECT, nie trudno napisać zapytanie, które nie zmieści się na monitorze. Ta elastyczność ma niestety swoją cenę: analiza takiego złożonego zapytania jest nie lada wyzwaniem dla silnika bazy danych i, jak pokazuje praktyka, niektóre systemy baz danych nie najlepiej sobie z tym radzą. Najprościej wytłumaczyć to na przykładzie, wzorowanym na prawdziwym przypadku.

Wyobraźmy sobie, że tworzymy system, którego jednym z zadań jest zapisywanie informacji o aktywności użytkowników umieszczających pliki na serwerze. Dla każdego zarejestrowanego użytkownika, chcemy wiedzieć, kiedy i jaki plik umieścił. Schemat bazy danych dla tej funkcjonalności wygląda następująco:

             Table "public.test_user"
     Column      |         Type          | Modifiers
-----------------+-----------------------+-----------
 user_id         | integer               | not null
 name            | character varying(64) | not null
 login           | character varying(16) | not null
 hashed_password | character varying(32) | not null

Indexes:
    "test_user_pkey" PRIMARY KEY, btree (user_id)
    "test_user_login_key" UNIQUE, btree ("login")

            Table "public.test_upload"
   Column    |          Type          | Modifiers
-------------+------------------------+-----------
 upload_id   | integer                | not null
 user_id     | integer                | not null
 path        | character varying(255) | not null
 upload_time | timestamp              | not null

Indexes:
    "test_upload_pkey" PRIMARY KEY, btree (upload_id)
Foreign-key constraints:
    "test_upload_user_id_fkey" FOREIGN KEY (user_id)
        REFERENCES test_user(user_id)

Tabela test_user zawiera ok. 10 tys. użytkowników. Jeden użytkownik średnio umieścił na serwerze 5 plików, choć są oczywiście tacy, którzy nie umieścili ani jednego, jak i tacy, którzy umieścili ich kilkaset. Każdemu umieszczonemu plikowi odpowiada jeden rekord w tabeli test_upload.

Powiedzmy, że nasz przykładowy serwis potrzebuje wyświetlić 10 różnych użytkowników, którzy dodawali ostatnio jakieś pliki. Użytkownik, który dodał plik najdawniej, ma znaleźć się na końcu listy, użytkownik, którego plik jest “najświeższy” – na samym początku. Jednak żaden użytkownik nie powinien znaleźć się na liście “top 10″ więcej niż raz.

Pierwsze podejście do tego zapytania mogłoby wyglądać następująco:

SELECT name, path, upload_time
FROM test_user u JOIN test_upload l ON (u.user_id = l.user_id)
ORDER BY upload_time DESC
LIMIT 10;

Niestety, zapytanie, choć faktycznie wyświetla ostatnio dodane pliki, niezupełnie robi to, czego oczekujemy – jeden użytkownik może wystąpić więcej niż raz na liście. Z pomocą przychodzi dodatkowy warunek, który wyeliminuje starsze wpisy dla tego samego użytkownika:

SELECT name, path, upload_time
FROM test_user u JOIN test_upload l ON (u.user_id = l.user_id)
WHERE upload_time =
   (SELECT max(upload_time) FROM test_upload WHERE user_id = u.user_id)
ORDER BY upload_time DESC
LIMIT 10;

Teraz zapytanie już działa poprawnie, ale w zależności od systemu baz danych, na którym pracujemy, mogliśmy wprowadzić inny poważny problem: zapytanie będzie się wykonywać dużo wolniej. Na naszym systemie testowym opartym o PostgreSQL 8.2 pierwsza (niepoprawna) wersja wykonywała się 200 ms. Tymczasem wersja “poprawiona”, wykonywała się nieco ponad 10 minut, czyli ok. 3 tys. razy wolniej. Przyczynę tej powolności pokazuje wynik EXPLAIN:

                                                                QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------------------------------
 Limit  (cost=50967080.34..50967080.36 rows=10 width=40) (actual time=617733.543..617733.554 rows=10 loops=1)
   ->  Sort  (cost=50967080.34..50967080.52 rows=75 width=40) (actual time=617733.542..617733.548 rows=10 loops=1)
         Sort Key: l.upload_date
         ->  Nested Loop  (cost=0.00..50967078.00 rows=75 width=40) (actual time=16.545..617691.016 rows=9967 loops=1)
               Join Filter: (l.upload_date = (subplan))
               ->  Seq Scan on test_upload l  (cost=0.00..894.00 rows=50000 width=28) (actual time=0.012..41.359 rows=50000 loops=1)
               ->  Index Scan using test_user_pkey on test_user u  (cost=0.00..0.28 rows=1 width=20) (actual time=0.009..0.011 rows=1 loops=50000)
                     Index Cond: (u.user_id = l.user_id)
               SubPlan
                 ->  Aggregate  (cost=1019.02..1019.03 rows=1 width=4) (actual time=12.333..12.333 rows=1 loops=50000)
                       ->  Seq Scan on test_upload  (cost=0.00..1019.00 rows=6 width=4) (actual time=1.967..12.323 rows=6 loops=50000)
                             Filter: (user_id = $0)
 Total runtime: 617733.733 ms

Po pierwsze, podzapytanie jest wykonywane dosyć nieoptymalnie – skanowana jest cała tabela, aby znaleźć pliki jednego użytkownika. Po drugie, podzapytanie jest wykonywane 50000 razy, raz na każdy rekord analizowany w głównym zapytaniu. Z pierwszym problemem można sobie poradzić przez dodanie odpowiedniego indeksu:

CREATE INDEX upload_user_id_idx ON test_upload(user_id);

Ta prosta zmiana spowodowała, że czas zapytania skrócił się do ok 0,6 sekundy:

                                                                          QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------------------------------------------------
 Limit  (cost=422099.29..422099.31 rows=10 width=40) (actual time=614.207..614.214 rows=10 loops=1)
   ->  Sort  (cost=422099.29..422099.47 rows=74 width=40) (actual time=614.205..614.208 rows=10 loops=1)
         Sort Key: l.upload_time
         ->  Merge Join  (cost=0.00..422096.99 rows=74 width=40) (actual time=0.071..602.762 rows=9967 loops=1)
               Merge Cond: (u.user_id = l.user_id)
               Join Filter: (l.upload_time = (subplan))
               ->  Index Scan using test_user_pkey on test_user u  (cost=0.00..378.25 rows=10000 width=20) (actual time=0.021..5.243 rows=10000 loops=1)
               ->  Index Scan using upload_user_id_idx on test_upload l  (cost=0.00..1595.25 rows=50000 width=28) (actual time=0.014..24.648 rows=50000 loops=1)
               SubPlan
                 ->  Aggregate  (cost=8.38..8.39 rows=1 width=4) (actual time=0.009..0.009 rows=1 loops=50000)
                       ->  Index Scan using upload_user_id_idx on test_upload  (cost=0.00..8.36 rows=6 width=4) (actual time=0.003..0.006 rows=6 loops=50000)
                             Index Cond: (user_id = $0)
 Total runtime: 614.338 ms

W tym artykule jednak chcieliśmy przedstawić inną technikę optymalizacji podzapytań: poprzez ich eliminację. Wiadomo, że podzapytanie, którego nie ma, nie potrzebuje czasu. Zależy nam jednak na tym, aby eliminując podzapytanie, całość była nadal poprawna, tj. zwracała właściwe wyniki, czyli musimy je czymś zastąpić. Kluczem do zastosowania tej techniki jest zamiana podzapytania na złączenie. Złączenia są łatwiejsze dla systemu do obliczenia chociażby z tego względu, że istnieją różne algorytmy realizacji złączeń i optymalizator ma tutaj większe “pole do popisu”. Poza tym hurtowy dostęp do dużej tabeli jest zwykle tańszy niż tysiące małych, prostych dostępów wybierających po kilka rekordów.

Wiele silników baz danych potrafi wykonać takie przekształcenie automatycznie dla podzapytań nieskorelowanych, jednak w tym przypadku mamy do czynienia z podzapytaniem skorelowanym, ponieważ odwołuje się ono do zapytania otaczającego. Komercyjne systemy baz danych poradziłyby sobie i z tym przypadkiem, ale jeśli nie mamy tego szczęścia ich używać, musimy poradzić sobie sami.

W pierwszej kolejności usuńmy niepotrzebny już indeks upload_user_id_idx. Następnie wykonajmy zapytanie:

SELECT user_id, max(upload_time)
FROM test_upload
GROUP BY user_id;

Wykonuje się jedynie 63 ms i zawiera wszystkie potrzebne dane do sprawdzenia, czy dany plik użytkownika jest tym “ostatnim” i powinien być uwzględniony w wyniku. Teraz tylko trzeba to zapytanie połączyć z pełną zawartością tabeli z użytkownikami i plikami, i na końcu odpowiednio posortować:

SELECT name, path, upload_time
FROM test_user u
  JOIN test_upload l ON (u.user_id = l.user_id)
  JOIN (
          SELECT user_id, max(upload_time) AS ud
          FROM test_upload
          GROUP BY user_id
       ) x
  ON (x.user_id = l.user_id AND l.upload_time = ud)
ORDER BY upload_time DESC
LIMIT 10;

Czas wykonania tego zapytania wyniósł 167 ms, czyli wyeliminowanie podzapytania zapewniło prawie 4-krotne przyspieszenie:

                                                                    QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------------------------------
 Limit  (cost=4324.97..4324.99 rows=10 width=40) (actual time=166.005..166.011 rows=10 loops=1)
   ->  Sort  (cost=4324.97..4325.13 rows=66 width=40) (actual time=166.003..166.004 rows=10 loops=1)
         Sort Key: l.upload_date
         ->  Hash Join  (cost=2053.31..4322.97 rows=66 width=40) (actual time=93.562..155.832 rows=9967 loops=1)
               Hash Cond: ((l.user_id = u.user_id) AND (l.upload_date = x.ud))
               ->  Seq Scan on test_upload l  (cost=0.00..894.00 rows=50000 width=28) (actual time=0.010..18.370 rows=50000 loops=1)
               ->  Hash  (cost=1920.04..1920.04 rows=8885 width=28) (actual time=93.524..93.524 rows=9922 loops=1)
                     ->  Hash Join  (cost=1498.00..1920.04 rows=8885 width=28) (actual time=68.164..86.451 rows=9922 loops=1)
                           Hash Cond: (x.user_id = u.user_id)
                           ->  HashAggregate  (cost=1144.00..1255.06 rows=8885 width=8) (actual time=52.218..57.378 rows=9922 loops=1)
                                 ->  Seq Scan on test_upload  (cost=0.00..894.00 rows=50000 width=8) (actual time=0.008..18.568 rows=50000 loops=1)
                           ->  Hash  (cost=229.00..229.00 rows=10000 width=20) (actual time=15.925..15.925 rows=10000 loops=1)
                                 ->  Seq Scan on test_user u  (cost=0.00..229.00 rows=10000 width=20) (actual time=0.007..5.835 rows=10000 loops=1)
 Total runtime: 166.287 ms

Testy przeprowadziliśmy na małym zbiorze danych, który całkowicie mieścił się w pamięci. Co się stanie jednak, jeśli zwiększymy ilość danych? Aby to sprawdzić, wygenerowaliśmy drugi, duży zbiór danych tak, by tabela użytkowników zawierała 500 tys. rekordów, a tabela z dodanymi plikami – 10 mln. Tym razem wersja z podzapytaniem wykorzystującym indeks na test_upload(user_id) wykonywała się ponad 30 minut i musieliśmy przerwać test. Natomiast wersja bez podzapytania skorelowanego zajęła 44 sekundy. Z kolei stosunek kosztów obu zapytań oszacowany przez optymalizator PostgreSQL wyniósł ok. 1600:1. Różnice są dlatego tak znaczne, że tym razem dane nie mieszczą się w całości w pamięci i każdorazowe wykonanie podzapytania wymagało fizycznego dostępu do przypadkowego miejsca dysku. Tymczasem w drugim przypadku rekordy są pobierane sekwencyjnie i nie traci się czasu na pozycjonowanie głowic dysku. Wersji z podzapytaniem bez indeksu nie sprawdzaliśmy na tym zbiorze danych. Gdybyśmy to zrobili, prawdopodobnie datę publikacji tego artykułu należałoby przesunąć o rok.

Jak widać, użycie złączenia i podzapytania nieskorelowanego we FROM zamiast podzapytania skorelowanego w WHERE może zapewnić duże zyski wydajności. Należy jednak pamiętać też o zagrożeniach jakie niesie ta technika. Przede wszystkim zmieniając postać zapytania, ryzykujemy, że nowe zapytanie nie będzie równoważne oryginałowi. W wielu przypadkach zamiana może wydawać się mechaniczna, ale należy bardzo uważać, żeby dodając kolejne złączenie nie wprowadzić duplikatów rekordów. Złączenia, w przeciwieństwie do zastosowania operatorów EXISTS, IN czy ‘=’ w sekcji WHERE, mogą nie tylko eliminować rekordy, ale również je powielać. Problem ten rozwiązuje się zwykle przez upewnienie się, że nigdy nie zostanie dołączony więcej niż jeden rekord (w naszym przypadku poprzez proste spostrzeżenie, że user_id jest unikalne), albo przez dodanie słowa DISTINCT, tak aby ewentualne duplikaty usunąć na końcu. Drugim zagrożeniem jest próba stosowania tej techniki zawsze i wszędzie, gdzie się tylko da. A niestety nie zawsze daje ona zyski w wydajności. Prezentowane zapytanie udało się nam przyspieszyć do 0,4 ms na małym zbiorze danych i 1 s na zbiorze dużym. Jak? To już temat na osobny artykuł.

]]> http://blog.sages.com.pl/2010/03/optymalizacja-zapytan-z-podzapytaniami/feed/ 0 http://blog.sages.com.pl/2010/03/witamy-na-naszym-blogu/ http://blog.sages.com.pl/2010/03/witamy-na-naszym-blogu/#comments Mon, 01 Mar 2010 11:38:35 +0000 Team Sages http://blog.sages.com.pl/?p=14 Serdecznie witamy na blogu konsultantów firmy Sages. Od dzisiaj rozpoczynamy publikację artykułów, przygotowanych przez naszych specjalistów, w których postaramy się przedstawić rozwiązania problemów, na jakie często natrafiamy w czasie naszej pracy, wskazać ciekawe zastosowania i integracje istniejących technologii, a także zaprezentować pomysły, który dopiero w przyszłości mogą potencjalnie stać się codziennie wykorzystywanymi narzędziami.

Liczymy na odzew i zapraszamy do regularnej lektury!

]]> http://blog.sages.com.pl/2010/03/witamy-na-naszym-blogu/feed/ 1