Komentarze do: Bezpieczeństwo mechanizmu sesji http://www.beldzio.com/bezpieczenstwo-mechanizmu-sesji Bełdziowe spojrzenie na aplikacje internetowe Wed, 23 Nov 2011 11:05:26 +0000 hourly 1 http://wordpress.org/?v=3.1.1 Autor: Michał Ławicki http://www.beldzio.com/bezpieczenstwo-mechanizmu-sesji/comment-page-1#comment-1014 Michał Ławicki Fri, 25 Mar 2011 05:54:54 +0000 http://localhost/wordpress/?p=95#comment-1014 Wszystko zależy od serwisu i od podatności jakie przejawia. Na blogu jest kilka notek zahaczających o tematykę wgrywania swoich plików. Np. http://www.beldzio.com/obsluga-plikow-a-sql-injection http://www.beldzio.com/kategoria/bezpieczenstwo/upload-bezpieczenstwo Wszystko zależy od serwisu i od podatności jakie przejawia. Na blogu jest kilka notek zahaczających o tematykę wgrywania swoich plików. Np.

http://www.beldzio.com/obsluga-plikow-a-sql-injection
http://www.beldzio.com/kategoria/bezpieczenstwo/upload-bezpieczenstwo

]]> Autor: Adrian http://www.beldzio.com/bezpieczenstwo-mechanizmu-sesji/comment-page-1#comment-1013 Adrian Fri, 25 Mar 2011 01:46:46 +0000 http://localhost/wordpress/?p=95#comment-1013 No dobra wszystko jasne tylko mam pytanie jak osoba z poza mojego serweru nie mająca do niego dostępu może wykonać na nim plik php?(tak jestem laikiem:P) No dobra wszystko jasne tylko mam pytanie jak osoba z poza mojego serweru nie mająca do niego dostępu może wykonać na nim plik php?(tak jestem laikiem:P)

]]> Autor: mosh http://www.beldzio.com/bezpieczenstwo-mechanizmu-sesji/comment-page-1#comment-743 mosh Sat, 01 Aug 2009 17:05:44 +0000 http://localhost/wordpress/?p=95#comment-743 ciekawie napisane, spora dawka informacji w jednym miejscu właśnie walczę ze e-sklepem i już przed przeczytaniem artu wpadł mi do głowy podobny system zabezpieczenia (token) przed botami, pozdro! ciekawie napisane, spora dawka informacji w jednym miejscu
właśnie walczę ze e-sklepem i już przed przeczytaniem artu wpadł mi do głowy podobny system zabezpieczenia (token) przed botami, pozdro!

]]> Autor: BnG http://www.beldzio.com/bezpieczenstwo-mechanizmu-sesji/comment-page-1#comment-533 BnG Tue, 19 May 2009 13:25:40 +0000 http://localhost/wordpress/?p=95#comment-533 Artykuł dobry. Dzięki za podzielenie się wiedzą. Artykuł dobry. Dzięki za podzielenie się wiedzą.

]]> Autor: Strummer http://www.beldzio.com/bezpieczenstwo-mechanizmu-sesji/comment-page-1#comment-288 Strummer Tue, 11 Nov 2008 18:11:29 +0000 http://localhost/wordpress/?p=95#comment-288 Szukałem mechanizmu który 'na pierwszej stronie' generuje losowy id ale jest odporny na odświeżanie , coż znalazłem coś co mnie skłania do dalszych eksperymentów nad własnymi mechanizmami :) Trafiasz do Ulubionych :) pozdrawiam Szukałem mechanizmu który ‘na pierwszej stronie’ generuje losowy id ale jest odporny na odświeżanie , coż znalazłem coś co mnie skłania do dalszych eksperymentów nad własnymi
mechanizmami :) Trafiasz do Ulubionych :)

pozdrawiam

]]> Autor: Artur http://www.beldzio.com/bezpieczenstwo-mechanizmu-sesji/comment-page-1#comment-244 Artur Thu, 09 Oct 2008 15:57:47 +0000 http://localhost/wordpress/?p=95#comment-244 swietny artykul i bardzo fajna strona, pozdrawiam ! swietny artykul i bardzo fajna strona, pozdrawiam !

]]> Autor: Michał "Bełdzio" Ławicki http://www.beldzio.com/bezpieczenstwo-mechanizmu-sesji/comment-page-1#comment-134 Michał "Bełdzio" Ławicki Fri, 12 Oct 2007 14:41:24 +0000 http://localhost/wordpress/?p=95#comment-134 ad token: token nie jest generowany w każdym miejscu serwisu, a tylko na stronie kupna tak więc nie problemu z konfliktem tokenów ajax tu nic nie zdziała<br /><br />ad routing: to samo co wyżej token routingu generowany jest za każdym razem jak user wchodzi w sekcje kupna czyli token = 12345 może wskazywać na ten sam produkt co token = 09876<br /><br />ad ograniczenie dostępu: jakoś nie widzę możliwości ograniczenia możliwości kupna produktu userom w sklepie internetowym :-)<br /><br />to w kwestii programisty leży kwestia zapewnienia userwi bezpieczeństwa na stronie<br /><br />ad captcha: wyciągnięcie tokena z obrazków nie jest wcale takie trudne jak się wydaje, w necie jest pełno softu do tego. Captcha zapewnia tak długo bezpieczeństwo do póki nie powstanie dla niego OCR tak więc nie ma co liczyć na pełne bezpieczeństwo ad token: token nie jest generowany w każdym miejscu serwisu, a tylko na stronie kupna tak więc nie problemu z konfliktem tokenów ajax tu nic nie zdziała

ad routing: to samo co wyżej token routingu generowany jest za każdym razem jak user wchodzi w sekcje kupna czyli token = 12345 może wskazywać na ten sam produkt co token = 09876

ad ograniczenie dostępu: jakoś nie widzę możliwości ograniczenia możliwości kupna produktu userom w sklepie internetowym :-)

to w kwestii programisty leży kwestia zapewnienia userwi bezpieczeństwa na stronie

ad captcha: wyciągnięcie tokena z obrazków nie jest wcale takie trudne jak się wydaje, w necie jest pełno softu do tego. Captcha zapewnia tak długo bezpieczeństwo do póki nie powstanie dla niego OCR tak więc nie ma co liczyć na pełne bezpieczeństwo

]]> Autor: Aethan http://www.beldzio.com/bezpieczenstwo-mechanizmu-sesji/comment-page-1#comment-133 Aethan Fri, 12 Oct 2007 14:25:07 +0000 http://localhost/wordpress/?p=95#comment-133 Routing i tokeny chyba nie są dobrym mechanizmem obrony przed session riding. Zacznę od tokenów. Załóżmy, że użytkownik abuseowany jest zalogowany do aplikacji sklepu internetowego. Użytkownik wchodzi na stronę sklepu podmieniona przez złośliwego użytkownika lub administratora, lub nawet przez użytkownika forum z możliwością dodawania zewnętrznych plików. Strona zawiera znacznik <img src="http://aplikacja.atakujacego.org/atak-sr.php">. Wtedy URL zostaje odpalony i dostaje m.in plik Javascript zbudowany w technologii AJAX. Jeśli chronione są tylko niektóre strony czy formularze, wystarczy, żeby spreparowany GET w AJAX zaczynał od strony nie chronionej przez token, wtedy pobierze token dokładnie taki, jaki jest wymagany. Wtedy dla serwera sytuacja wygląda tak, jakby użytkownik miał otwarte dwie strony tego samego serwisu (np. newsy i forum). Z tych powodów niemożliwe jest odświeżanie tokena po każdym przejściu do kolejnej strony i jednocześnie akceptowanie tylko ostatniego tokena, bo w drugim oknie będzie wylogowany. Byłoby to trochę frustrujące, jeśli użytkownik rozmawia na chacie AJAXowym i jednocześnie pisze coś na forum i nagle z jednego go wyrzuca.<br /><br />To samo z routingiem. Musiałby powstać zaawansowany system śledzący kolejne przejścia użytkownika i rozgałęziające jego adresy. Szczerze powiedziawszy nie widzę takiego systemu - szczególnie w obliczu tzw. Web 2.0 - aplikacji zakładającej identyfikację i interakcję użytkownika.<br /><br />Moim zdaniem, system zabezpieczający wrażliwe części systemu przed session riding powinien zaczynać się od edukowania użytkowników i ograniczania im dostępu. Filtrowanie i przepisywanie znaczników też może mieć swoje efekty. Jednak najwrażliwsze części systemu powinny być zabezpieczone czymś, czego komputer nie potrafi odczytać (przynajmniej nie na tyle, żeby w miarę szybko odpowiedzieć) - czyli obrazkiem. Zabezpieczony i zamazany kod wyświetlony przez formularz potwierdzeniowy (sic!) musi być odczytany przez człowieka i człowiek musi podać jego zawartość. W ten sposób nie ma możliwości, aby bot zamówił nam niechciany komputer na przykład. Routing i tokeny chyba nie są dobrym mechanizmem obrony przed session riding. Zacznę od tokenów. Załóżmy, że użytkownik abuseowany jest zalogowany do aplikacji sklepu internetowego. Użytkownik wchodzi na stronę sklepu podmieniona przez złośliwego użytkownika lub administratora, lub nawet przez użytkownika forum z możliwością dodawania zewnętrznych plików. Strona zawiera znacznik <img src="http://aplikacja.atakujacego.org/atak-sr.php">. Wtedy URL zostaje odpalony i dostaje m.in plik Javascript zbudowany w technologii AJAX. Jeśli chronione są tylko niektóre strony czy formularze, wystarczy, żeby spreparowany GET w AJAX zaczynał od strony nie chronionej przez token, wtedy pobierze token dokładnie taki, jaki jest wymagany. Wtedy dla serwera sytuacja wygląda tak, jakby użytkownik miał otwarte dwie strony tego samego serwisu (np. newsy i forum). Z tych powodów niemożliwe jest odświeżanie tokena po każdym przejściu do kolejnej strony i jednocześnie akceptowanie tylko ostatniego tokena, bo w drugim oknie będzie wylogowany. Byłoby to trochę frustrujące, jeśli użytkownik rozmawia na chacie AJAXowym i jednocześnie pisze coś na forum i nagle z jednego go wyrzuca.

To samo z routingiem. Musiałby powstać zaawansowany system śledzący kolejne przejścia użytkownika i rozgałęziające jego adresy. Szczerze powiedziawszy nie widzę takiego systemu – szczególnie w obliczu tzw. Web 2.0 – aplikacji zakładającej identyfikację i interakcję użytkownika.

Moim zdaniem, system zabezpieczający wrażliwe części systemu przed session riding powinien zaczynać się od edukowania użytkowników i ograniczania im dostępu. Filtrowanie i przepisywanie znaczników też może mieć swoje efekty. Jednak najwrażliwsze części systemu powinny być zabezpieczone czymś, czego komputer nie potrafi odczytać (przynajmniej nie na tyle, żeby w miarę szybko odpowiedzieć) – czyli obrazkiem. Zabezpieczony i zamazany kod wyświetlony przez formularz potwierdzeniowy (sic!) musi być odczytany przez człowieka i człowiek musi podać jego zawartość. W ten sposób nie ma możliwości, aby bot zamówił nam niechciany komputer na przykład.

]]> Autor: Mario http://www.beldzio.com/bezpieczenstwo-mechanizmu-sesji/comment-page-1#comment-132 Mario Sun, 12 Aug 2007 17:43:54 +0000 http://localhost/wordpress/?p=95#comment-132 Musze tu częściej zaglądać :) Musze tu częściej zaglądać :)

]]> Autor: Michał `Bełdzio` Ławicki http://www.beldzio.com/bezpieczenstwo-mechanizmu-sesji/comment-page-1#comment-131 Michał `Bełdzio` Ławicki Sat, 11 Aug 2007 16:13:43 +0000 http://localhost/wordpress/?p=95#comment-131 Pod koniec arta masz szkielet klasy do obsługi sesji, wystarczy wypełnić metody kodem i już :-) Jeśli Ci to nie odpowiada to zapoznaj się z obsługą sesji z popularnych frameworków i dostosuj ich kod do swoich wymagań. Pod koniec arta masz szkielet klasy do obsługi sesji, wystarczy wypełnić metody kodem i już :-) Jeśli Ci to nie odpowiada to zapoznaj się z obsługą sesji z popularnych frameworków i dostosuj ich kod do swoich wymagań.

]]>