it-swarm.dev

In che modo i metodi HTTP PUT e DELETE sono insicuri, se lo sono davvero?

Se ho davvero bisogno di usare questi metodi, come posso assicurarmi che siano sicuri?

Modifica: esiste un collegamento o una fonte in cui posso vedere come assicurarsi che i metodi 'PUT' e 'DELETE' non siano in grado di eliminare o aggiornare le risorse, ma i servizi e i servlet sono ancora in grado di usare PUT e DELETE.

I seguenti servizi utilizzano i metodi HTTP PUT e DELETE

https://developers.google.com/drive/v2/reference/files/delete

http://developers.facebook.com/docs/reference/api/Comment/

http://docs.aws.Amazon.com/AmazonS3/latest/API/RESTObjectDELETE.html

http://www.salesforce.com/us/developer/docs/api_rest/index.htm

http://developer.tradeshift.com/rest-api/#tsapi.conventions

http://developer.linkedin.com/documents/groups-api#create

https://developer.Paypal.com/webapps/developer/docs/api/#delete-a-stored-credit-card

Quindi, chiaramente deve esserci un modo per assicurarsi che PUT e DELETE possano essere usati senza danneggiare i file di risorse come HTML, CSS, JS o immagini.

9
gurvinder372

PUT e DELETE non sono intrinsecamente insicuri, ad esempio vengono utilizzati senza problemi in molti servizi REST .

Nella mia pratica il problema principale relativo a questi verbi HTTP (a parte i comuni problemi di autenticazione e autorizzazione) era che gli operatori del server non erano a conoscenza della loro esistenza introducendo la possibilità di HTTP Verb Tampering . In sintesi, ciò significa che il controllo degli accessi è stato implementato sulla base di una lista nera dei verbi HTTP ma alcuni verbi meno noti mancavano da questo elenco, consentendo il bypass del controllo degli accessi.

Vorrei sottolineare che molti server Web implementano i loro verbi HTTP personalizzati (a volte privi di documenti), quindi questo tipo di "Controllo degli accessi basato sui verbi" non sembra comunque un'ottima idea.

11
buherator

I metodi HTTP hanno poco a che fare con la sicurezza in sé e per sé. Un metodo come DELETE /users/1 potrebbe essere facilmente implementato come POST /users/1/delete o anche GET /users/1/delete (I GET non dovrebbero mai avere effetti collaterali, ma ciò non impedisce comunque ad alcuni sviluppatori di farlo).

Dovresti quindi trattarli in modo simile a qualsiasi altro metodo HTTP. I GET non dovrebbero cambiare lo stato del server, quindi in genere dovresti solo verificare che il client abbia accesso in lettura alla risorsa richiesta. I PUT dovrebbero essere usati per aggiornare una risorsa completamente sul posto (anche se spesso sono usati in modo simile al verbo PATCH), e quindi dovresti assicurarti che il client abbia i privilegi per farlo. Allo stesso modo, DELETE deve essere inviato per richiedere l'eliminazione di una risorsa. Quindi si desidera assicurarsi che un utente disponga dell'autorizzazione per farlo.

In breve: tratta i verbi come descrittori del tipo di azione che l'utente desidera eseguire. Autenticarli e autorizzarli a eseguire queste azioni come richiesto dai parametri di sicurezza della propria specifica applicazione.

10
Stephen Touset

Dalla guida ai test OWASP:

Alcuni di questi metodi possono potenzialmente rappresentare un rischio per la sicurezza di un'applicazione Web, in quanto consentono a un utente malintenzionato di modificare i file archiviati sul server Web e, in alcuni scenari, rubare le credenziali degli utenti legittimi. Più specificamente, i metodi che dovrebbero essere disabilitati sono i seguenti:

  • PUT: questo metodo consente a un client di caricare nuovi file sul server Web. Un utente malintenzionato può sfruttarlo caricando file dannosi
    (ad es. un file asp che esegue comandi invocando cmd.exe) o semplicemente utilizzando il server della vittima come repository di file

Detto questo, in realtà ci sono due cose di cui devi occuparti.

  • Se desideri consentire a questi utenti di creare nuovi contenuti, assicurati di consentirli solo agli utenti autenticati di cui ti fidi. Questi utenti dovrebbero essere considerati attendibili nella misura in cui si consentirebbe loro di avere un account FTP.
  • Se permetti loro di modificare il contenuto esistente, assicurati di limitarlo in modo tale che possano effettivamente solo sovrascrivere determinate risorse esistenti e nient'altro.

Assicurati anche di utilizzare SSL/TLS.

7
Lucas Kauffman

per i record: RFC 2616 Hypertext Transfer Protocol HTTP/1.1/Method-Section

una RICHIESTA è una richiesta da un client al server e non dice molto su cosa farà il server con quella richiesta; i possibili metodi non devono essere implementati a livello di server.

quindi se vai su myserver.com e chiedi "ELIMINA/blah" myserver.com potrebbe semplicemente dire: "grazie, signore, e buona giornata".

9.6 PUT

Il metodo PUT richiede che l'entità inclusa sia archiviata nell'URI di richiesta fornito.

9.7 ELIMINA

Il metodo DELETE richiede che il server Origin elimini la risorsa identificata dall'URI di richiesta. Questo metodo può essere ignorato dall'intervento umano (o altri mezzi) sul server Origin. Non è possibile garantire al client che l'operazione sia stata eseguita, anche se il codice di stato restituito dal server di origine indica che l'azione è stata completata correttamente