4. Considerazioni di sicurezza

Le applicazioni che introducono nuovi URI ben noti, così come gli amministratori che li distribuiscono, dovranno considerare diverse questioni legate alla sicurezza, tra cui (senza limitarsi a) esposizione di dati sensibili, attacchi di tipo denial-of-service (oltre ai normali problemi di carico), autenticazione di server e client, vulnerabilità ad attacchi di DNS rebinding, e attacchi in cui un accesso limitato al server consente di influenzare come vengono serviti gli URI ben noti.

[RFC3552] contiene alcuni esempi di potenziali considerazioni di sicurezza rilevanti per i protocolli applicativi e per gli amministratori che li distribuiscono.

4.1. Protezione delle risorse ben note

Poiché le posizioni ben note rappresentano in effetti l’intera origine, gli operatori del server dovrebbero controllare in modo appropriato la possibilità di scrivervi. Ciò vale soprattutto quando più entità sono collocate sulla stessa origine. Anche per origini controllate da e rappresentanti una singola entità, occorre cura per assicurarsi che l’accesso in scrittura alle posizioni ben note non sia concesso inconsapevolmente, né esternamente tramite la configurazione del server né localmente tramite permessi dell’implementazione (ad es. su un file system).

4.2. Interazione con la navigazione Web

Le applicazioni che usano URI ben noti in URL http o https devono essere consapevoli che le risorse ben note saranno accessibili ai browser Web e quindi possono essere manipolate da contenuti ottenuti da altre parti di quell’origine. Se un attaccante riesce a iniettare contenuti (ad es. tramite una vulnerabilità Cross-Site Scripting), potrà effettuare richieste potenzialmente arbitrarie alla risorsa ben nota.

HTTP e HTTPS usano le origini anche come confine di sicurezza per molti altri meccanismi, tra cui (senza limitarsi a) cookie [RFC6265], Web Storage [WEBSTORAGE] e varie capacità.

Un’applicazione che definisce posizioni ben note non dovrebbe presumere di avere accesso esclusivo a tali meccanismi o di essere l’unica applicazione che usa l’origine. A seconda della natura dell’applicazione, le mitigazioni possono includere:

Crittografare le informazioni sensibili
Consentire flessibilità nell’uso degli identificatori (ad es. nomi dei cookie) per evitare collisioni con altre applicazioni
Usare il flag HttpOnly sui cookie per assicurarsi che non siano esposti agli script del browser [RFC6265]
Usare il parametro Path sui cookie per assicurarsi che non siano disponibili ad altre parti dell’origine [RFC6265]
Usare X-Content-Type-Options: nosniff [FETCH] per assicurarsi che contenuti sotto controllo dell’attaccante non possano essere indotti in una forma interpretata come contenuto attivo da un browser Web

Altre buone pratiche:

Usare un tipo di media specifico dell’applicazione nel campo di intestazione Content-Type e richiedere che i client falliscano se non è usato
Usare Content-Security-Policy [CSP] per vincolare le capacità del contenuto attivo (come HTML [HTML5]), mitigando così attacchi Cross-Site Scripting
Usare Referrer-Policy [REFERRER-POLICY] per impedire che dati sensibili negli URL vengano trapelati nel campo di intestazione di richiesta Referer
Evitare la compressione su informazioni sensibili (ad es. token di autenticazione, password), poiché l’ambiente di scripting offerto dai browser Web consente a un attaccante di sondare ripetutamente lo spazio di compressione; se l’attaccante ha accesso al percorso della comunicazione, può usare questa capacità per recuperare tali informazioni.

4.3. Ambito delle applicazioni

Il presente memo non specifica l’ambito di applicabilità delle informazioni ottenute da un URI ben noto, né come scoprire l’URI ben noto per una particolare applicazione.

Ogni applicazione che usa questo meccanismo deve definire entrambi gli aspetti; in caso contrario possono sorgere problemi di sicurezza da deviazioni implementative e confusione sui confini tra applicazioni.

Applicare i metadati scoperti in un URI ben noto a risorse diverse da quelle collocate sulla stessa origine comporta rischi amministrativi e di sicurezza. Ad esempio, consentire che https://example.com/.well-known/example applichi policy a https://department.example.com, https://www.example.com o persino https://www.example.com:8000 presuppone una relazione tra host che potrebbe non esistere, dando così il controllo a un potenziale attaccante.

Allo stesso modo, specificare che un URI ben noto su un determinato nome host sia usato per avviare un protocollo può causare un gran numero di richieste indesiderate. Ad esempio, se un URI HTTPS ben noto è usato per trovare policy su un servizio separato come la posta elettronica, ciò può generare un’ondata di richieste ai server Web, anche se non implementano l’URI ben noto. Tali richieste indesiderate possono assomigliare a un attacco denial-of-service.

4.4. Capacità nascoste

Le applicazioni che usano posizioni ben note dovrebbero considerare che alcuni amministratori di server potrebbero ignorarne l’esistenza (in particolare su sistemi operativi che nascondono le directory il cui nome inizia con .). Ciò significa che se un attaccante ha accesso in scrittura alla directory .well-known, potrebbe controllarne i contenuti senza che l’amministratore se ne accorga.