moduli Sqlmap e multipart / form-data

Question

moduli Sqlmap e multipart / form-data

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

2

Sto lavorando su un po 'di sicurezza per un sito web che è costruito in ASP classico e MS SQL 2000.

Ho trovato con successo un paio di moduli viziati che hanno permesso l'inserimento di SQL nei campi del modulo usando Sqlmap con i seguenti comandi:

python sqlmap.py -u "URL TO FORM" --forms --level=5 --risk=3 --batch

python sqlmap.py -u "URL TO FORM" --forms --dbs --level=5 --risk=3 --batch

Ora sto provando a controllare un altro modulo che utilizza il tipo di codifica multipart / form-data.

Sqlmap non può iniettare nulla in questo modulo ma poiché sta usando un diverso tipo di codifica non so se è a causa del tipo di codifica o perché Sqlmap non può gestire questo tipo di modulo?

Il modulo usa query concatenate quindi nella mia mente dovrebbe essere non sicuro, ma il risultato Sqlmap mi ha gettato un po '.

Qualcuno sa se devo usare un comando diverso su questo tipo di modulo o Sqlmap non può essere usato qui?

Solo un rapido aggiornamento. Questo è il messaggio che ricevo da Sqlmap:

[WARNING] heuristic (basic) test shows that (custom) POST parameter 'MULTIPART #1*' might not be injectable

Quindi continua a eseguire i test fino a quando non ricomincia:

[WARNING] heuristic (basic) test shows that (custom) POST parameter 'MULTIPART #2*' might not be injectable

sql-injection penetration-test

posta Brigante 09.07.2013 - 15:48

fonte

2 risposte

Leggi altre domande sui tag sql-injection penetration-test

CRLF Iniezione nella pagina Web Qual è l'architettura più "più sicura" da eseguire in QEMU? [chiuso]

score 1 · Answer 1

Perché non lo fai manualmente? . È piuttosto semplice e ti darà una migliore comprensione di che tipo di filtro è presente nel back-end e che cosa può essere fatto per aggirarlo. In questo momento ti stai semplicemente affidando allo strumento per darti dei risultati. Se sei coinvolto nel testare la penna dell'applicazione, attenzione, potrebbero esserci ancora bug. E se lo fai per divertimento, perché non imparare pure.

Usa dati Burp o Tamper vedi la richiesta e la risposta, suona insieme ad essa e capirai meglio l'applicazione.

score 0 · Answer 2

Questo è un buon esempio del perché non si suppone che i penetratori possano dipendere completamente dagli strumenti poiché spesso portano a falsi negativi. In questo caso, un possibile parametro vulnerabile sarebbe considerato sicuro a causa dell'osservanza del suddetto tipo di "codifica" del modulo che getta fuori da SQL Map.

La mia raccomandazione sarebbe quella di utilizzare un proxy di intercettazione del traffico manuale come Burp Suite o Paros per poter meglio comprendere i dati comunicati e quindi modificarli.

Fare riferimento a un cheat di SQLI per la sintassi esatta da testare.