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

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

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

Vorrei sottolineare che molti web server implementano i propri verbi HTTP personalizzati (a volte non documentati), quindi questo tipo di "controllo degli accessi basato sui verbi" non sembra comunque una buona idea.

I metodi HTTP hanno poco a che fare con la sicurezza di per sé. Un metodo come DELETE /users/1 potrebbe facilmente essere 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 è sufficiente verificare che il client abbia accesso in lettura alla risorsa richiesta. I PUT dovrebbero essere utilizzati per aggiornare una risorsa interamente sul posto (sebbene siano spesso utilizzati anche in modo simile al verbo PATCH), quindi è necessario assicurarsi che il client abbia i privilegi per farlo. Allo stesso modo, è necessario inviare DELETE per richiedere l'eliminazione di una risorsa. Quindi vorresti assicurarti che un utente abbia il permesso di farlo.

In breve: tratta i verbi come descrittori del tipo di azione che l'utente desidera eseguire. Autenticali e autorizzali a eseguire queste azioni come richiesto dai parametri di sicurezza della tua particolare applicazione.

Dalla guida ai test OWASP:

Some of these methods can potentially pose a security risk for a web application, as they allow an attacker to modify the files stored on the web server and, in some scenarios, steal the credentials of legitimate users. More specifically, the methods that should be disabled are the following:

• PUT: This method allows a client to upload new files on the web server. An attacker can exploit it by uploading malicious files
  (e.g.: an asp file that executes commands by invoking cmd.exe), or by simply using the victim's server as a file repository

Detto questo ci sono in realtà due cose di cui devi aver cura.

• Se vuoi consentire a questi utenti di creare nuovi contenuti, assicurati che lo permetti solo per gli utenti autenticati di cui ti fidi. Questi utenti dovrebbe essere considerato attendibile nella misura in cui si consentirebbe loro di avere un Account FTP.
• Se vuoi consentire loro di modificare il contenuto esistente, assicurati di restringerlo in modo tale da poter effettivamente sovrascrivere solo alcune risorse esistenti e nient'altro .

Assicurati anche di utilizzare SSL / TLS.

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

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

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

9.6 PUT

The PUT method requests that the enclosed entity be stored under the supplied Request-URI.

9.7 DELETE

The DELETE method requests that the origin server delete the resource identified by the Request-URI. This method MAY be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the operation has been carried out, even if the status code returned from the origin server indicates that the action has been completed successfully