TL; DR:
C'è una ragione valida per chiedere a un fornitore di software di smettere di usare i metodi% PUT e DELETE in un'applicazione web e usare solo GET e POST ? L'applicazione utilizza 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 cambiare il codice e i controlli di sicurezza in esso?
Domanda completa
I nostri clienti hanno configurato la propria istanza Tomcat con quanto segue, in base allo 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 la configurazione Http Header Security Filter , ha interrotto la nostra applicazione.
La nostra applicazione fornisce le stesse funzionalità Sicurezza intestazione HTTP in Spring Security. Inoltre, la nostra applicazione è RESTful, quindi utilizziamo ampiamente i metodi PUT e DELETE per il caricamento di 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 affermato che dovrà generare un'eccezione di criterio nella produzione per rimuovere le righe incriminate dalla configurazione di 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 all'interno delle pianificazioni e 2) non venga rilevata alcuna vulnerabilità evidente. Le politiche di eccezione richiedono l'approvazione della direzione.
Tuttavia, le eccezioni della politica di sicurezza richiedono che il nostro cliente coinvolga il fornitore entro 6 mesi in "risoluzione del problema di sicurezza". Entro 6 mesi, il venditore deve fornire costi e scadenze per rispettare la politica di sicurezza.
Ciò significa che torneranno da me chiedendo un preventivo per far funzionare l'applicazione con il filtro dei metodi HTTP abilitato e il filtro HTTP Header Security.
Non voglio fare loro un favore e cambiare tutte le chiamate Ajax dai pattern RESTful a GET / POST solo, nemmeno per denaro, 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 creiamo un precedente per fare a questo cliente un favore con 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 le istituzioni finanziarie) . In futuro, ciò potrebbe rivelarsi contrario alla nostra gestione dei costi.
La domanda è, come nel TLDR, potrebbe utilizzare solo i metodi PUT e DELETE , indipendentemente dalle funzionalità di sicurezza dell'applicazione, rappresentare un rischio per la sicurezza?
Se è dimostrato che l'unico verbo HTTP non rappresenta un rischio per la sicurezza, sarò in grado di generare una politica di eccezione permanente e confrontare il personale IT con argomentazioni solide.
Modifica
Lavoro in una fabbrica di software che distribuisce la stessa istanza di prodotto a un gran numero di clienti e al nostro cloud. Utilizziamo pienamente tutti gli strumenti che abbiamo a bordo, incluso il modello REST. Stiamo pianificando di utilizzare HATEOAS, WebSockets, download di file ripristinabili e tutto ciò che la tecnologia web ci può offrire per offrire un'esperienza migliore. Sì, sembra una linea di marketing. In ogni caso, la sicurezza è ancora una preoccupazione nei nostri prodotti.