5. Considerazioni sulla sicurezza
5. Considerazioni sulla sicurezza
Le considerazioni sulla sicurezza per PATCH sono quasi identiche alle considerazioni sulla sicurezza per PUT ([RFC2616], sezione 9.6). Queste includono l'autorizzazione delle richieste (possibilmente tramite controllo degli accessi e/o autenticazione) e la garanzia che i dati non vengano corrotti attraverso errori di trasmissione o sovrascritture accidentali. Qualsiasi meccanismo utilizzato per PUT può essere utilizzato anche per PATCH. Le seguenti considerazioni si applicano in particolare a PATCH.
Un documento che viene patchato potrebbe essere più suscettibile alla corruzione rispetto a un documento che viene sovrascritto nella sua interezza, ma questa preoccupazione può essere affrontata attraverso l'uso di meccanismi come richieste condizionali (conditional requests) utilizzando ETag e l'intestazione di richiesta If-Match come descritto nella sezione 2. Se una richiesta PATCH fallisce, il client può emettere una richiesta GET alla risorsa per vedere in quale stato si trova. Nella maggior parte dei casi, il client può verificare il contenuto della risorsa per vedere se il PATCH ha prodotto lo stato previsto.
A volte un intermediario HTTP (intermediary) potrebbe tentare di rilevare virus inviati tramite HTTP controllando il corpo della richiesta PUT/POST o della risposta GET. Il metodo PATCH complica tale monitoraggio perché né il documento sorgente né il documento di patch potrebbero essere un virus, ma il risultato potrebbe esserlo. Questa considerazione sulla sicurezza non è materialmente diversa da quelle già introdotte da download di intervalli di byte (byte-range downloads), download di documenti di patch, caricamento di file compressi, ecc.
I singoli formati di documenti di patch avranno le proprie considerazioni di sicurezza specifiche che saranno documentate con quei formati. Le applicazioni che utilizzano PATCH dovrebbero prendere in considerazione tutte le considerazioni di sicurezza associate ai formati specifici che supportano. Tuttavia, alcune considerazioni generali si applicano a tutti i formati di documenti di patch, tra cui:
- I documenti di patch potrebbero contenere istruzioni per modificare parti di una risorsa che il client non è autorizzato a modificare. Tale PATCH dovrebbe essere rifiutato dal server.
- Alcuni formati di documenti di patch potrebbero avere disposizioni per richieste condizionali. Il server DEVE (MUST) garantire che tali condizioni siano valutate in base allo stato della risorsa al momento dell'operazione, non allo stato al momento della richiesta.
- I server DEVONO (MUST) essere cauti nella convalida delle risorse che contengono contenuto non affidabile (ad esempio, dati forniti dall'utente). Molte operazioni di convalida richiedono l'analisi della risorsa e l'analisi di contenuto non affidabile presenta opportunità per attacchi denial-of-service (denial-of-service attacks) e altri comportamenti dannosi.
- I documenti di patch potrebbero non avere una dimensione massima definita nel formato del documento di patch. I server potrebbero voler stabilire la propria dimensione massima per i documenti di patch per proteggersi da attacchi che utilizzano documenti di patch molto grandi e rifiutare documenti di patch troppo grandi con il codice di stato 413 (Request Entity Too Large).
- I progettisti di applicazioni dovrebbero considerare l'impatto delle operazioni di patch sulle risorse che potrebbero essere distribuite su più posizioni. Ad esempio, una patch potrebbe avere successo su una copia di una risorsa ma fallire su un'altra, causando una divergenza dello stato delle risorse (resource state divergence).