it-swarm-eu.dev

Perché qualcuno dovrebbe bloccare tutti i metodi diversi da GET e POST in un'applicazione RESTful?

TL; DR:

Esiste un motivo valido per richiedere a un fornitore di software di smettere di usare i metodi HTTP PUT e DELETE in un'applicazione Web e di utilizzare solo GET e POST? L'applicazione utilizza i framework per whitelist percorsi e metodi di richiesta consentiti.

In altre parole, c'è qualche differenza dal punto di vista della sicurezza nel consentire la cancellazione di un record tramite i metodi DELETE o POST senza modificare il codice e i controlli di sicurezza in esso?

Domanda completa

I nostri clienti hanno configurato la loro istanza Tomcat con quanto segue, secondo lo standard aziendale:

<security-constraint> 
    <web-resource-collection> 
        <web-resource-name>restricted methods</web-resource-name> 
        <url-pattern>/*</url-pattern> 
        <http-method>CONNECT</http-method> 
        <http-method>PUT</http-method> 
        <http-method>DELETE</http-method> 
        <http-method>OPTIONS</http-method> 
        <http-method>TRACE</http-method> 
    </web-resource-collection> 
    <user-data-constraint> 
        <transport-guarantee>CONFIDENTIAL</transport-guarantee> 
    </user-data-constraint> 
    <auth-constraint /> 
</security-constraint> 

Questo, tra i Http Header Security Filter configurazione, ha rotto la nostra applicazione.

La nostra applicazione fornisce le stesse funzionalità HTTP Header security in Spring Security. Inoltre, la nostra applicazione è RESTful, quindi utilizziamo ampiamente i metodi PUT e DELETE per il caricamento dei file. Nelle versioni future, stiamo anche pianificando di utilizzare websocket (ma da una ricerca, non usano CONNECT, che è per il proxy).

Il nostro cliente ha dichiarato che dovrà sollevare un'eccezione politica nella produzione per rimuovere le linee offensive dalla configurazione Tomcat e far funzionare l'applicazione.

La politica delle eccezioni di sicurezza viene attivata quando le applicazioni del fornitore non soddisfano i requisiti di sicurezza in modo che 1) la risoluzione del problema non possa essere eseguita nei tempi previsti e 2) non sia stata rilevata alcuna vulnerabilità evidente. Le politiche di eccezione richiedono l'approvazione del senior management.

Tuttavia, le eccezioni alla politica di sicurezza impongono al cliente di coinvolgere il fornitore entro 6 mesi nel "risolvere il problema di sicurezza". Entro 6 mesi, il fornitore deve fornire costi e termini per rispettare la politica di sicurezza.

Ciò significa che torneranno da me chiedendomi un preventivo per far funzionare l'applicazione con il filtro del metodo HTTP abilitato e il filtro di sicurezza dell'intestazione HTTP.

Non voglio fare loro loro un favore e cambiare tutte le chiamate Ajax da schemi RESTful a GET/POST, nemmeno per soldi se possibile. Vorrei invece dimostrare che la loro implementazione della sicurezza non è solo incompatibile, ma ridondante, per quanto riguarda le implementazioni di sicurezza all'interno dell'applicazione.

Se stabiliamo un precedente nel fare questo cliente un favore con le richieste PUT e DELETE, dovremo affrontare richieste come "essere compatibile con il mio quadro/politica/ambiente" da una vasta base di clienti (tutte le banche e gli istituti finanziari). In futuro, ciò potrebbe andare contro la nostra gestione dei costi.

La domanda è, come nel TLDR, che l'utilizzo dei metodi PUT e DELETE da soli, indipendentemente dalle funzionalità di sicurezza dell'applicazione, potrebbe rappresentare un rischio per la sicurezza?

Se viene dimostrato che l'unico verbo HTTP non rappresenta un rischio per la sicurezza, sarò in grado di sollevare una politica di eccezione permanente e confront il personale IT con solide argomentazioni.

Modificare

Lavoro in una fabbrica di software che distribuisce la stessa istanza di prodotto a un gran numero di clienti e al nostro cloud. Stiamo utilizzando pienamente tutti gli strumenti che abbiamo a bordo, incluso il modello REST. Stiamo programmando di utilizzare HATEOAS, WebSocket, download di file riprendibili e tutto ciò che la tecnologia web può offrirci per offrire meglio esperienza. Sì, sembra una linea di marketing. Comunque, la sicurezza è ancora una preoccupazione nei nostri prodotti.

Sospetto che questo sia il caso di qualcuno che applica con zelo "buone pratiche" che non capiscono.

Attacco manomissione del verbo HTTP

Il motivo per cui esiste questa best practice è a causa dell'attacco manomissione del verbo HTTP. Da questo articolo :

Molti meccanismi di autenticazione del server Web utilizzano l'autenticazione basata su verbi e controlli di accesso. Ad esempio, un amministratore può configurare un server Web per consentire l'accesso senza restrizioni a una pagina Web utilizzando richieste HTTP GET, ma limitando i POST solo agli amministratori. Tuttavia, molte implementazioni di meccanismi di sicurezza basati su verbi impongono le regole di sicurezza in modo non sicuro, consentendo l'accesso a risorse limitate utilizzando metodi HTTP alternativi (come HEAD) o persino stringhe di caratteri arbitrarie.

Quindi qualcuno ha deciso che, poiché alcune app sono scritte male, tutte le app dovrebbero essere vietate dall'accettazione di verbi HTTP diversi da GET o POST, perché ... sai ... mumble mumble SICUREZZA !!


La mia opinione (possibilmente incompleta/errata, si prega di inviare commenti) :

  • Il contenuto HTML/CSS/js puro dovrebbe essere limitato a GET e POST perché questi sono gli unici verbi consentiti nelle specifiche HTML .
  • Le API (AJAX, REST) ​​dovrebbero essere autorizzate a usare qualsiasi verbo dalle specifiche HTTP , che dicesse:
    • Tieni presente che anche se il tuo livello applicazione applica correttamente i controlli di accesso basati su verbi, il tuo front-end del server web potrebbe non farlo, quindi devi ai tuoi clienti fare alcuni test di sicurezza e assicurarti che l'app applichi i controlli di accesso e autenticazione appropriati su tutti i verbi supportati. Consiglio di seguire la guida ai test OWASP .

Sembra che la tua app vada bene e che il tuo cliente abbia una politica di sicurezza troppo zelante.


A parte, HEAD è un esempio interessante; alcuni scanner di sicurezza sembrano lamentarsi se la tua app risponde a HEAD richieste, perché alcune app restituiranno intestazioni valide senza invocando i controlli di autenticazione appropriati. Tuttavia, le app progettate in modo più appropriato elaboreranno un GET completo e restituiranno solo le intestazioni, incluso il content-length: corretto. Quindi, per le app che usano framework moderni, probabilmente non c'è modo di bypassare la logica di autenticazione sul controller GET. Esegui alcuni test rapidi! (Grazie @ usr-local-ΕΨΗΕΛΩΝ per averlo segnalato nei commenti. Vedi questo post Stack Overflow per i dettagli su come lo gestisce MVC Spring.)

26
Mike Ounsworth

Probabilmente, DELETE e PUT sono più sicuri di GET/POST perché non possono essere utilizzati negli attacchi CSRF. Inoltre, probabilmente, DELETE e PUT dovrebbero essere comunque protetti da CSRF, poiché è male basare la sicurezza della propria applicazione sul presupposto che ogni implementazione del browser in circolazione segua gli standard. Ma non è raro che le applicazioni non abbiano quella protezione, quindi forse è questo il pensiero dietro il divieto, anche se sto raggiungendo un po 'qui.

O forse hanno semplicemente disabilitato tutti i metodi di cui non avevano bisogno (il che è una buona pratica) e nel tempo si sono trasformati da un default in una regola non violabile.

1
Tgr

L'API remota può essere progettata in questo modo, quindi qualsiasi altro metodo http tranne GET o POST non vengono utilizzati, ad esempio:

DELETE /item/123

può essere:

GET /delete/item/123

Ad ogni modo, dovrai leggere una specifica API e capire come aggiungere o eliminare elementi, quindi è argomento 50/50 che uno è meglio di un altro. Preferisco avere solo GET e POST.

0
Michael Quad

OWASP consiglia di bloccare i percorsi non utilizzati nel modo descritto nella domanda.

Limita i metodi HTTP

  • Applicare una lista bianca dei metodi HTTP consentiti, ad es. OTTIENI, POST, PUT.
  • Rifiuta tutte le richieste che non corrispondono alla whitelist con il codice di risposta HTTP 405 Metodo non consentito.
  • Assicurarsi che il chiamante sia autorizzato a utilizzare il metodo HTTP in entrata sulla raccolta di risorse, sull'azione e sul record
0
GreenAsJade

Raccomando di coinvolgere presto il team legale aziendale, in modo che qualcuno si concentri sugli aspetti aziendali delle discussioni a venire.

Come parte della politica di eccezione di sicurezza, il personale dei nostri clienti è obbligato a coinvolgere il fornitore nel "risolvere il problema di sicurezza" entro 6 mesi.

Ciò significa che torneranno da me chiedendo di far funzionare l'applicazione con il filtro del metodo HTTP abilitato e il filtro di sicurezza dell'intestazione HTTP.

Non voglio fare loro un favore e cambiare tutte le chiamate Ajax da schemi RESTful a GET/POST, nemmeno per soldi.

Il tuo cliente sta ovviamente gestendo la propria burocrazia, applicando una politica inflessibile. Credi di avere tre possibili percorsi:

  1. Convincili a cambiare la loro politica.
  2. Apporta il cambiamento indesiderato.
  3. Rischio di perderli come cliente.

Anche se ti sembra una decisione logica e tecnica, cambiare le politiche richiede una buona dose di litigi politici. La persona con cui hai a che fare dall'altra parte della discussione può o meno avere la posizione nella sua azienda necessaria per presentare una richiesta del genere. Potrebbe non voler perdere tempo a combattere la propria burocrazia per il cambiamento. La sua vita potrebbe essere notevolmente più semplice se cambia fornitore e usa il prodotto di qualcun altro che già rispetta le loro politiche. Peggio ancora per te, la vita del suo capo sarà quasi sicuramente più facile se cambierà semplicemente i venditori.

Sarebbe irresponsabile da parte tua pensare di riuscire a farli cambiare la loro politica senza fare una seria pianificazione per gli altri risultati.

I buoni clienti sono abbastanza difficili da trovare. Lo devi alla tua azienda per valutare attentamente il rischio di perderne uno.

0
John Deters