![]() |
![]() |
![]() ![]()
Post
#1
|
|
Grupa: Zarejestrowani Postów: 375 Pomógł: 20 Dołączył: 28.07.2006 Ostrzeżenie: (0%) ![]() ![]() |
Istnieją 2 metody zabezpieczeń przed CSRF, które chronią tylko częściowo:
Skuteczniejsze metody:
Jakie jeszcze znacie skuteczne sposoby zabezpieczeń? Chcę zastosować takie zabezpieczenia, aby w jak najmniejszym stopniu utrudnić korzystanie z serwisu. Rozważmy jednorazowy klucz. Standardowa implementacja wygląda tak:
Osoba pisze jednocześnie 2 posty. Kiedy wyśle drugi, zobaczy komunikat "Wyślij formularz ponownie". Przyczyna: w sesji zapisujemy klucz pod identyczną nazwą. Innym razem pisze długi post. Znowu do samo. Przyczyna: Sesja wygasa po 20 minutach (można zwiększyć, tylko niezalecane). Rozważmy ponowne logowanie przy wejściu do panelu admina. Redaktor pisze długi artykuł. Zapisuje. Niestety, sesja wygasła. Musi zalogować się ponownie. Artykuł znika. Zamiast sesji można wykorzystać ciasteczka. Dopóki nie zamknie przeglądarki, nie zostanie wylogowany. Jak nie popełnić błędu? Wystarczy zapisać md5(hasło + coś tam)? Jak projektować zabezpieczenia, aby nie utrudniać życia użytkownikom? Ten post edytował WebCM 18.03.2012, 16:41:44 |
|
|
![]() |
![]()
Post
#2
|
|
Grupa: Zarejestrowani Postów: 2 291 Pomógł: 156 Dołączył: 23.09.2007 Skąd: ITALY-MILAN Ostrzeżenie: (10%) ![]() ![]() |
Cytat Dla mnie hash to hash (czysty bez dodatków, który przy ataku idzie jako drugi w kolejności). Gdybyś na początku zarzucił takim kodem to chyba oczywiste, że nie miał bym się o co czepiać. To sie nie zrozumielismy (IMG:style_emoticons/default/wink.gif) Cytat Jednak sprawdzanie przy każdym formularzu takiego hashu w bazie przy kilku tysiącach użytkowników JEST wciąż BARDZO zasobożerne w porównaniu do prostego jednokrotnego generowania keya na sesje... nawet więcej niż zasobożerne - jest to bardzo nie wydajne rozwiązanie. Hash sprawdzam tylko wtedy gdy sa odpalane jakies wazne akcje w systemie np zarzadzanie wpisami,panel admina czy usuwanie komentarzy, poprostu frontcontroller PA sprawdza przy jego odpaleniu hash, reszta frontcontrollerow i komponentow uwierzytelnia uzytkownika na podstawie ACL'a. Cytat Zakładając, że na stronie będzie sqlinfect i xss to oba sposoby są na tym samym poziomie bezpieczeństwa przed CSRF z różnicą wydajności. Dla uprzedzenia Twojej wypowiedzi dodam, że sqlinfecty są tak samo popularne jak xssy. Wiec jak zawsze trzeba "zakladac" jak najmniej i testowac wlasne strony ;p |
|
|
![]() ![]() |
![]() |
Aktualny czas: 8.10.2025 - 22:14 |