Indirizzamento alla vulnerabilità dei parametri del corpo accettati nella query

Questa vulnerabilità è considerata "bassa" e presenta un punteggio CVSS di 5.0. Il pen-test prende una pagina esistente e cambia semplicemente il verbo nell'invio, passando il payload del form nella stringa della query. Se il sito web genera un errore o visualizza una pagina diversa da quella normale, è un PASS. Se il sito Web restituisce una pagina sostanzialmente simile alla pagina normale, si tratta di un errore.

I gestori per le richieste POST hanno spesso attenuazioni diverse; ad esempio, CSRF è spesso implementato per POST e non per GET. Modificando il verbo, un utente malintenzionato potrebbe potenzialmente aggirare il controllo. Un esempio può essere trovato nel database di vulnerabilità comuni, qui , se sei curioso di sapere se questo è un problema.

Potresti avere una vulnerabilità se hai utilizzato ActionName attributo per mappare GET e POST a diversi metodi e i metodi hanno filtri diversi (ad esempio POST ha il AuthorizeAttribute e GET non lo fa). Sarebbe una supervisione piuttosto seria e avrebbe bisogno di essere corretto prima di chiudere questo problema.

D'altro canto, questo tipo di test può generare falsi positivi, specialmente nelle pagine in cui il contenuto pubblicato non ha un effetto immediato sull'esperienza utente.

Se mi sono imbattuto in questo rapporto per un sito MVC, vorrei solo verificare che ci fosse una restrizione verb sul metodo di azione, quindi contrassegnare l'elemento come "falso positivo" e andare avanti, senza pensarci troppo , per ragioni che il PO ha spiegato.

Se non c'è una restrizione verbale, dovrai aggiungerla (con un HttpPostAttribute ), o trovare una giustificazione sul motivo per cui la pagina / gestore non è sensibile o non è meno vulnerabile quando si accede tramite GET.

"parametri del corpo" è almeno una terminologia insolita. Potrebbe non essere del tutto sbagliato, se è la terminologia del quadro specifico. Nello sviluppo web comune, non esiste una cosa del genere.

Il difetto di sicurezza è qui che un utente malintenzionato può fornire qui una query sql incorporata nel modulo. Ad esempio, immagina una query come

SELECT 1 FROM users WHERE user='$_GET[user]';

Se l'attaccante dà una stringa

anything'; UPDATE users SET password='cr4ck';

al campo utente, tramite una richiesta GET o POST basata su script, può cambiare tutte le password in "cr4ck".

La protezione è abbastanza semplice, tutto ciò che viene dal browser e va al db, dovrebbe essere quotato sql. Non è così banale se il framework che stai usando non gli piace molto, per esempio gioca cinquanta volte con le variabili in tutto il codice fino a quando non saranno fatte su una query sql reale.

This vulnerability is considered "low" and has a CVSS score of 5.0. The pen test takes an existing page and simply changes the verb in the submit, passing the form payload in the query string. If the web site raises an error, or displays a page that is different from normal, it is a PASS. If the web site returns a page that is substantively similar to the normal page, it is a FAIL.

Se stai usando MVC puoi aggiungere Attribute [HttpGet] o [HttpPost] per ogni metodo che sei sicuro, voglio dire che questo metodo non risponderà se è richiesto come GET e tu tagghi il metodo come HttpPost.