Paweł Goleń, blog - Formularz komentarzy "Znajdź błąd projektowy: wykorzystanie AJAX (część I)"

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

nospam@example.com (Tomek) — Fri, 21 Aug 2009 00:54:44 +0200

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. (...)

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

nospam@example.com (Paweł Goleń) — Thu, 20 Aug 2009 15:07:24 +0200

Masz rację, choć bardziej chodziło mi na pokazaniu pewnej architektury (często stosowanego "wzorca") przy kompletnym oderwaniu od tego, co ona robi.

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

nospam@example.com (kravietz) — Thu, 20 Aug 2009 14:27:16 +0200

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.

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

nospam@example.com (Paweł Goleń) — Wed, 19 Aug 2009 21:36:50 +0200

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ę.

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

nospam@example.com (Tomek) — Wed, 19 Aug 2009 21:23:09 +0200

Nudził będę ... tutaj rozwiązaniem byłoby przedstawienie przez klienta względem aplikacji jak i webservice tokenu uzyskanego od IP ... :)

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

nospam@example.com (Tomek) — Wed, 19 Aug 2009 21:21:25 +0200

(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 ...

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

nospam@example.com (kravietz) — Wed, 19 Aug 2009 21:12:27 +0200

Że webservice gada z klientem nie sprawdziwszy, czy najprzód rozmawiał on z aplikacją, a przynajmniej nic o tym nie wspomniano?

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

nospam@example.com (Paweł Goleń) — Wed, 19 Aug 2009 19:43:29 +0200

Nie :)

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

nospam@example.com (Marcin Gryszkalis) — Wed, 19 Aug 2009 17:54:18 +0200

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?