nicht angemeldet
Wenn Du die Session-ID bei jedem Request änderst, ist ein solcher Download-Link auch gegen CSRF geschützt. Wer Deine Session kapern will, muss vor Dir eine weitere Seite aufrufen
Dieses Verfahren wird häufig in Verbindung mit Session-Fixation-Angriffen genannt, aber es hat leider bekannte Schwachstellen.
Zum einen entsteht dadurch eine Race-Condition: Wem gelingt es zuerst einen Request abzusetzen, um einen neue Session-ID zu generieren, dem Angreifer oder dem Nutzer? Die Startbedingungen stehen besser für den Angreifer, da er die Abfrage automatisiert stellen kann. So kann der Angreifende das Opfer von der Nutzung der Seite aussperren, indem er schneller als das Opfer neue Session-IDs generiert.
Zum anderen wird der Server ggf. anfällig für DOS-Angriffe: Wenn der Server einen Hardware-getriebenen Zufallsgenerator benutzt, muss der Server erst genügend Umgebungs-Entropie sammeln, um Session-IDs zu generieren. Ein Angreifer kann das ausnutzen: er kann in sehr hoher Frequenz Anfragen an den Server schicken, die ihn zwingen neue Session-IDs zu erzeugen. Bei jedem Request wird der Entropie-Buffer wieder geleert und der Server muss warten, bis er wieder genügend befüllt ist, um die nächste ID zu generieren. Macht er das in einer ausreichend hohen Frequenz, dann hat der Server keine Ressourcen mehr übrig, um die Anfragen legitimer Besucher:innen zu bedienen.
Die gängige Praxis ist es, die Session-ID nicht bei jeder Anfrage neu zu vergeben, sondern nur bei Änderungen der Nutzer-Priviligen, zum Beispiel wenn der Nutzer sich ein- oder ausloggt. Außerdem sollten veraltete Session-IDs ungültig gemacht werden und nach angemessener Lebensdauer automatisch verworfen werden. Auch zu diesem Thema gibt es ein Cheat Sheet von OWASP.
Das ist aber ein anderes Thema. Ich verstehe auch nicht, wie das Erneuern der Session-ID vor CSRF-Angriffen schützen sollte.
Der Martin