GET e POST Intercambiabilità

Question

GET e POST Intercambiabilità

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

1

In alcune applicazioni, i metodi HTTP GET e POST possono essere usati in modo intercambiabile.

Ad esempio, l'applicazione potrebbe aspettarsi una richiesta POST, e il frontend invierà anche i dati in una richiesta POST, ma se la richiesta viene manomessa, i dati saranno accettati anche in una richiesta GET.

Un esempio di questo comportamento sarebbe Javas getParameter o PHP $_REQUEST , che forniscono entrambi i parametri GET e POST.

Questo è generalmente considerato un problema di sicurezza? È documentato da qualche parte, ad esempio come CWE o OWASP?
Questo problema ha un nome?
Quali sono i pericoli del POST per ottenere il downgrade? Un esempio che potrei pensare sarebbe la possibilità di sfruttare i problemi CSRF tramite i tag img , il che significa che un utente malintenzionato può caricare payload CSRF su siti Web in cui non possono pubblicare script, rendendo molto più facile sfruttare il problema. Ci sono altri vantaggi per gli attaccanti?
Che cosa - se del caso - sono i pericoli della modifica da GET a POST?

http web-application vulnerability

posta tim 30.07.2016 - 16:16

fonte

2 risposte

Leggi altre domande sui tag http web-application vulnerability

Il nome utente / password possono essere intercettati su un'app utilizzando il Wi-Fi pubblico? allegato inaspettato all'interno del PDF

score 2 · Answer 1

È una cattiva pratica in quanto rende lo sviluppo più confuso al fine di garantire che non vi sia sovrapposizione tra i possibili parametri GET e POST che vengono normalmente elaborati separatamente.

Rende anche leggermente più semplice per un hacker trarre vantaggio da una vulnerabilità nel tuo sito ma non crea violazioni da solo.

In un'applicazione Web ben organizzata, i parametri GET vengono utilizzati per il routing (selezione di pagine o moduli e opzioni pertinenti) mentre i parametri POST rappresentano effettivamente i dati inviati dall'utente. Seguendo questa semplice linea guida lo sviluppo è molto più organizzato, quindi più sicuro da errori da parte tua.

score 1 · Answer 2

Il OWASP ASVS fa menzione di questa vulnerabilità, vedi regola 11.1. Anche se non fa menzione di questa vulnerabilità a livello di metodo, allude che l'applicazione dovrebbe accettare solo set definiti di metodi di richiesta HTTP.

In genere lo faccio un po 'oltre e lego la guida nel OWASP Progetto AppSensor in cui è possibile utilizzare queste modifiche nei verbi HTTP previsti come potenziale punto di rilevamento.

Non credo ci siano dei veri e propri pericoli di un POST da OTTENERE il downgrade dal punto di vista del server. Finché proteggi contro l'inquinamento dei parametri e stai monitorando il traffico da una prospettiva di appensori, non ci sono danni. Ovviamente GET viene passato alla stringa di query e viene registrato da altri dispositivi nella catena. Questo è un problema con il lato client IMHO e potrebbe verificarsi solo se il codice (forms, html, javascript) è stato modificato (tramite MITM o tramite javascript errato dopo il rendering).