Laden...

ASP.NET Core: Sessions funktionieren nicht in Iframe

Erstellt von Cord Worthmann vor 4 Jahren Letzter Beitrag vor 4 Jahren 2.038 Views
C
Cord Worthmann Themenstarter:in
1.215 Beiträge seit 2004
vor 4 Jahren
ASP.NET Core: Sessions funktionieren nicht in Iframe

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:



            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ß

T
2.219 Beiträge seit 2008
vor 4 Jahren

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

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

C
Cord Worthmann Themenstarter:in
1.215 Beiträge seit 2004
vor 4 Jahren

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.

C
Cord Worthmann Themenstarter:in
1.215 Beiträge seit 2004
vor 4 Jahren

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:


services.AddMvc().AddRazorPagesOptions(options =>
{
    options.Conventions.ConfigureFilter(new IgnoreAntiforgeryTokenAttribute());
});

16.806 Beiträge seit 2008
vor 4 Jahren

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

   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.

C
Cord Worthmann Themenstarter:in
1.215 Beiträge seit 2004
vor 4 Jahren

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.