RSS

Paweł Goleń, blog

Zrzędzenie starego zgreda

Wednesday, August 19. 2009

Znajdź błąd projektowy: wykorzystanie AJAX (część I)

Nie przepadam za AJAX. Moja niechęć dotyczy nie tyle samej technologii, co jej nadużywania. Świat jednak idzie do przodu i trzeba pogodzić się z tym, że coraz więcej aplikacji z AJAX i podobnych technologii korzystać będzie. A czasami wykorzystanie nowej technologii niesie ze sobą nowe, lepsze błędy. Tym razem zaprezentuję prosty schemat dostępu do danych, który spotkałem w kilku implementacjach.

Schemat DFD i opis do niego

Na początek prosty diagram DFD:

Na diagramie tym istotne są data flow, w szczególności te, które nazwałem od DF1 do DF6 oraz trust boundary. Fakt umieszczenia na diagramie dwóch obiektów aplikacji (aplikacja i webservice) nie jest specjalnie istotny, równie dobrze mógłby być jeden obiekt tego typu. Diagram ten przedstawia następującą historię:

  1. W pierwszym kroku klient (użytkownik) otrzymuje formatkę, na której może określić dane wyszukiwania. To, co użytkownik może wybrać na formatce jest ograniczone jego uprawnieniami. W zależności od roli użytkownika, pewne opcje są lub nie są dostępne. Wypełniona formatka jest wysyłana do aplikacji w DF1. Ponieważ DF1 przekracza trust boundary (tampering!) przesłane przez użytkownika parametry są weryfikowane po stronie serwera.
  2. Jeśli użytkownik przysłał poprawne dane, serwer generuje "szablon" strony (bez danych), na której osadzone jest odpowiednie zapytanie AJAX, które ma pobrać odpowiednie dane i zaprezentować je użytkownikowi. Wszystko to jest przesyłane do klienta przez DF2.
  3. Po załadowaniu strony w przeglądarce, generuje ona żądanie (osadzony w kroku drugim kod) do WebService w celu pobrania danych. To, jaka funkcja jest wywoływana i z jakimi parametrami zależy od przesłanych w pierwszym kroku przez użytkownika parametrów. Wywołanie odbywa się w DF3.
  4. Na podstawie otrzymanego od klienta zapytania, WebService konstruuje zapytanie do DB i przesyła je z wykorzystaniem DF4.
  5. Odpowiedź jest odbierana przez WebService w DF5
  6. Klient otrzymuje dane, których parametry określił w kroku pierwszym przez DF6, dane wyświetlane są na stronie.

Pytanie: gdzie jest błąd?

Ślady
Znajdź błąd projektowy: wykorzystanie AJAX (część II) - rozwiązanie
Właściwie mógłbym nie pisać drugiej części do Znajdź błąd projektowy: wykorzystanie AJAX (część I), bo odpowiedź znalazła się w komentarzach. Mimo wszystko małe podsumowanie.Na czym polegał błąd w projekcie Problem, na który chciałem zwrócić uwagę związa
Weblog: Wampiryczny blog
Przesłany: Aug 24, 15:42
Piramida potrzeb
W psychologii istnieje pojęcie piramidy (hierarchii) potrzeb. Potrzeby wyższe aktywizują się dopiero po zaspokojeniu potrzeb niższych. Również w przypadku budowania aplikacji, (w)budowania bezpieczeństwa i jego testowania są rzeczy, które mają większy pri
Weblog: Wampiryczny blog
Przesłany: Nov 12, 17:43
Komentarze
Rozumiem, że pominięcie w opisie informacji o weryfikacji danych DF3 wynika z tego, że i tak na rysunku przekraczamy trust boundary co automatycznie implikuje istnienie takiej weryfikacji?
#1 Marcin Gryszkalis o 2009-08-19 17:54
Nie :-)
#1.1 Paweł Goleń o 2009-08-19 19:43
Że webservice gada z klientem nie sprawdziwszy, czy najprzód rozmawiał on z aplikacją, a przynajmniej nic o tym nie wspomniano?
#2 kravietz (Strona) o 2009-08-19 21:12
Nudził będę ... tutaj rozwiązaniem byłoby przedstawienie przez klienta względem aplikacji jak i webservice tokenu uzyskanego od IP ... :-)
#2.1 Tomek (Strona) o 2009-08-19 21:23
(1) Brak weryfikacji poprawności żądania przez WebService, (2) brak weryfikacji tego o co żąda użytkownik w odniesieniu do jego uprawnień w webservice (klient może wysłać tam co chce), (3)to na co zwrócił uwage Kravietz czyli brak potwierdzenia po stronie web service że klient najpierw korzystał z aplikacji i że to czego żąda to ma prawo żądać (poniekąd jak w 2).

Ale aplikacje i bezpieczeństwo to nie moja bajka ...
#3 Tomek (Strona) o 2009-08-19 21:21
Ale bardzo dobrze sobie poradziłeś. Problem, na który chciałem zwrócić uwagę, to właśnie brak sprawdzenia tego, co przychodzi w DF3. W pewnym uproszczeniu można przyjąć, że aplikacja przekazuje coś do WebService (to coś, to parametry wywołania funkcji, które określają zwracane dane) za pośrednictwem klienta, przy czym nie został rozwiązany problem ewentualnego tamperingu tych danych przez samego klienta.

Kravietz też słusznie prawi, przy czym bardziej chodziło mi o zawrócenie uwagi na to, co oznaczyłeś jako (2), czyli na fakt, że klient może wysłać do WS dowolne żądanie, które nie jest już przez WS sprawdzane odnośnie uprawnień użytkownika, bo istnieje nieuprawnione założenie, że klient wywoła WS tylko tak, jak mu Aplikacja pozwoli. A w rzeczywistości klient może wywołać WS jak chce, w szczególności kompletnie ignorując aplikację.
#3.1 Paweł Goleń o 2009-08-19 21:36
BTW warto byłoby dodać założenie, że WS operuje na danych wrażliwych bo mogłaby przecież zwracać jakieś dane jawne - np. aktualne kursy walut.
#3.1.1 kravietz (Strona) o 2009-08-20 14:27
Masz rację, choć bardziej chodziło mi na pokazaniu pewnej architektury (często stosowanego "wzorca") przy kompletnym oderwaniu od tego, co ona robi.
#3.1.1.1 Paweł Goleń o 2009-08-20 15:07
A tak już tylko w ramach dodatku, właśnie to przeczytałem w innym miejscu i jakoś mi się skojarzyło:

(...) A good programming philosophy is... if you don't completely control the information store, you can't completely trust the information store. (...)
#4 Tomek (Strona) o 2009-08-21 00:54