Felsökningsguide för egenhostade appsessioner vid ändringar av proxy och cookies

Eva Wong

IceWhale author

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

Self-Hosted App Session Troubleshooting Guide for Proxy and Cookie Changes - Zima Store Online

Det säkra tillvägagångssättet är att behandla en lager-för-lager-jämförelse av direkta och proxade förfrågningar, svarscookies, webbläsarlagring och backend-sessionstillstånd som en serie observerbara kontrollpunkter, inte som ett enda kommando.

I en självvärd webbapplikation bakom en omvänd proxy är den praktiska risken att användare loggas ut, fastnar i en omdirigeringsslinga eller inte kan upprätta en session efter ändringar av proxyn eller cookies. Dokumentera den aktuella identiteten och återställningspunkten, börja med den minst ingripande särskiljande kontrollen, tolka godkända och underkända resultat innan du ändrar en annan variabel och stoppa när lagringstillståndet blir instabilt eller den enda återställningsbara kopian skulle exponeras. Arbetsflödet nedan avslutas först när den ursprungliga arbetsbelastningen fungerar eller bevisningen når en eskaleringsgräns.

Återskapa en sessionsväg och bevara bevis

Välj en användare, webbläsarprofil, värdnamn och inloggningsväg. Dokumentera den första misslyckade förfrågan, statussekvensen, omdirigeringsplatserna, svarens Set-Cookie-headers med värdena maskerade, förfrågningarnas cookies, proxyloggar, apploggar och den exakta konfigurationsändring som föregick felet.

Börja inte med att rensa alla cookies eller byta programmets hemlighet. Använd en privat webbläsarprofil som ren kontroll samtidigt som du bevarar den felande profilen för jämförelse. Bekräfta om direkt åtkomst till backend fungerar; det skiljer applikationsautentisering från URL- och cookie-beteende som beror på proxyn.

Stoppa om applikationen exponerar tokens i loggar, proxyn accepterar förfalskade vidarebefordringsheaders från otillförlitliga klienter eller inloggningen kringgår TLS. Skydda autentiseringsuppgifter och korrigera säkerhetsgränsen innan du fortsätter med den funktionella felsökningen.

Verifiera schema, värd och förtroende för vidarebefordran

Jämför den externa URL:en med vad applikationen tror: schema, värd, port, bassökväg och klientens IP-adress. Kontrollera Host, X-Forwarded-Proto eller standardiserade vidarebefordringsheaders samt applikationens lista över betrodda proxyservrar. En backend som tror att HTTPS-förfrågningar är HTTP kan vägra Secure-cookies eller skapa en oändlig omdirigering till HTTPS.

Använd en betrodd proxy för att ange eller ersätta vidarebefordringsheaders och konfigurera applikationen att endast lita på det proxysteget. Lägg inte blint till klientlevererade värden. Testa en inloggning och en absolut omdirigering efter varje ändring i stället för att ändra proxyheaders och applikationens bas-URL samtidigt.

ZimaSpaces guide om diagnostik av direkt och proxad inloggning använder samma jämförelse mellan direkt och proxad åtkomst efter en omstart av proxyn. Dess Immich-exempel är snävare, men bevisföringen kan överföras: bevisa att backend-sessionen fungerar och inspektera sedan vidarebefordringsheaders, routning och webbläsartillstånd.

Inspektera cookies omfattning och webbläsarens beslut

Kontrollera cookiens namn, Domain, Path, Secure, HttpOnly, SameSite, giltighetstid och om det finns dubbla cookies med samma namn på olika sökvägar eller domäner. Webbläsarens utvecklarverktyg visar om en cookie lagrades, avvisades eller utelämnades från nästa förfrågan; enbart serverloggar kan inte avslöja det beslutet.

OWASP:s beteende för SameSite-cookies förklarar hur SameSite-värden styr leverans av cookies över olika webbplatser. Om autentiseringen går över webbplatser eller använder ett inbäddat flöde kräver SameSite=None även Secure; för en enkel applikation på samma webbplats försvagar en onödig breddning av cookien designen.

Ta bort endast den berörda cookien i kontrollprofilen efter att ha dokumenterat den och upprepa sedan inloggningen. Om en ny cookie fungerar medan den bevarade profilen misslyckas, jämför omfattning och giltighetstid; om båda misslyckas, återgå till svarshuvuden eller backendens sessionslagring i stället för att upprepade gånger rensa tillståndet.

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

Kontrollera delat sessionstillstånd och validera lösningen

För applikationer med flera containrar eller repliker ska du bekräfta att varje instans använder samma sessionsigneringshemlighet och tidskälla samt samma delade sessionsbackend när det krävs. En proxy som växlar mellan instanser kan se ut som slumpmässiga utloggningar när en instans inte kan validera den andras cookie.

PortSwiggers diskussion om SameSites säkerhetsgräns fokuserar på säkerhet, men klargör att SameSite är en webbläsargräns och inte en allmän knapp för att reparera inloggning. Bevara CSRF-skyddet samtidigt som du anpassar det efter applikationens faktiska ursprung och omdirigeringsflöde.

Validera inloggning, utloggning, inaktivitetens giltighetstid, omstart av webbläsaren, lösenordsändring och åtkomst via de avsedda interna och externa värdnamnen. Avsluta ärendet först när gamla cookies misslyckas på ett säkert sätt, nya sessioner överlever normal routning och ingen vidarebefordran eller cookie-attribut har lättats mer än det dokumenterade behovet kräver.