https://archive.mroczna-zaloga.org/ Paweł Goleń, blog - Zrzędzenie starego zgreda pl Serendipity - http://www.s9y.org/ Sat, 15 Mar 2025 22:14:17 GMT https://archive.mroczna-zaloga.org/templates/bulletproof/img/s9y_banner_small.png https://archive.mroczna-zaloga.org/ 100 21 https://archive.mroczna-zaloga.org/archives/767-bootcamp-xvii-wyjasnienie-zadania-czesc-pierwsza.html#c2168 https://archive.mroczna-zaloga.org/archives/767-bootcamp-xvii-wyjasnienie-zadania-czesc-pierwsza.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=767 nospam@example.com (Paweł Goleń) Szczerze mówiąc ciekawy jestem co zostanie pokazane. Szczególnie w przypadku ASP.NET, bo domyślne zastosowanie HMAC powinno ograniczać możliwości modyfikacji ViewState (podmianę pomijam). Znanym potencjalnym problemem jest natomiast ujawnianie informacji. Ciekawsze są te przypadki, w których ViewState nie jest chroniony przed modyfikacją. Tue, 02 Feb 2010 07:58:35 +0100 https://archive.mroczna-zaloga.org/archives/767-guid.html#c2168 https://archive.mroczna-zaloga.org/archives/767-bootcamp-xvii-wyjasnienie-zadania-czesc-pierwsza.html#c2167 https://archive.mroczna-zaloga.org/archives/767-bootcamp-xvii-wyjasnienie-zadania-czesc-pierwsza.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=767 nospam@example.com (Krzysztof Kotowicz) Sprawa ViewState odżyla - za parę dni na Black Hat DC mają opublikować toola do wyłuskiwania danych z niezaszyfrowanego ViewState'a - http://www.darkreading.com/vulnerability_management/security/vulnerabilities/showArticle.jhtml?articleID=222600302&cid=RSSfeed . Pomijając naciągane tezy ("This is the first time a vulnerability of this nature has been discovered") zaczyna mnie zastanawiać - przecież tego typu rozwiązanie aż kłuje w oczy w momencie jego implementacji. Czy tylko garstka ludzi "zorientowanych na bezpieczeństwo" w ogóle widzi taką podatność, a inni mają w tym względzie "kurzą ślepotę", czy po prostu nikt się tym nie przejmuje, bo trzeba np. oddać projekt na czas i naładować go funkcjonalnościami z umowy? Tue, 02 Feb 2010 01:29:42 +0100 https://archive.mroczna-zaloga.org/archives/767-guid.html#c2167 https://archive.mroczna-zaloga.org/archives/767-bootcamp-xvii-wyjasnienie-zadania-czesc-pierwsza.html#c1807 https://archive.mroczna-zaloga.org/archives/767-bootcamp-xvii-wyjasnienie-zadania-czesc-pierwsza.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=767 nospam@example.com (Paweł Goleń) W JSF jest również ViewState i właśnie w tej "gorszej" wersji, niezabezpieczonej. W ASP.NET domyślnie jest włączony HMAC. Co prawda (znów - domyślnie) to ViewState nie zastępuje całkiem mechanizmu sesji, ale oczywiście można to użyć "źle", ładując tam wszystko, co popadnie. 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. Wed, 25 Nov 2009 20:35:24 +0100 https://archive.mroczna-zaloga.org/archives/767-guid.html#c1807 https://archive.mroczna-zaloga.org/archives/767-bootcamp-xvii-wyjasnienie-zadania-czesc-pierwsza.html#c1806 https://archive.mroczna-zaloga.org/archives/767-bootcamp-xvii-wyjasnienie-zadania-czesc-pierwsza.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=767 nospam@example.com (kravietz) Czy ktoś zna może jakiś racjonalny powód dla którego takie zmienne trzyma się po stronie klienta? Dokładnie w ten sposób działa przecież ViewState, ale widziałem to też w jakichś frameworkach dla Javy. Jedyne co mi przychodzi do głowy to odciążenie serwera od przechowywania tych danych, ale i tak jest to argument dość wiotki ze względu na czas wkładany w kodowanie i dekodowanie tych danych, oraz na zwiększenie transferu danych od/do klienta. Wed, 25 Nov 2009 20:22:48 +0100 https://archive.mroczna-zaloga.org/archives/767-guid.html#c1806