16 Security Considerations (Considerazioni sulla sicurezza)
16 Security Considerations (Considerazioni sulla sicurezza)
Per la similarità di sintassi e uso tra server RTSP e HTTP, valgono le considerazioni sulla sicurezza delineate in [H15]. In particolare, si noti quanto segue:
Meccanismi di autenticazione: RTSP e HTTP condividono schemi di autenticazione comuni e dovrebbero quindi seguire le stesse prescrizioni in materia di autenticazione. Vedere [H15.1] per l'autenticazione del client e [H15.2] per il supporto di più meccanismi.
Abuso dei log del server: I server RTSP e HTTP avranno presumibilmente meccanismi di logging simili e dovrebbero quindi proteggere con uguale cautela il contenuto di tali log, salvaguardando la privacy degli utenti. Vedere [H15.3] per le raccomandazioni HTTP sui log.
Trasferimento di informazioni sensibili: Non c'è motivo di ritenere che le informazioni trasferite via RTSP siano meno sensibili di quelle trasmesse normalmente via HTTP. Pertanto, tutte le precauzioni su privacy dei dati e degli utenti si applicano a chi implementa client, server e proxy RTSP. Vedere [H15.4] per i dettagli.
Attacchi basati su nomi di file e percorso: Sebbene gli URL RTSP siano handle opachi senza semantica di file system, si prevede che molte implementazioni tradurranno porzioni degli URL direttamente in chiamate al file system. In tal caso, i file system DOVREBBERO seguire le precauzioni di [H15.5], ad es. verificare la presenza di «..» nei componenti del percorso.
Informazioni personali: I client RTSP spesso hanno accesso alle stesse informazioni dei client HTTP (nome utente, posizione, ecc.) e vanno trattati allo stesso modo. Vedere [H15.6].
Privacy e header Accept: Poiché molti degli stessi header «Accept» esistono in RTSP come in HTTP, vanno seguite le stesse avvertenze di [H15.7] sul loro uso.
DNS spoofing: Presumibilmente, date le connessioni tipicamente più lunghe delle sessioni RTSP rispetto a HTTP, le ottimizzazioni DNS lato client RTSP saranno meno diffuse. Tuttavia, le raccomandazioni in [H15.8] restano rilevanti per ogni implementazione che tenti di far valere una mappatura DNS-IP oltre un singolo utilizzo.
Header Location e spoofing: Se un server supporta più organizzazioni che non si fidano l'un l'altra, deve controllare i valori degli header Location e Content-Location nelle risposte generate sotto il controllo di tali organizzazioni, affinché non tentino di invalidare risorse fuori dalla loro autorità. ([H15.9])
Oltre alle raccomandazioni nella specifica HTTP corrente (RFC 2068 [2] alla stesura del presente documento), specifiche HTTP future possono fornire ulteriore guida sui problemi di sicurezza.
Di seguito considerazioni aggiuntive per le implementazioni RTSP.
Attacco denial-of-service concentrato: Il protocollo consente un attacco denial-of-service controllato da remoto. L'attaccante può avviare flussi verso uno o più indirizzi IP indicandoli come destinazione nelle richieste SETUP. L'indirizzo IP dell'attaccante può essere noto, ma ciò non è sempre utile a prevenire ulteriori attacchi o a identificare l'autore. Un server RTSP DOVREBBE consentire destinazioni specificate dal client per i flussi avviati via RTSP solo se ha verificato l'identità del client, ad es. tramite meccanismi di autenticazione RTSP (preferibilmente digest o più forte) contro un database di utenti noti, o altri mezzi sicuri.
Dirottamento di sessione: Non essendovi relazione tra connessione a livello di trasporto e sessione RTSP, un client malevolo può inviare richieste con identificatori di sessione casuali che colpiscono client ignari. Il server DOVREBBE usare un identificatore di sessione grande, casuale e non sequenziale per ridurre questa possibilità.
Autenticazione: I server DOVREBBERO implementare sia l'autenticazione basic sia digest [8]. Dove serve maggiore sicurezza per i messaggi di controllo, il flusso di controllo RTSP può essere cifrato.
Problemi di flusso: RTSP fornisce solo il controllo del flusso. La consegna del flusso non è trattata in questa sezione né nel resto del memo. Le implementazioni RTSP si appoggiano spesso ad altri protocolli come RTP, multicast IP, RSVP e IGMP e dovrebbero affrontare le considerazioni di sicurezza ivi sollevate.
Comportamento persistentemente sospetto: I server RTSP DOVREBBERO restituire il codice di errore 403 (Forbidden) alla ricezione di un singolo comportamento ritenuto un rischio per la sicurezza. DOVREBBERO anche accorgersi di tentativi di sondare il server per debolezze e PORREBBERO disconnettere arbitrariamente e ignorare ulteriori richieste da client che violano la politica di sicurezza locale.