Sicherheit: ASP.NET Identität HTTPOnly Cookie mit SSL

Question

Dies ist eine allgemeine Frage, da ich gewohnt bin, Benutzerobjekt in der Sitzung gespeichert werden, und ich lerne das neue Identitätsframework.

Ich sehe viel reden über das Senden von "Claims" als Teil des Cookies. So müssen Sie die Benutzerinformationen nicht erneut nachschlagen. Bedeutungen wie Name, E-Mail oder sogar Berechtigungen sind ein Teil des Anspruchsbereichs im Cookie, der gespeichert wird.

Alles, was ich hier untersucht habe, sagt httpOnly über SSL ist sehr sicher in Bezug auf gehackt werden. Ich zögere, etwas anderes als eine Benutzer-ID zu senden, um den Benutzer zu identifizieren und dann den Rest in der DB nachzuschlagen, um sicherzustellen, dass zumindest, wenn der Benutzer gehackt wird, die Berechtigungen nicht gehackt werden. Bin ich übervorsichtig?

Ich sehe auch Leute Cookies setzen, um in 7 Tagen oder 1 Tag ect ... In Bezug auf das, und Sie senden die Berechtigungen/Rollen im Bereich Ansprüche ablaufen. Was passiert, wenn sie sich auf dem Server ändern? Im Grunde scheint es, dass sich der Benutzer an- und abmelden muss, damit die neuen Berechtigungen stattfinden können. War das Wundern, dass die Norm Erwartung mit Software-UI-Standards ist?

Vielen Dank im Voraus für Ihre Gedanken :)

Angela

Answer 1

meine Unwissenheit verzeihen, aber ich habe über ein Stück Software, die nicht kommen, wo die Ansprüche in Cookies gesendet werden würden. In der Regel besteht das Problem mit Cookies in der Möglichkeit von XSS (Cross-Site-Scripting) -Angriffen, da Browser so geschrieben sind, dass sie sie immer senden.

In den heutigen Tagen wird häufig ein Mechanismus zur föderierten Authentifizierung verwendet, bei dem Identity Provider (Anmeldeseite) und Dienstanbieter (der App-Code) nicht unbedingt dieselbe App sind und nicht immer direkt verbunden sind . Dies bedeutet, dass die Daten des Benutzers, die Sie in der Datenbank nachschlagen können, nur in IdP vorhanden sind und SP sich mit den von Ihnen bereitgestellten IDPs befassen muss.

Dies ist der Grund, warum jedes Bit der Information in einem 'Anspruch' gesendet wird. Dies bedeutet, dass der IdP behauptet, dass der Benutzername john.smith ist, aber SP hat möglicherweise keine Möglichkeit, dies zu überprüfen.

Damit IdP und SP funktionieren, sollten sie eine Art von Vertrauensstellung eingerichtet haben, typischerweise in Form von Pre-Shared Signing Keys, die es dem IdP erlauben, das Token (SAML Envelope oder JWT) und den SP zu signieren um zu überprüfen, ob die Signatur überprüft werden kann, dass das Token nicht manipuliert wurde.

Dieses Token wird normalerweise nie als Cookie verwendet. stattdessen wird es zu einem Authorization Header hinzugefügt, der normalerweise Bearer Schema verwendet.

Auch als Randnotiz - wenn Sie sagen, dass Sie mit Sitzungen vertraut sind, müssen Sie verstehen, dass ein Session Tracker auch ein Cookie ist (in ASP.NET). Der Server verfügt über Informationen zu einem Benutzer, der im Speicher-Cache des App-Pools gespeichert ist, und der Browser sendet weiterhin das Cookie mit der Angabe "Hier bin ich". Aus Sicherheitsgründen gibt es eine vergleichbare Ebene zwischen der einfachen Verwendung von Cookies oder der Verwendung von Cookies und Sitzungen. Natürlich könnte man argumentieren, dass ein Cookie Informationen verlieren könnte, aber eine App könnte immer die Daten in Tokens umwandeln oder das ganze Cookie verschlüsseln, um dieses Argument zu negieren.