Przygotowałem pierwszą część wyjaśnienia zadania, dostępne jest ono tutaj. Jak do tej pory nadal tylko dwie osoby uporały się z zadaniem, nie widzę też by zadanie próbował rozwiązywać ktoś więcej, a szkoda. Głównym celem tego zadania jest ponowne pokazanie, że użytkownik może i będzie modyfikował dane, nad którymi ma kontrolę. Przykłady z ceną przekazywana w polach hidden są oklepane, dlatego w tym przypadku wykorzystałem przechowywanie stanu sesji po stronie klienta. Wybrałem ten przypadek, ponieważ niektóre frameworki pozwalają na przechowywanie całości lub części danych po stronie klienta, nie zawsze domyślnie właściwie chroniąc dane przechowywane w ten sposób. Czasami nie jest to istotne, a czasami wręcz przeciwnie...
Najnowsze wpisy
- Prosty przykład clickjacking
- wtorek, 31 sierpień 2010
- DLL Hijacking i CWDIllegalInDllSearch
- piątek, 27 sierpień 2010
- Skąd pochodzi podpisany kod
- czwartek, 26 sierpień 2010
- Memory leak. Znowu.
- środa, 25 sierpień 2010
- Jak korzystam z KeePass
- poniedziałek, 23 sierpień 2010
- Ciekawy przykład phishingu
- czwartek, 19 sierpień 2010
- SecDay 2010
- czwartek, 19 sierpień 2010
- Spójność rządzi
- wtorek, 17 sierpień 2010
- Gdy są fanty do wyjęcia, ktoś będzie chciał je mieć
- poniedziałek, 16 sierpień 2010
- Nokia E51+1
- czwartek, 12 sierpień 2010
Losowe wpisy
- Do zapisania w umowie: Application Security Verification Standards
- czwartek, 30 kwiecień 2009
- Gdyby głupota miała skrzydła...
- piątek, 2 maj 2008
- I po wyzwaniu...
- piątek, 22 sierpień 2008
- Bootcamp III: "kontrola dostępu" do funkcji - tekst
- czwartek, 9 kwiecień 2009
- Samo nie dzieje się nic
- sobota, 27 grudzień 2008
- Ale to właściwie o co chodzi
- niedziela, 18 maj 2008
- New, Improved Office Crypto
- piątek, 5 grudzień 2008
- Psychologia dla projektanta systemów informatycznych
- wtorek, 1 grudzień 2009
- Bootcamp III: "kontrola dostępu" do funkcji (tylko przykład na razie)
- środa, 8 kwiecień 2009
- Ten niewykrywalny wirus co o nim mówią
- wtorek, 17 luty 2009
Jeśli chodzi o powody korzystania z tego typu rozwiązań, to głównie spotykałem się z tłumaczeniem odnośnie wydajności właśnie, przy czym chodziło bardziej o pamięć - gdzieś te dane sesji muszą być trzymane. Tworząc wiele nowych sesji można przeprowadzić DoS i może być to łatwiejsze, niż ten sam DoS poprzez operację serializowania/deserializowania danych. Z drugiej strony rosną wówczas wymagania co do łącza.
Przychodzi mi do głowy jeszcze jedna zaleta trzymania sesji po stronie klienta - kompletna dowolność który serwer będzie obsługiwał klienta. Zwykle jest tak, że nawet jeśli jest jakiś klaster kilku serwerów jeden klient trafia do tego samego serwera, właśnie po to, by dane sesji były dostępne. Można to oczywiście rozwiązać inaczej (inny sposób składowania sesji po stronie "serwera"), ale może to być trochę skomplikowane i kosztowne. Przerzucenie utrzymywania stanu sesji na klienta może być wówczas uzasadnione, może go odtworzyć dowolny serwer.
Mimo wszystko jakoś trzymanie sesji po stronie klienta nie do końca do mnie przemawia.