Ich habe eine Seite mit privaten Eigenschaften, die ein Kreditkartenobjekt und ein Einkaufswagenobjekt im Viewstate speichern, so dass ich einen Verweis auf sie über Postbacks beibehalten kann. Übrigens verwendet die betroffene Seite SSL.Ist es sicher, Kreditkarten- und Preisinformationen in ViewState auch über SSL zu speichern?
Ist das sicher?
Ich würde keine vertraulichen Informationen im Viewstate speichern ... überhaupt. Damit delegieren Sie die Sicherheit an die Implementierung des Browsers, um die Daten Ihrer Kunden zu schützen. Schwachstellen wie Cross-Site-Scripting (XSS), URL-Redirection-Attacken usw. können diese vertraulichen Daten einem Eindringen, Diebstahl oder Spoofing aussetzen.
Wenn Sie solche Details über Postbacks speichern, sollten Sie Ihr Design neu bewerten und einen Weg finden, dies zu vermeiden.
Ich stimme Ihrer Antwort zu, aber ich könnte darauf hinweisen, wenn Sie Ihre sensiblen Daten (z. B .: CC info) und Schieben Sie es in Sicht, Sie sind sicher vor Missbrauch. Es würde nicht schaden, den Verschlüsselungsschlüssel gelegentlich alle paar Monate zu ändern, falls jemand versucht, Ihre Verschlüsselung brutal zu erzwingen (je mehr verschlüsselte Daten sie sehen, schließlich können sie den Verschlüsselungsschlüssel erhalten). – TravisO
Ich würde definitiv nicht sagen, Wenn Sie Kreditkarteninformationen über mehrere HTTP-Anfragen speichern müssen, würde ich möglicherweise über Ihre Architektur neu denken.
Hoffe, das hilft.
Viewstate ist hackable. Wenn Sie diese Informationen über Postbacks speichern müssen, sollten Sie sie in einer verschlüsselten Datenbank speichern.
Q10. Ist ViewState standardmäßig sicher? Kann es gesichert werden? Wie?
Standardmäßig ist der Wert des ausgeblendeten Formularfelds __VIEWSTATE Base64-codiert und nicht verschlüsselt. Daher sind Daten in ViewState standardmäßig nicht sicher.
Ja, Daten im ViewState können gesichert werden. Es gibt zwei Dinge, die getan werden können. Die erste ist die Verwendung von SSL. Die zweite besteht darin sicherzustellen, dass EnableViewStateMac auf "true" gesetzt ist. Dies stellt sicher, dass der ViewState verschlüsselt und gegen Manipulationen geprüft wird. Der Standard-Verschlüsselungsalgorithmus ist SHA1, kann jedoch bei Bedarf auch in MD5 oder 3DES geändert werden. Vor diesem Hintergrund sollte man bedenken, dass es fast immer einen Kompromiss zwischen erhöhter Sicherheit und Leistung gibt. Es ist am besten, die Speicherung sensibler Daten in ViewState zu vermeiden und aufgrund der Notwendigkeit, die Sicherheit zu erhöhen, Leistungseinbußen zu erleiden.
Denken Sie daran, dass in der Viewstate enthalten alles, was an den Client-Browser geliefert werden (einfach in einem versteckten Eingang gespeichert) und wird hin und her vom Client an den Server übergeben. Das Verschlüsseln und Entschlüsseln von Daten kann einen enormen Systemaufwand verursachen.
Wie hack ich es? Hast du einen Link? – EMP
Ein Standard-Viewstate ist nicht verschlüsselt. Die Verschlüsselung erhöht den Overhead und überträgt vertrauliche Kreditkarteninformationen zwischen Client und Server. Ich habe nicht gesagt, ViewState ist unsicher, ich sagte, es ist hackable ... also ja, es kann gehackt werden, wenn keine geeigneten Sicherheitsmaßnahmen getroffen werden. Es ist keine effiziente/effektive Art, die erforderlichen Aufgaben auszuführen. –
Nur weil es lesbar ist, heißt das nicht, dass es hackbar ist. Der Inhalt kann nicht geändert werden, es sei denn, Sie haben den MAC deaktiviert, der standardmäßig aktiviert ist. – blowdart
Alle anderen Antworten scheinen zu implizieren, dass Viewstate völlig unsicher ist. Dem stimme ich nicht zu.
ASP.NET kann den Viewstatus mit dem Serverschlüssel verschlüsseln. Wenn Sie das tun, dann in der Theorie sollte es sicher genug sein. Trotzdem, ich empfehle es immer noch nicht. Jemand anderes wird eines Tages mitkommen und die Verschlüsselung "zu Testzwecken" deaktivieren oder einen schwachen Schlüssel setzen oder die Konfigurationsdatei des Servers wird irgendwie kompromittiert und plötzlich sind Ihre Kreditkartennummern anfällig.
Also ja, es gibt ein gewisses Maß an Sicherheit im Viewstate, aber es gibt immer noch bessere Möglichkeiten, dies zu tun.Selbst das Speichern sensibler Daten in der Benutzersitzung wäre viel besser und recht einfach.
Welche anderen Antworten sagen, dass es "völlig unsicher" ist? –
OK, "implizieren", nicht "sagen". :) – EMP
Ich würde es nicht empfehlen und wirklich über mein Design nachdenken, wenn ich hineingerannt bin. Aber wenn Sie es tun wollen: Speichern Sie den Viewstate auf dem Server.
Lesen Sie dazu: http://aspguy.wordpress.com/2008/07/09/reducing-the-page-size-by-storing-viewstate-on-server/
Nur wenige Punkte
MSDN: (Session vs Viewstate) Während die Viewstate Daten codiert und optional verschlüsselt werden können, sind Ihre Daten sichersten, wenn es nie ist an den Kunden gesendet. Daher ist der Sitzungsstatus eine sicherere Option. (Speichern der Daten in der Datenbank ist noch sicherer aufgrund der zusätzlichen Datenbank-Anmeldeinformationen. Sie können SSL für eine noch bessere Link-Sicherheit hinzufügen.) Aber wenn Sie dieprivate Daten in der Benutzeroberfläche angezeigt haben, vermutlich Sie bin schon mit der Sicherheit der Verbindung selbst vertraut. In diesem Fall ist es nicht weniger sicher, um den gleichen Wert in ViewState als auch zu setzen.
ViewState is Visible in Source: Obwohl in einem versteckten Bereich frei zugänglich ist __VIEWSTATE, die Blick Zustandsinformationen genannt nicht Klartext. Standardmäßig wird ein maschinenspezifischer Authentifizierungscode für die Daten berechnet und an die Anzeigestatuszeichenfolge angehängt. Der resultierende Text ist dann Base64 nur verschlüsselt, aber nicht verschlüsselt. Wenn jedoch Vertraulichkeit der Daten gewünscht ist, dann ist SSL die einzige Lösung, da es nicht nur den Ansichtszustand schützt, sondern auch alle Daten, die zu und von der Seite übertragen werden. Die Decodierung des Ansichtszustands ist weiterhin möglich, es müssen jedoch eine Reihe von Schritten durchgeführt werden. nicht nur müssen mehrere undokumentierte und interne Strukturen demontiert werden, sondern es müssen auch einige Umstände eintreten. Beachten Sie außerdem, dass auf dem Server normalerweise ein manipulierter Ansichtszustand erkannt wird und eine Sicherheitsausnahme ausgelöst wird. Schließlich und am wichtigsten von allem, enthält der Ansichtszustand Daten, nicht Code. Wenn Sie die Standardsicherheitseinstellungen für die Seite nicht explizit reduzieren, kann ein Hacker den Ansichtszustand nicht wesentlich ändern. Wenn Sie jedoch die Standardsicherheitseinstellungen ändern, sollten Sie beim Ansichtszustand vorsichtig sein. Ein Hacker könnte die Daten ändern, die den Zustand der Seite darstellen. Dies ist kein Fehler per se und öffnet nur dann Lücken für Angriffe, wenn die Grundregeln der Datenvalidierung und Datenprüfung nicht durchgesetzt werden. Aber das, Sie verstehen, ist ein allgemeineres Problem, wenn Sie versuchen, sicheren Code zu schreiben. Die interne Implementierung des Ansichtszustands ist ziemlich komplex und vielschichtig genug, um Angriffe abzuwehren. Die Verschlüsselung ist das wichtigste Element zum Schutz der Informationen zum Ansichtszustand. Um den Ansichtszustand sicherer zu machen, unterstützt die ASP.NET @ Page-Direktive ein Attribut mit dem Namen EnableViewStateMac, dessen einziger Zweck darin besteht, einen möglichen Versuch der Beschädigung von Originaldaten zu erkennen.
Wenn EnableViewStateMac wahr ist, wird der Status der verschlüsselten Ansicht bei der Zurückmeldung der Seite algorithmisch überprüft, um zu verifizieren, dass sie auf dem Client nicht manipuliert wurde. Im Endeffekt können Sie den Inhalt des Ansichtsstatus lesen. Um ihn zu ersetzen, benötigen Sie jedoch den Verschlüsselungsschlüssel, der sich in der LSA des Webservers befindet.
Ich würde es nicht empfehlen. Selbst wenn die Sicherheit aktiviert ist, je öfter Sie die Daten von Client zu Server übertragen, desto größer ist die Wahrscheinlichkeit, dass ein Angreifer sie greifen kann. – rossisdead
Danke für die schnellen Antworten.Ich fühlte mich auch nicht sicher. Anstatt die Kartendaten festzuhalten, bearbeite ich sie sofort. Vielen Dank! – Mike
http://stackoverflow.com/questions/1049159/asp-net-1-1-viewstate-security – PRR