Wenn in der Webentwicklung der Sitzungsstatus aktiviert ist, wird eine Sitzungs-ID in einem Cookie gespeichert (im cookieless-Modus wird stattdessen eine Abfragezeichenfolge verwendet). In asp.net wird die Sitzungs-ID automatisch verschlüsselt. Es gibt viele Themen im Internet, wie Sie Ihren Cookie verschlüsseln sollten, einschließlich der Sitzungs-ID. Ich kann verstehen, warum Sie private Informationen wie DOB verschlüsseln möchten, aber private Informationen sollten nicht in Cookies gespeichert werden. Also für andere Cookie-Werte wie Sitzungs-ID, was ist die Zweckverschlüsselung? Gibt es Sicherheit überhaupt? Egal wie Sie es sichern, es wird zur Entschlüsselung zurück an den Server gesendet.
Seien Sie genauer,
Zur Authentifizierung,
vs
Asp.net Formular-Authentifizierungsmechanismus (es beruht auf Sitzungs- oder Session-ID, denke ich)
Bietet letzteres bessere Sicherheit?
Angriffe auf Sessions wie Session Hijacking zielen auf eine gültige Session ID ab. Wenn Sie jetzt die Sitzungs-ID verschlüsseln würden, würden Angreifer einfach auf die verschlüsselte Sitzungs-ID abzielen und Sie hätten keinen Vorteil. Das Verschlüsseln der Sitzungs-ID ist also nutzlos. Denken Sie daran, dass die Sitzungs-ID nur ein zufälliger Wert ist, der zum Identifizieren einer Sitzung verwendet wird. Angreifer müssen nicht wissen, ob dieser zufällige Wert eine bestimmte Bedeutung hat; Sie müssen nur diesen zufälligen Wert kennen.
Wenn Sie Ihre Sitzung sichern möchten, verwenden Sie HTTPS, um die gesamte HTTP-Kommunikation über SSL zu verschlüsseln, und setzen Sie die Cookies nur mit den Flags
Ich denke, dass die "Sie sollten immer Ihre Daten verschlüsseln" bezieht sich auf SSL in Ihren Verbindungen mit ein ordnungsgemäß signiertes Zertifikat. Dies verschlüsselt die gesamte Kommunikation zwischen Client und Server.
Ich sehe keine andere Verwendung, um die Sitzungs-ID (die ohnehin schon eine sehr zufällig generierte ID ist) anderweitig zusätzlich zu verschlüsseln.
Dies ist in der OWASP Seite
dokumentiert Über web.config im Element system.web/httpCookies
Oder programmgesteuert
%Vor%Die über SSL (HTTPS) gesendeten Daten sind vollständig verschlüsselt, Header enthalten (daher Cookies), nur der Host, an den Sie die Anfrage senden, ist nicht verschlüsselt. Es bedeutet auch, dass die GET-Anfrage verschlüsselt ist (der Rest der URL). Obwohl ein Angreifer einen Client zwingen könnte, über HTTP zu antworten, wird dringend empfohlen, das Flag "Sicher" in Ihrem Cookie zu verwenden, wodurch die Verwendung von HTTPS zum Senden von Cookies erzwungen wird.
Das Attribut "Secure" hat keine zugeordneten Werte. Stattdessen zeigt das Vorhandensein der Attributnamen an, dass das Secure-Verhalten angegeben ist. Das Secure-Attribut soll die Cookie-Kommunikation auf eine verschlüsselte Übertragung beschränken, indem Browser angewiesen werden, Cookies nur über sichere / verschlüsselte Verbindungen zu verwenden. Natürlich sollten Webserver sichere Cookies über sichere / verschlüsselte Verbindungen setzen, damit die Cookie-Informationen nicht so übertragen werden, dass sie beim ersten Senden an den Webbrowser abgehört werden können.
Das Verschlüsseln zufälliger Dinge bringt dich nirgendwohin ...
Tags und Links asp.net security session authentication cookies