2013-05-14 13 views
5

Pracuję nad aplikacją, która używa zmiennej Session, aby śledzić użytkowników, sprawdzając na stronie wzorcowej jej istnienie, w przeciwnym razie powala ich na logowanie. Chciałem to zmienić na Uwierzytelnianie formularza, ponieważ przeczytałem, że jest bezpieczniejszy, a dane są zaszyfrowane.co chroni uwierzytelnianie formularzy, w przeciwieństwie do używania zmiennej sesji

Czy ktoś może mi powiedzieć, jakie dane są rzeczywiście zaszyfrowane? Próbowałem skonfigurować uwierzytelnianie formularzy w mojej witrynie, działa dobrze, użytkownicy są odpowiednio śledzeni i nie mają dostępu do stron bez logowania. Jednak, gdy patrzę na treść żądania, używając Fiddlera, widzę wszystkie pola formularzy i tam zadowolony. Czy haker nie może tego użyć do zmiany danych i ponownego przesłania żądania, tak jak w przypadku pliku cookie generowanego ze zmiennej sesji? Ta aplikacja nie używa SSL, więc rozumiem, że SSL zaszyfruje ciało, ale pomyślałem, że to samo będzie robić uwierzytelnianie formularzy. W przeciwnym razie, co jest szyfrowane, tylko identyfikator sesji w pliku cookie?

Oto kod używałem:

<authentication mode="Forms"> 
    <forms loginUrl="default.aspx" name=".ASPXFORMSAUTH_Test" defaultUrl="home.aspx" protection="All"/> 
</authentication> 
<authorization> 
    <deny users="?"/> 
</authorization> 

na stronie logowania próbowałem ręcznie utworzyć plik cookie:

    FormsAuthenticationTicket ticket = new FormsAuthenticationTicket(1, 
        txtEmail.Text, 
        DateTime.Now, 
        DateTime.Now.AddMinutes(30), 
        false, 
        txtEmail.Text, 
        FormsAuthentication.FormsCookiePath); 

       // Encrypt the ticket. 
       string encTicket = FormsAuthentication.Encrypt(ticket); 

       // Create the cookie. 
       Response.Cookies.Add(new HttpCookie(FormsAuthentication.FormsCookieName, encTicket)); 

       // Redirect back to original URL. 
       Response.Redirect(FormsAuthentication.GetRedirectUrl(txtEmail.Text, false)); 

ja też próbowałem:

FormsAuthentication.RedirectFromLoginPage(txtEmail.Text, false); 

earler, ma takie same wyniki, treść zapytania w skrzypce pokazuje wszystkie pola i ich zawartość.

+1

Brak odpowiedzi na twoje pytanie (domyślam się, że wartość cookie zawiera pewne informacje hashowe, ale nie jestem pewien.). W każdym razie nie powinieneś ręcznie ustawiać ciasteczka. Powinieneś polegać na FormsAuthentication.SetAuthCookie. Niektóre szczegóły tutaj: http://stackoverflow.com/a/15199149/1236044 – jbl

Odpowiedz

1

Nie należy podawać poświadczeń użytkownika ani innych poufnych danych bez SSL.

Niezależnie od tego, czy korzystasz z protokołu SSL, dane są zawsze widoczne od klienta i zawsze mogą być "sfałszowane". SSL (jeśli jest używany prawidłowo) może chronić przed "człowiekiem pośrodku" wsłuchując się w komunikację, ale ważne jest, aby zdać sobie sprawę, że jest prawie całkowicie bezużyteczny, jeśli nie jest rygorystycznie zaimplementowany, dlatego też powinieneś rozważyć użycie Strict Transport Security, nawet jeśli nie jest obsługiwany przez wszystkie przeglądarki.

Identyfikator sesji nie jest "szyfrowany", ale identyfikator sesji (w praktyce) nie może zostać "odgadnięty".HTTP (S) jest bezpaństwowcem i nie ma możliwości ustalenia, czy żądanie od określonego klienta samo w sobie jest szkodliwe, czy nie. Każde żądanie będzie zawierało wszystkie pliki cookie od klienta, zaszyfrowane lub nie (oczywiście, jeśli dane w pliku cookie są zaszyfrowane, trudno udowodnić jego zawartość).

Co można i należy zrobić, to próbować chronić pliki cookie przed utratą ich właściwego kontekstu, podlegając np. Ataki XSS i CSRF. FormsAuthentication używa domyślnie tylko protokołu HTTP dla plików cookie. Aby zapewnić cookies na swojej sieci są HTTP tylko, umieścić następujące w Twojej web.config:

<httpCookies httpOnlyCookies="true" /> 

aby wszystkie pliki cookie są zobowiązane do bezpieczne połączenie, przeznaczenie:

<httpCookies requireSSL="true" /> 

Teraz Głównym powodem, dla którego powinieneś używać uwierzytelniania za pomocą formularzy, jest to, że jest to sprawdzone rozwiązanie. Złamane uwierzytelnianie i zarządzanie sesją nie ma 2 na OWASP Top 10, po prostu dlatego, że jest trudniejsze, niż myślisz, aby to naprawić.

Uwierzytelnianie za pomocą formularzy dodatkowo zwiększa możliwość konfiguracji i prawidłowe szyfrowanie poświadczeń użytkownika w magazynie (jeśli zostanie to powiedziane). Standardowe implementacje w żaden sposób nie są odporne na kulę w świetle nowoczesnych możliwości opartych na procesorze GPU, ale przynajmniej nie jest to złe.

Jeśli chcesz dowiedzieć się więcej o tym, jak standardowe wdrożenie dotyczy jego działalności, możesz skorzystać z dowolnego z dostępnych dekompilatorów.

+0

Kiedy mówisz, że opublikowane dane są zawsze widoczne od klienta, masz na myśli, że jeśli używam lub nie używam SSL, skrzypek uruchomiony na moim komputerze zawsze pokaże mi niezaszyfrowaną treść żądania. Jednakże, gdyby ktoś zainstalował skrzypka na serwerze, który trafiłbym z mojej przeglądarki, bez SSL zobaczyłby moją treść zapytania, ale z SSL, czy byłby zaszyfrowany? – Paritosh

+0

To jest teoria, tak. W praktyce "bezpieczne" połączenie może nadal być zagrożone, podobnie jak w przypadku CRIME, BEAST lub Lucky 13. SSL nie jest jednolitym standardem w tym sensie, że kompresja i inne modyfikacje mogą być stosowane, a z kolei wykorzystywane, gdy ujawnione zostaną usterki. Jest to jeden z wielu interesujących i dość aktualnych artykułów na ten temat: http://arstechnica.com/security/2013/03/new-attacks-on-ssl-decrypt-authentication-cookies/. Jak zawsze, bezpieczeństwo polega na zmniejszaniu ryzyka i ograniczaniu tego, co musimy zrobić - prawdopodobnie nie zobaczymy "bezpiecznej" sieci w najbliższym czasie, z wyjątkiem względnego znaczenia. –

+0

Widzę, że mogłem źle odczytać twój komentarz, więc dla jasności - "teoria", jak to ujęłam, jest taka, że ​​jeśli ruch jest zabezpieczony za pomocą SSL, nie powinno być możliwe podsłuchiwanie. Na marginesie, dzięki cyfrowemu podpisowi możliwe jest upewnienie się, że żadne dane (zaszyfrowane lub niezaszyfrowane) nie zostały zmienione po drodze między nadawcą a odbiorcą. –

1

Uwierzytelnianie za pomocą formularzy używa obiektu FormsAuthentication do ustawienia pliku cookie dla użytkownika. Plik cookie zawiera informacje identyfikujące użytkownika. Nie jestem pewien, czy ten plik cookie jest tylko HTTP, ponieważ pliki cookie typu "tylko HTTP" są dostępne tylko na serwerze, a nie na kliencie. Te pliki cookie są odszyfrowywane na serwerze, pobierają identyfikator użytkownika, itp.

Więc jeśli to nie jest plik cookie wyłącznie dla protokołu HTTP, może to stanowić problem, z wyjątkiem informacji zaszyfrowanych, więc użytkownik musiałby odszyfruj i poznaj klucz podstawowy. Sesja Myślę, że tylko identyfikator sesji był bezpiecznie śledzony, a nie faktyczne informacje. Informacje użytkownika są nadal przechowywane na serwerze.

Wreszcie, pierwszą i najważniejszą obroną, o której ludzie wspominali w dzisiejszych czasach, jest SSL. Możesz uzyskać certyfikaty za tak tanie jak 10 USD z tego, co znalazłem ...

+0

Kiedy patrzę cookie w Skrzypek, widzę, że zawiera to: .ASPXFORMSAUTH_Test = BE08825FDBCD2B2679CDBA0095CCECXBE5117A7BC81022C5C142870B6576B943C4984F362318D5121FB28F644AE9B7EDC957F537AB83A839BA0511BB068AFFE067175A9D538F7B3C96DE8E22F0A3D8B4A6DB631298DD26607D8A72B1081979BBAB02D8CE8908C88A9CDE8EB8C26F709EAF7B376C59DBA227467C974CDDC634K6 że zgaduję jest zaszyfrowane dane, czy wiesz co to jest, to po prostu SessionID? Organ wnioskujący nadal widzę otwarty w Skrzypku, ale wygląda na to, że jest to ViewState, zgadując jedyny sposób, aby chronić to przez SSL. – Paritosh

+1

To jest zaszyfrowane dane. Uwaga Uwierzytelnianie formularzy nie ma nic wspólnego z identyfikatorem sesji, więc SessionID nie odtwarza go. Aplikacja Viewstate jest również zaszyfrowana według jej natury. Szyfrowanie nie jest w 100% doskonałe, ale bardzo, bardzo trudne do złamania, i prawdopodobnie może zostać złamane tylko przez niewielką część populacji, która jest bardzo uzdolniona i gotowa poświęcić dużo czasu na jej złamanie. Częściej, ktoś może spróbować ataku brute force lub ataku powtórki. –

2

Zmiana podejścia do Uwierzytelniania za pomocą formularzy nie zwiększy bezpieczeństwa. Będzie to oznaczać, że będziesz używać bardziej znormalizowanego mechanizmu uwierzytelniania, aby łatwiej było kontrolować twoje oprogramowanie pod kątem problemów związanych z uwierzytelnianiem.

Także uwierzytelnianie formularzy jest w stanie działać nawet po wygaśnięciu sesji dla użytkownika (lub rekompensowaniu puli aplikacji), ponieważ przechowuje dane użytkownika w zaszyfrowanym pliku cookie z własną polityką wygaśnięcia.

Powiązane problemy