myCSharp.de - DIE C# und .NET Community
Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 
 | Suche | FAQ

» Hauptmenü
myCSharp.de
» Startseite
» Forum
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Suche
» Regeln
» Wie poste ich richtig?
» Forum-FAQ

Mitglieder
» Liste / Suche
» Wer ist wo online?

Ressourcen
» openbook: Visual C#
» openbook: OO
» Microsoft Docs

Team
» Kontakt
» Übersicht
» Wir über uns

» myCSharp.de Diskussionsforum
Du befindest Dich hier: Community-Index » Diskussionsforum » Entwicklung » Web-Technologien » ASP.NET Core: Sessions funktionieren nicht in Iframe
Letzter Beitrag | Erster ungelesener Beitrag Druckvorschau | Thema zu Favoriten hinzufügen

Antwort erstellen
Zum Ende der Seite springen  

ASP.NET Core: Sessions funktionieren nicht in Iframe

 
Autor
Beitrag « Vorheriges Thema | Nächstes Thema »
Cord Worthmann Cord Worthmann ist männlich
myCSharp.de-Mitglied

Dabei seit: 30.03.2004
Beiträge: 1.203


Cord Worthmann ist offline

ASP.NET Core: Sessions funktionieren nicht in Iframe

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Hallo,

ich habe noch mal ein Problem mit Cookies in ASP.NET Core.

Unsere Anwendung läuft in einem Iframe, der auf Websites mit abweichender Domain erscheint. Sobald dies der Fall ist, werden keine Session-Cookies mehr geschrieben bzw. überhaupt keine Cookies mehr, die von ASP.NET automatisch erstellt werden wie Antiforgery u.ä. Im Testszenario innerhalb derselben Domain funktioniert alles wie erwünscht. Also offensichtlich ein Problem, das mit der domainübergreifenden Funktionsweise der App zu tun hat.

In der Startup.cs habe ich das so konfiguriert:

C#-Code:
            services.AddDistributedMemoryCache();
            services.AddSession(options =>
            {
                options.IdleTimeout = TimeSpan.FromMinutes(UserManagement.SessionTimeout);
                options.Cookie.HttpOnly = true;
                options.Cookie.IsEssential = true;
                //options.Cookie.Name = UserManagement.SessionCookieName;
                options.Cookie.SameSite = SameSiteMode.None;
                options.Cookie.SecurePolicy = CookieSecurePolicy.None;
            });


            services.AddAntiforgery(options =>
            {
                options.SuppressXFrameOptionsHeader = true;
            });

Hat evtl. jemand eine Idee, was hier zu tun ist?

Gruß

Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von Cord Worthmann am 03.02.2020 10:56.

03.02.2020 10:51 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
T-Virus T-Virus ist männlich
myCSharp.de-Mitglied

Dabei seit: 17.04.2008
Beiträge: 1.602
Entwicklungsumgebung: Visual Studio, Codeblocks, Edi
Herkunft: Nordhausen, Nörten-Hardenberg


T-Virus ist offline Füge T-Virus Deiner Kontaktliste hinzu

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Liegt an der  Same-Origin Policy
Wäre auch fatal, wenn eine andere Domain einfach so eine Session einer anderen Domain verwenden könnte.

Wenn du die Session verwenden willst, kann dein iFrame nur funktionieren, wenn die Seiten darin zu gleichen Domain gehören.

T-Virus
03.02.2020 11:07 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Cord Worthmann Cord Worthmann ist männlich
myCSharp.de-Mitglied

Dabei seit: 30.03.2004
Beiträge: 1.203

Themenstarter Thema begonnen von Cord Worthmann

Cord Worthmann ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

So etwas hatte ich schon vermutet, war mir aber nicht sicher, ob der Browser die Cookies unterschiedlicher Domains nicht auch getrennt verwaltet.

Aber danke für den Hinweis bzw. die Bestätigung.
03.02.2020 11:19 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Cord Worthmann Cord Worthmann ist männlich
myCSharp.de-Mitglied

Dabei seit: 30.03.2004
Beiträge: 1.203

Themenstarter Thema begonnen von Cord Worthmann

Cord Worthmann ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Nach allerhand Recherche und Ausprobieren hat sich ergeben, dass man Sessions doch in einem Iframe verwenden kann. Man muss allerdings den AntiForgery-Mechanismus von ASP.NET deaktivieren. Bin darauf gestoßen, weil Formulardaten innerhalb des Iframes auch im Nirvana verschwunden sind.

Nur für den Fall, dass jemand mal vor einem ähnlichen Problem steht, hier der notwendige Befehl:

C#-Code:
services.AddMvc().AddRazorPagesOptions(options =>
{
    options.Conventions.ConfigureFilter(new IgnoreAntiforgeryTokenAttribute());
});
03.02.2020 13:13 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Abt
myCSharp.de-Team

avatar-4119.png


Dabei seit: 20.07.2008
Beiträge: 14.219
Herkunft: Stuttgart/Stockholm


Abt ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

AntiForgery prüft bei einem POST Request, ob ein Formular vorher dem Benutzer über eine GET-Anfrage angezeigt wurde.
So kann man die Hürde erhöhen, dass Bots einfach Formulare über POST abschicken.
Das Angriffsszenario nennt sich CSRF.

Technologisch ist das so, dass das entsprechende @Html.AntiForgeryToken() eine Session erzeugt und einen zusätzlichen Eintrag im Formular hinterlässt.
Dieser VerficationToken wird beim Submit dann am HTTP Post Endpunkt geprüft; ist er nicht da oder ungültig, dann gibts einen Error.

Bezogen auf ASP.NET Core ist aber die Prüfung nicht global aktiv; daher wird auch kein Fehler erzeugt, wenn man das nicht prüft.
Offenbar verwendest Du jedoch die Razor Pages (diese Info fehlte); das ist die derzeit einzige Middleware von ASP.NET Core, die CSRF/XSRF aktiv prüft und immer geprüft wird.

Sessions verwenden per default jedoch Cookies.
Daher wird

C#-Code:
   options.Cookie.SameSite = SameSiteMode.None;
                options.Cookie.SecurePolicy = CookieSecurePolicy.None;

nicht funktionieren.

Siehe auch  Developers: Get Ready for New SameSite=None; Secure Cookie Settings

iframes werden leider sehr oft dazu verwendet, dass Tracker und andere Datensammel-Varianten in Seiten zu injizieren.
Daher gibt es auch schon die ersten Bemühungen iframes in Browsern generell zu verbieten oder zumindest deren Einsatz sehr einzuschränken; dies ist vor allem bei Cookies der Fall.
Der neue Microsoft Edge macht dies bereits in den striken Privacy Settings - und auch Chrome und Firefox werden hier nachziehen.

Die allgemeine Empfehlung - und danach streben auch die Einschränkungen der iFrames - ist, dass Du das Formular nicht über ein IFrame einbindest.
Die Alternative ist ein eingebettetes Formular, dessen Endpunkt dann zB via JavaScript angesprochen wird.
Dazu muss man beachten, dass dies prinzipiell ein XHR Request zu einer fremdem Domain ist, was Browser standardmäßig blocken; was aber in den Cross Origin Headern freigegeben werden kann.
03.02.2020 13:30 Beiträge des Benutzers | zu Buddylist hinzufügen
Cord Worthmann Cord Worthmann ist männlich
myCSharp.de-Mitglied

Dabei seit: 30.03.2004
Beiträge: 1.203

Themenstarter Thema begonnen von Cord Worthmann

Cord Worthmann ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Okay, vielen Dank für den Hinweis!

Die Iframe-Lösung ist leider eine Anforderung seitens unserer Leitung. Es geht um ein Modul, das verschiedene Abfragen an unsere Hauptanwendung richtet und auswertet. Die Abfragen selber mache ich schon per AJAX, aber es gehört auch ein Registrierungs- und Loginsystem dazu.

Das Iframe-Modul soll möglichst einfach in die Websites unserer Kunden eingebunden werden, die i.d.R. irgendein PHP-CMS verwenden wie Wordpress, Joomla o.ä., weswegen das mit einem eingebetteten Formular schwer wird. Aber wenn die Browser-Entwicklung diesen Weg geht, werde ich das wohl mittelfristig so umbauen müssen, dass die gesamte Funktionalität per AJAX/REST-Api abgewickelt wird.
03.02.2020 14:03 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Baumstruktur | Brettstruktur       | Top 
myCSharp.de | Forum Der Startbeitrag ist älter als 7 Monate.
Der letzte Beitrag ist älter als 7 Monate.
Antwort erstellen


© Copyright 2003-2020 myCSharp.de-Team | Impressum | Datenschutz | Alle Rechte vorbehalten. | Dieses Portal verwendet zum korrekten Betrieb Cookies. 30.09.2020 22:10