Github Pages Security, da .com a .io

Il meccanismo dei cookie HTTP ti consente di specificare il dominio associato a un determinato cookie. Il dominio può essere il dominio della pagina che imposta il cookie o, più interessante, uno dei suoi superdomini. Per esempio. foo.bar.example.com è autorizzato a impostare cookie sui domini foo.bar.example.com , bar.example.com e example.com .

Che cosa significa per GitHub Pages? Bene, i sottodomini del dominio github.com possono impostare cookie su di esso, il che significa che possono eseguire attacchi di fissazione della sessione fornendo al browser un cookie di sessione esistente. Ecco come apparirà uno scenario di attacco semplificato:

Diciamo che github.com utilizza un cookie chiamato SESSION_ID per identificare le sessioni attive. Questo cookie contiene un hash unico, abbastanza lungo da essere impossibile da indovinare. Ogni hash è associato ai dati di sessione lato server, ad esempio un utente che ha effettuato l'accesso.

Ora considera un utente malintenzionato che imposta una pagina GitHub a evil.github.com . Includono alcuni dei loro script malvagi nella pagina e poi ingannano una vittima per visitarla. Cosa fa la pagina? Imposta il cookie SESSION_ID sul dominio github.com su un valore valido noto all'attaccante. Ciò farebbe sì che il browser della vittima si connettesse effettivamente a GitHub utilizzando le credenziali fornite dall'hacker . L'utente malintenzionato potrebbe quindi seguire l'attività sull'account e recuperare i dati creati dalla vittima clueless.

Spostare pagine GitHub da github.com a github.io risolve il problema, poiché non ci sono account utente o sessioni sul nuovo dominio.