Come sapere se una pagina Web ASP è vulnerabile all'iniezione SQL?

Question

Come sapere se una pagina Web ASP è vulnerabile all'iniezione SQL?

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

1

Ho alcune esperienze di lavoro con applicazioni Web PHP vulnerabili all'iniezione SQL e sfruttano questo tipo di vulnerabilità con successo ma non ho mai provato a farlo su un'applicazione web basata su ASP. Quando proviamo a scoprire se un'applicazione web PHP è vulnerabile all'iniezione SQL, di solito aggiungiamo un solo preventivo alla fine di un parametro di input come questo:

http://example.com/index.php?id=1'

e se otteniamo un errore del genere:

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ''' at line 1

sappiamo che è vulnerabile. In alcuni casi otteniamo una pagina vuota o mancano alcuni dati sulla pagina che possono significare che è vulnerabile.

Quindi ecco la mia domanda: se aggiungo una virgoletta singola alla fine di un parametro di input in una classica pagina Web ASP e ottengo una pagina vuota o mi manca alcuni dati su quella pagina, vuol dire che è vulnerabile a SQL iniezione? Esistono altri modi per sapere se esiste una vulnerabilità di SQL injection in un'applicazione Web ASP?

sql-injection web-application classic-asp

posta sherl.lol 19.11.2017 - 18:36

fonte

2 risposte

1

L'iniezione di Sql è in SQL injection. È indipendente dal tuo framework web. Se lo sviluppatore non ha vincolato i parametri sono potenzialmente vulnerabili. Uno dei due metodi che hai citato è probabile che funzioni su ASP come su PHP.

Tuttavia è improbabile che la classica applicazione ASP stia usando MySql, molto più probabile che stia usando Sql Server, forse anche MS Access. Ciò ti fornirà alcune più sottili differenze su come sfruttare eventuali vulnerabilità che potresti trovare.

risposta data 21.11.2017 - 00:18

fonte

Leggi altre domande sui tag sql-injection web-application classic-asp

Possibile perdita di metadati durante l'analisi forense Perché il certificato client con l'handshake TLS?

score 1 · Accepted Answer

Mi dispiace, voglio espandere un po 'il tuo processo di pensiero. Non è solo un 'alla fine. Voglio dire, è buono, veloce nel trovare una percentuale decente dei buchi.

Lasciatemi dare un esempio di una vulnerabilità che questo approccio non trova:

url: http://www.somesite.com/page.asp?name=kevin&status=live

--- code behind the scenes: ---
string table = "history"
if (status == "live") table = "current"
string sqlCmd = "select * from " + table + " where name = '" + name + "'"

... vedi il problema? L'ultimo parametro nel tuo url specifica lo stato, e il codice sta semplicemente usando un "è X o no?" logica ad esso - non inserisce il valore reale nell'istruzione SQL, quindi non è vulnerabile. Ma il altro parametro è inserito nell'istruzione SQL raw - che lo rende vulnerabile all'attacco di un'iniezione. Così mentre:

http://www.somesite.com/page.asp?name=kevin&status=live'

... non avrebbe un errore, questo sarebbe:

http://www.somesite.com/page.asp?name=kevin'&status=live

Quindi, realisticamente, se stai cercando le vulnerabilità di SQL injection, devi provare tutti i parametri nell'URL - anche i parametri che sono opzionali e talvolta non sono specificati.

Punto finale: se si ha accesso al codice sorgente, è più facile trovare questo genere di cose guardando effettivamente il codice. Fondamentalmente, se stai costruendo istruzioni SQL raw e poi chiamate EXEC, probabilmente hai dei problemi.