Il mio nome NON è nessuno
- Marco Montorsi
- Sicurezza Informatica
- 16 Apr, 2024
Concetto di autenticazione nell’informatica
L’autenticazione è l’atto di verificare l’identità di un utente, che può essere una persona, un’applicazione o un dispositivo. Questo processo avviene attraverso diversi fattori, che possono includere ciò che l’utente “sa”, ciò che l’utente “possiede” e ciò che l’utente “è”.
- Conoscenza: l’utente può dimostrare di conoscere una password o può rispondere a una sfida, come una password monouso (ad esempio, TOTP).
- Possesso: l’utente può dimostrare di possedere un token hardware o software, o un dispositivo di sicurezza come un telefono cellulare.
- Caratteristiche biometriche: l’utente può essere identificato tramite tratti biometrici come impronte digitali o riconoscimento facciale.
Quando l’autenticazione richiede più di un fattore, si parla di autenticazione multi-fattore.
Concetto di Sessione
Alcune applicazioni consentono agli utenti di rimanere autenticati solo per un periodo limitato di tempo prima di richiedere loro di autenticarsi nuovamente. Questo è fatto per verificare che l’utente sia ancora legittimo.
La durata della sessione dipende dalla sensibilità dell’applicazione e dal rischio di esposizione. Per ulteriori informazioni sulla gestione delle sessioni, si consiglia di consultare la pagina dedicata di OWASP.
Gestione delle Sessioni
Poiché HTTP è ”stateless”, le applicazioni forniscono agli utenti identificatori di sessione (token) che vengono scambiati per la durata della sessione. I cookie sono comunemente utilizzati a questo scopo:
- PHPSESSID (PHP)
- JSESSIONID (J2EE)
- ASP.NET_SessionId (ASP .NET), ecc.
Questi sono preferibili rispetto al salvataggio di token in spazi di memoria come il localStorage del browser, che è più esposto a possibili script malevoli.
Per i cookie di sessione è buona prassi impostare il flag ”http only”, che impedisce l’accesso al cookie da parte di JavaScript, rendendo più difficile un eventuale session hijacking in caso di attacchi XSS(Cross Site Scripting). È inoltre consigliabile impostare l’attributo ”secure” per garantire lo scambio del cookie solo su HTTPS.
Altre implementazioni di sessione utilizzano:
- Parametri o argomenti URL
- Parametri del body della richiesta
- Intestazioni HTTP personalizzate
Rischi legati a configurazioni non corrette
L’autenticazione di un’applicazione è un aspetto critico per la sicurezza del software. I principali rischi di sicurezza secondo la lista OWASP 2021 includono:
- Violazione del principio del privilegio minimo o del rifiuto predefinito
- Elusione dei controlli di accesso (modifica dell’URL, dello stato interno dell’applicazione, ecc.)
- Permesso di visualizzare o modificare l’account di un altro utente (fornendo il suo identificatore univoco)
- Accesso all’API con controlli di accesso mancanti
- Elevazione dei privilegi (agire come un utente senza essere connessi)
- Manipolazione dei metadati (ad esempio, riproduzione o manomissione di un JWT o token di controllo dell’accesso)
- Configurazione errata di CORS (consente l’accesso all’API da origini non autorizzate/non attendibili)
- Forzare la navigazione verso pagine autenticate come utente non autenticato o verso pagine privilegiate come utente standard.
Framework di autenticazione popolari
- SAML 2.0
- OAuth 2.0
- OpenId Connect
In futuro, verranno pubblicati articoli dedicati a questi framework per fornire una spiegazione più dettagliata del loro funzionamento. In generale, questi framework vengono utilizzati per gestire l’autenticazione in modo centralizzato;
Attraverso un identity provider, si consente agli utenti di accedere a più applicazioni con un’unica autenticazione per migliorare la sicurezza complessiva dell’architettura.
Per essere più precisi, OAuth è principalmente utilizzato per lo scopo dell’autorizzazione piuttosto che per l’autenticazione. Queste differenze saranno spiegate più approfonditamente negli articoli dei singoli framework.
Gestione della Sessione in Laravel
Ci sono molte librerie che consentono di implementare vari flussi di autenticazione in Laravel.
L’implementazione più comune utilizza un cookie di sessione, il cui identificatore viene aggiornato ad ogni richiesta.
I valori di configurazione possono essere impostati nel file di configurazione config/session.php.
<?php
use Illuminate\Support\Str;
return [
/*
|--------------------------------------------------------------------------
| Default Session Driver
|--------------------------------------------------------------------------
|
| This option controls the default session "driver" that will be used on
| requests. By default, we will use the lightweight native driver but
| you may specify any of the other wonderful drivers provided here.
|
| Supported: "file", "cookie", "database", "apc",
| "memcached", "redis", "dynamodb", "array"
|
*/
'driver' => env('SESSION_DRIVER', 'file'),
/*
|--------------------------------------------------------------------------
| Session Lifetime
|--------------------------------------------------------------------------
|
| Here you may specify the number of minutes that you wish the session
| to be allowed to remain idle before it expires. If you want them
| to immediately expire on the browser closing, set that option.
|
*/
'lifetime' => env('SESSION_LIFETIME', 120),
'expire_on_close' => false,
/*
|--------------------------------------------------------------------------
| Session Encryption
|--------------------------------------------------------------------------
|
| This option allows you to easily specify that all of your session data
| should be encrypted before it is stored. All encryption will be run
| automatically by Laravel and you can use the Session like normal.
|
*/
'encrypt' => false,
/*
|--------------------------------------------------------------------------
| Session File Location
|--------------------------------------------------------------------------
|
| When using the native session driver, we need a location where session
| files may be stored. A default has been set for you but a different
| location may be specified. This is only needed for file sessions.
|
*/
'files' => storage_path('framework/sessions'),
/*
|--------------------------------------------------------------------------
| Session Database Connection
|--------------------------------------------------------------------------
|
| When using the "database" or "redis" session drivers, you may specify a
| connection that should be used to manage these sessions. This should
| correspond to a connection in your database configuration options.
|
*/
'connection' => env('SESSION_CONNECTION'),
/*
|--------------------------------------------------------------------------
| Session Database Table
|--------------------------------------------------------------------------
|
| When using the "database" session driver, you may specify the table we
| should use to manage the sessions. Of course, a sensible default is
| provided for you; however, you are free to change this as needed.
|
*/
'table' => 'sessions',
/*
|--------------------------------------------------------------------------
| Session Cache Store
|--------------------------------------------------------------------------
|
| While using one of the framework's cache driven session backends you may
| list a cache store that should be used for these sessions. This value
| must match with one of the application's configured cache "stores".
|
| Affects: "apc", "dynamodb", "memcached", "redis"
|
*/
'store' => env('SESSION_STORE'),
/*
|--------------------------------------------------------------------------
| Session Sweeping Lottery
|--------------------------------------------------------------------------
|
| Some session drivers must manually sweep their storage location to get
| rid of old sessions from storage. Here are the chances that it will
| happen on a given request. By default, the odds are 2 out of 100.
|
*/
'lottery' => [2, 100],
/*
|--------------------------------------------------------------------------
| Session Cookie Name
|--------------------------------------------------------------------------
|
| Here you may change the name of the cookie used to identify a session
| instance by ID. The name specified here will get used every time a
| new session cookie is created by the framework for every driver.
|
*/
'cookie' => env(
'SESSION_COOKIE',
Str::slug(env('APP_NAME', 'laravel'), '_').'_session'
),
/*
|--------------------------------------------------------------------------
| Session Cookie Path
|--------------------------------------------------------------------------
|
| The session cookie path determines the path for which the cookie will
| be regarded as available. Typically, this will be the root path of
| your application but you are free to change this when necessary.
|
*/
'path' => '/',
/*
|--------------------------------------------------------------------------
| Session Cookie Domain
|--------------------------------------------------------------------------
|
| Here you may change the domain of the cookie used to identify a session
| in your application. This will determine which domains the cookie is
| available to in your application. A sensible default has been set.
|
*/
'domain' => env('SESSION_DOMAIN'),
/*
|--------------------------------------------------------------------------
| HTTPS Only Cookies
|--------------------------------------------------------------------------
|
| By setting this option to true, session cookies will only be sent back
| to the server if the browser has a HTTPS connection. This will keep
| the cookie from being sent to you when it can't be done securely.
|
*/
'secure' => env('SESSION_SECURE_COOKIE'),
/*
|--------------------------------------------------------------------------
| HTTP Access Only
|--------------------------------------------------------------------------
|
| Setting this value to true will prevent JavaScript from accessing the
| value of the cookie and the cookie will only be accessible through
| the HTTP protocol. You are free to modify this option if needed.
|
*/
'http_only' => true,
/*
|--------------------------------------------------------------------------
| Same-Site Cookies
|--------------------------------------------------------------------------
|
| This option determines how your cookies behave when cross-site requests
| take place, and can be used to mitigate CSRF attacks. By default, we
| will set this value to "lax" since this is a secure default value.
|
| Supported: "lax", "strict", "none", null
|
*/
'same_site' => 'lax',
/*
|--------------------------------------------------------------------------
| Partitioned Cookies
|--------------------------------------------------------------------------
|
| Setting this value to true will tie the cookie to the top-level site for
| a cross-site context. Partitioned cookies are accepted by the browser
| when flagged "secure" and the Same-Site attribute is set to "none".
|
*/
'partitioned' => false,
];