Mam stronę z prywatnymi właściwościami, które przechowują obiekt z kartą kredytową i obiekt koszyka na zakupy w stanie podglądu, więc mogę zachować odniesienie do nich poprzez posty zwrotne. Nawiasem mówiąc, strona zaangażowana będzie używać SSL.Czy przechowywanie informacji o kartach kredytowych i cenach w usłudze ViewState jest bezpieczne nawet w przypadku usługi ssl?
Czy to jest bezpieczne?
Nie przechowywałbym poufnych informacji w widoku ... kiedykolwiek. W ten sposób przekazujesz bezpieczeństwo implementacji przeglądarki w celu ochrony danych klientów. Luki w zabezpieczeniach, takie jak ataki typu cross-site scripting (XSS), ataki z przekierowaniem adresów URL itd. Mogą narazić te poufne dane na włamania, kradzieże lub fałszowanie.
Jeśli przechowujesz takie informacje w postbackach, powinieneś ponownie ocenić swój projekt i znaleźć sposób, aby tego uniknąć.
Zgadzam się z Twoją odpowiedzią, ale mógłbym wskazać, czy poprawnie zaszyfrujesz swoje poufne dane (np. Informacje CC) i wepchnij go do stanu oglądania, jesteś bezpieczny od nadużyć. Nie zaszkodzi by czasami zmieniać klucz szyfrujący co kilka miesięcy, na wypadek, gdyby ktoś próbował brutalnie włamać się do twojego szyfrowania (im więcej zaszyfrowanych danych zobaczy, w końcu mogą uzyskać klucz szyfrujący). – TravisO
Powiedziałbym zdecydowanie, że nie, jeśli chcesz przechowywać dane karty kredytowej w wielu żądaniach HTTP, prawdopodobnie będę musiał ponownie przemyśleć twoją architekturę.
Mam nadzieję, że to pomoże.
Viewstate jest hackable. Jeśli chcesz przechowywać te informacje w postbackach, zajrzyj do przechowywania ich w zaszyfrowanej bazie danych.
Q10. Czy usługa ViewState jest domyślnie bezpieczna? Czy można go zabezpieczyć? W jaki sposób?
Domyślnie wartość pola ukrytego formularza __VIEWSTATE jest zakodowana w Base64 i nie jest szyfrowana. Dlatego domyślnie dane w ViewState nie są bezpieczne.
Tak, dane w obiekcie ViewState można zabezpieczyć. Są dwie rzeczy, które można zrobić. Pierwszym z nich jest użycie SSL. Drugim jest zapewnienie, że EnableViewStateMac ma wartość true. Zapewni to, że ViewState zostanie zaszyfrowane, a także sprawdzone przed manipulowaniem. Domyślnym algorytmem szyfrowania jest SHA1, ale w razie potrzeby można go zmienić na MD5 lub 3DES. To powiedziawszy, należy pamiętać, że prawie zawsze istnieje kompromis między zwiększonym bezpieczeństwem a wydajnością. Najlepiej unikać zapisywania poufnych danych w ViewState i ponosić kary za wydajność, ze względu na potrzebę zwiększenia bezpieczeństwa.
Pamiętaj, że wszystko zawarte w ViewState jest dostarczana do przeglądarki klienta (po prostu przechowywane w ukrytym wejściem) i jest przekazywana z powrotem iz powrotem od klienta do serwera. Szyfrowanie i odszyfrowywanie danych może być ogromnym obciążeniem systemu.
Jak mogę to zhackować? Masz link? – EMP
domyślna stan widoku nie jest zaszyfrowany. Szyfrowanie dodaje znaczny narzut, a nawet nadal przekazuje wrażliwe dane karty kredytowej w obie strony pomiędzy klientem a serwerem. Nie powiedziałem, że stan oglądania jest niepewny, powiedziałem, że jest włamywaczem ... co oznacza, że tak, może zostać zhakowany, jeśli nie zostaną wprowadzone właściwe środki bezpieczeństwa. Nie jest to skuteczny/skuteczny sposób wykonywania wymaganych zadań. –
To, że jest czytelny, nie oznacza, że można go hakować. Zawartość nie może zostać zmieniona, chyba że wyłączysz MAC, który jest domyślnie włączony. – blowdart
Wszystkie pozostałe odpowiedzi sugerują, że stan widoku jest całkowicie niepewny. Nie zgadzam się z tym.
Program ASP.NET może zaszyfrować stan widoku za pomocą klucza serwera. Jeśli to zrobisz, to w teorii powinno być wystarczająco bezpieczne. Powiedziawszy to, nadal go nie polecam. Ktoś inny nadejdzie pewnego dnia i wyłączy szyfrowanie "do celów testowych" lub ustawi słaby klucz, albo plik konfiguracyjny serwera zostanie w jakiś sposób naruszony i nagle twoje numery kart kredytowych są podatne na atak.
Tak, istnieje pewna miara bezpieczeństwa w stanie oglądania, ale wciąż istnieją lepsze sposoby na zrobienie tego.Nawet przechowywanie wrażliwych danych w sesji użytkownika byłoby o wiele lepsze i całkiem proste.
jakie inne odpowiedzi mówią, że jest "całkowicie niepewny"? –
OK, "sugeruj", a nie "mów". :) – EMP
Nie poleciłbym tego i naprawdę pomyślałbym nad moim projektem, gdybym do niego podbiegł. Ale jeśli chcesz to zrobić: przechowuj stan widoku na serwerze.
Przeczytaj to: http://aspguy.wordpress.com/2008/07/09/reducing-the-page-size-by-storing-viewstate-on-server/
kilka punktów
MSDN (Session vs ViewState) O ile dane ViewState jest kodowany i ewentualnie może być szyfrowane, dane są najbardziej bezpieczne, jeśli nigdy nie jest wysłane do klienta. Tak więc stan sesji jest bezpieczniejszą opcją. (Przechowywanie danych w bazie danych jest jeszcze bezpieczniejsze dzięki dodatkowym referencjom bazy danych. Możesz dodać SSL dla jeszcze lepszego zabezpieczenia łącza.) Ale jeśli masz wyświetlanyprywatnych danych w interfejsie użytkownika, prawdopodobnie ty "jest już dobrze z bezpieczeństwem samego łącza. W tym przypadku nie mniej niż bezpieczne, aby umieścić tę samą wartość w ViewState, jak również.
ViewState is Visible in Source: Choć swobodnie dostępne w ukrytym polu zwanym __VIEWSTATE informacje widok państwo nie jest jasne tekstu. Domyślnie kod uwierzytelniania specyficzny dla komputera jest obliczany na danych i dołączany do ciągu stanu widoku. Wynikowy tekst jest następnie kodowany tylko Base64, ale nie zaszyfrowany. Jednak jeśli poufność danych jest pożądana, to SSL jest jedynym rozwiązaniem, ponieważ chroni nie tylko stan widoku, ale także wszystkie dane, które docierają do i ze strony. Stan widoku dekodowania jest nadal możliwy, ale należy wykonać kilka kroków; nie tylko trzeba zdemontować kilka nieudokumentowanych i wewnętrznych struktur, ale musi również wystąpić szereg okoliczności. Ponadto należy wziąć pod uwagę, że uszkodzony stan widoku jest zwykle wykryty na serwerze i zgłoszony zostanie wyjątek zabezpieczeń . Wreszcie, i co najważniejsze, stan widoku zawiera danych, a nie kod. O ile nie zmniejszysz domyślnie domyślnych ustawień zabezpieczeń strony, haker nie będzie w stanie zmodyfikować stanu widoku. Jeśli jednak zmienisz domyślne ustawienia zabezpieczeń, powinieneś uważać na stan widoku. Haker może modyfikować dane reprezentujące stan strony. Nie jest to błąd jako taki i otwiera luki w atakach tylko wtedy, gdy podstawowe zasady sprawdzania poprawności danych i sprawdzania danych nie są egzekwowane. Ale rozumiesz, że jest to bardziej ogólny problem podczas pisania bezpiecznego kodu. Wewnętrzna implementacja stanu widoku jest dość złożona i na tyle warstwowa, aby zniechęcić do ataków. Szyfrowanie jest najważniejszym elementem ochrony informacji o stanie widoku. Aby uczynić stan widoku bezpieczniejszym, dyrektywa ASP.NET @Page obsługuje atrybut o nazwie EnableViewStateMac, którego jedynym celem jest wykrycie ewentualnej próby uszkodzenia oryginalnych danych.
Jeśli EnableViewStateMac ma wartość True, to po przesłaniu strony stanu zaszyfrowanego widoku jest algorytmicznie sprawdzana w celu sprawdzenia, czy nie została zmodyfikowana na kliencie. Efektem sieci jest to, że możesz odczytać zawartość stanu widoku, ale aby go zastąpić, potrzebujesz klucza szyfrowania, który znajduje się w LSA serwera WWW.
Nie polecam go. Nawet przy włączonych zabezpieczeniach, im więcej razy przekazujesz dane od klienta do serwera, tym większa szansa, że napastnik go złapie. – rossisdead
Dzięki za szybkie odpowiedzi.Nie czułem się też bezpiecznie. Zamiast trzymać dane karty, właśnie je teraz przetwarzam. Dzięki! – Mike
http://stackoverflow.com/questions/1049159/asp-net-1-1-viewstate-security – PRR