Devo impedire l'invio di richieste GET per gli URL che normalmente vengono gestiti con la richiesta POST?

Se la transazione ha effetti collaterali, sì, dovresti configurare il tuo server web in modo che non elabori le richieste GET. Non dovresti consentire a nessuna richiesta GET di causare effetti collaterali sul tuo server.

Non posso puntare a nessun attacco particolare che causerà necessariamente problemi, ma ci sono vulnerabilità sottili se consenti all'elaborazione di una richiesta GET di causare effetti collaterali, quindi se permetti alle richieste GET di avere effetti collaterali, stiamo iniziando a scavalcare il territorio dei "draghi". Ad esempio, conosco un attacco sottile ai siti che utilizzano l'intestazione Referer per difendersi dagli attacchi CSRF e che consentono alle richieste GET di avere effetti collaterali. I browser non hanno implementato correzioni per fermare quell'attacco perché la reazione è "duh, le richieste GET non dovrebbero avere effetti collaterali, quindi è colpa del sito web". Quindi, piuttosto che entrare in un territorio potenzialmente pericoloso, ti suggerisco di configurare il tuo server web in modo che elabori queste richieste solo tramite POST, non tramite GET.

Ci sono una serie di motivi per usare POST:

1. Il browser avvisa in caso di nuovo invio.
2. La dimensione del contenuto non è limitata
3. Il caricamento dei file funziona solo tramite il POST
4. Alcuni programmi accelerano i tempi di risposta mediante il precaricamento delle pagine collegate, quindi attiva la richiesta fittizia.
5. L'URL non può essere inserito nei segnalibri, evitando l'invio accidentale (sebbene il token CSRF possa essere comunque limitato nel tempo).
6. I dati del modulo (che potrebbero includere token CSRF) non vengono visualizzati nella barra degli indirizzi, nei segnalibri, nella cronologia del browser o nei log del server.

POST non fornisce alcuna protezione notevole contro CRSF. Solo i token non guidabili possono farlo, come hai detto tu. Se utilizzi solo "POST" nei tuoi moduli, nessuno dei problemi elencati si applica a te perché gli utenti normali utilizzeranno la variante POST.

Ovviamente esiste la nozione di disabilitare le cose che non vengono utilizzate per ridurre le superfici attaccabili.

Il motivo per cui non dovresti usare il metodo GET per i dati sensibili sono già elencati sopra, quindi non lo scriverò di nuovo. E come capisco per impostazione predefinita la tua applicazione genererebbe una richiesta di posta per le risorse in questione. Alcuni motivi per cui dovresti comunque bloccare il metodo GET tramite la configurazione o programmaticamente

1. Pochi utenti tendono a aggiungere pagine ai segnalibri con i parametri nell'URL (anche le richieste di accesso). Pertanto, se l'applicazione non elabora la richiesta GET, il segnalibro non funzionerà e quindi non utilizzeranno realmente i segnalibri. Quindi evita l'esposizione di dati sensibili nell'URL
2. Quando si dispone di un'applicazione enterprise, lo stesso gestore di richieste può essere richiamato da diversi componenti dell'applicazione, quindi uno sviluppatore potrebbe utilizzare Post per richiamarlo, ma in futuro alcuni altri sviluppatori potrebbero utilizzare GET per richiamarlo. Quindi, tramite il diario del metodo GET, assicurerai che non superi il test dell'unità.

In conclusione, se il flusso delle tue applicazioni passa sempre attraverso il POST, il rifiuto di GET aggiungerebbe una quantità minima di protezione.

Lo vedrei sempre nelle WAF, inviare una richiesta con un verbo imprevisto è il 99% delle volte un bot o uno script kiddy. Se mai, funge da avvertimento se stai vedendo molti verbi imprevisti

Perché non limitare l'utilizzo di singole variabili alle loro fonti previste?

This request will be approved by server and action will be done

Sembra che non stiate definendo correttamente le variabili. Non hai menzionato quale lingua lato server stai usando, ma la maggior parte può distinguere tra GET e POST. Ad esempio, se ti aspetti una variabile chiamata "pippo" via POST, in PHP usando $ _POST ['pippo'] invece di $ _REQUEST ['pippo'] rimuoverà l'ambiguità.

Inoltre, supporterò di non elaborare il verbo imprevisto.

Se la tua applicazione è progettata per prevedere un tipo di comportamento in uso normale (ad esempio un POST) ma riceve qualcosa di inaspettato (ad esempio un GET in questo caso), hai anche uno scenario valido per rilevare utenti potenzialmente malintenzionati.

link

Dai un'occhiata al progetto AppSensor di OWASP se questa idea ti interessa.

-Michael

Un altro punto è impedire il raschiamento del sito. Se il tuo sito fornisce informazioni di alto valore, le persone potrebbero voler analizzare questi dati. È molto più facile da fare con GET quindi con POST.

Non sicurezza al 100%, ma ancora ...