Per quotare direttamente:
Only use inbuilt session management.
Store secondary SSO / framework / custom session identifiers in native session object – do not send as additional headers or cookies.
Ciò che sta dicendo è che, se hai un sistema secondario che non / non può usare sessioni integrate, non devi inviare quel secondo token di sessione come cookie o intestazione, ma invece dovresti metterlo token nella sessione integrata. In questo modo, hai un singolo token di sessione che può indirizzare gli altri se necessario.
Quando dicono "la gestione della sessione nativa", significano qualcosa come $_SESSION su PHP o l'oggetto Session in ASP.NET, in cui i dati della sessione sono archiviati sul lato server e un token viene mantenuto sul lato client per identificare la sessione per quell'utente.
Ad esempio, supponiamo tu abbia tre webapp. Successivamente, il sistema di SSO (Single Sign-On) non sarà necessario per accedere separatamente a ciascuno di essi. Secondo le linee guida OWASP, sarebbe una cattiva idea implementarlo in modo tale che visitare ogni singola applicazione ti fornisca token di sessione separati. Invece, l'SSO dovrebbe darti un singolo token di sessione, che dovrebbe essere usato per tutte e tre le applicazioni. Se per ognuno sono necessari identificatori separati, questi identificatori devono essere memorizzati nella sessione data , in modo che possano essere letti da lì.
I vantaggi di questo sono:
- La scadenza della sessione principale scade automaticamente, senza sessioni latenti.
- Meno superficie di attacco per problemi di gestione dei cookie (ad esempio
Secure o HttpOnly flags).
- Minore probabilità di perdita di token di sessione.
Un rapido esempio di PHP su come potresti gestirlo in una webapp:
<?php
session_start();
$sid = isset($_SESSION['app3_session']) ? $_SESSION['app3_session'] : NULL;
if ($sid != NULL)
{
// verify SID for this particular app
}
?>
L'SSO creerà la sessione iniziale e popolerà il valore app3_session .