Dovrei proibire GET per il POST senza effetti collaterali di default?

Question

Dovrei proibire GET per il POST senza effetti collaterali di default?

#1 da (2 voti)
#2 da (1 voti)

3

Se una pagina web è sicura (nessun effetto sul lato servizio) ma usi POST parametri (per evitare problemi di lunghezza dell'URL), allora dovrebbe essere vietato chiamarlo usando GET ? O ogni pagina dovrebbe avere una sorta di "marcatore" che dice che è sicuro o non sicuro e proibisce GET solo su non sicuri ?

In primo luogo, alcuni refactoring vanno qua e là per avere solo GET e POST solo pagine (e non più "mix"), mentre il secondo porta a pagine potenzialmente dimenticate (quelle vecchie e quelle imminenti di nuovi sviluppatori) .

Ho letto il post correlato " Devo impedire l'invio di richieste GET per gli URL che normalmente vengono gestiti con la richiesta POST? " ma quella domanda era per non sicuro POST , che ovviamente deve vietare GET . Qui, si tratta di come gestire globalmente { sicuro POST che potrebbe essere chiamato da GET + safe GET + unsafe POST che non deve essere GET callable}.

http

posta Xenos 03.02.2017 - 12:15

fonte

2 risposte

Leggi altre domande sui tag http

Può un timestamp proteggere una firma con l'obsoleto SHA1? È considerato "hacking" se non è stata implementata un'autorizzazione? [chiuso]

score 2 · Answer 1

La distinzione tra GET e POST non riguarda solo la sicurezza. In termini di REST (il principio sottostante HTTP), il metodo GET è un'operazione "recupera le informazioni specificate nell'URL" mentre il POST è un "fa qualcosa alla risorsa nominata dall'URL" o, a volte "fa l'operazione nominata dal URL "operazione.

Se la tua operazione è sicura ma non è un recupero di informazioni, allora è semanticamente scorretto usare un'operazione GET. Se il recupero delle informazioni richiede una query che non rientra nel limite di lunghezza dell'URL, probabilmente è necessario strutturare meglio i dati in modo che le tue query siano meno complesse, i tuoi clienti apprezzerebbero non dover mescolare la struttura dei dati complessi solo per recuperare il informazioni di cui hanno bisogno.

Avere la stessa risorsa operata da più metodi HTTP (un "mix") è molto comune e raccomandata in REST. Ogni metodo generalmente fa cose diverse rispetto alla risorsa, ad esempio potresti avere un'API in cui PUT / transazione / 1 crea o aggiorna una transazione senza commit, PATCH / transazione / 1 pianifica azioni aggiuntive su una transazione non salvata, mentre POST / transazione / 1 esegue la transazione e la contrassegna come impegnata e GET / transaction / 1 per recuperare i dettagli della transazione.

Ci sono molti casi anche se non tutti i metodi hanno senso in una risorsa. In tal caso, probabilmente vorrai emettere una risposta HTTP 405 metodo non consentita.

Should I forbid GET for non-side effect POST by default?

In generale, non vuoi. Il fatto che tu pensi di farlo solitamente indica che potresti avere un odore di progettazione o potresti avere un'API non REST.

score 1 · Answer 2

Come hai detto, per le richieste POST sicure, non importa se è possibile accedervi tramite le richieste GET. Tuttavia, questo introduce un problema di usabilità dal punto di vista degli sviluppatori. Devono essere in grado di determinare in modo affidabile se una determinata richiesta è sicura o meno e di applicare coerentemente le regole corrette a tali pagine.

Se non riescono ad applicare correttamente una regola a una nuova pagina, o apportare una modifica che modifica una richiesta sicura in una non sicura su una pagina precedente senza aggiornare le regole, potresti potenzialmente avere problemi.

Pertanto, assicurando che tutte le richieste POST vengano considerate "non sicure", anche quando possono, in casi specifici, essere "sicuri" è l'opzione di sicurezza. Dà agli sviluppatori una classificazione molto semplice: se usa POST, non usa GET.

In alcuni casi ciò potrebbe comportare alcuni refactoring, ma questo sarebbe un compito una tantum, mentre tenere aggiornate le modifiche alle classificazioni sicure / non sicure sarebbe un'attività continuativa.