Come eseguire il test per la query di SQL injection

Come prevedi di usare le informazioni è il modo migliore di gestirle. Se stai cercando di assicurarti che nessuno stia usando e l'attacco SQL injection contro di te, la risposta non è cercare di rilevarlo con le blacklist. L'approccio corretto consiste nell'utilizzare funzionalità come le variabili di bind.

Se il tuo obiettivo è quello di fornire un sistema di avviso per qualcuno che cerca cose che non dovrebbero, il rilevamento di parole chiave SQL come "and, or, select, delete, where, update, drop" e simili può aiutare. Il problema con la lista nera ( l'igienizzazione della query SQL (lista nera) ) è duplice: probabilmente otterrai false positivi e probabilmente ti mancheranno gli attacchi ben offuscati. Anche se può darti un vantaggio nel rilevamento degli attacchi, ho scritto query che vanno al di là di questi filtri e sono diventato molto frustrato quando le normali frasi vengono bloccate quando compili i moduli.

sqlmap lo rende facile (aggiungi un * per ogni posizione di test):

sqlmap.py -v 4 -u http://example.com/category*/tutorials*/cooking*/
sqlmap.py -v 4 -u http://example.com/articles*/another-perspective-on-data*

-v 4 visualizzerà ogni richiesta GET su stdout in modo da poter vedere le richieste esatte e osservare come sta sondando sqlmap.

Quando un URL appare come questo significa che è stato riscritto. Su un webserver Apache è realizzato tramite il file htaccess usando mod_rewrite.

Ecco un esempio di riscrittura:

RewriteRule ^([a-z])-([0-9]).html$ /index.php?page=$1&id=$2 [L]

Tutti i caratteri diversi da quelli definiti nell'espressione regolare verranno filtrati. Viene utilizzato principalmente con le query GET e fornisce una certa protezione. Ma un'espressione regolare che non è abbastanza specifica potrebbe consentire un'iniezione.

Ecco un esempio di riscrittura vulnerabile:

RewriteRule ^([a-z.*])-([0-9]).html$ /index.php?page=$1&id=$2 [L]

Il test per un'iniezione SQL sarebbe simile a questo:

example.com/cate'gory/1234

Assumendo nessun'altra forma di protezione e non usando query parametrizzate o input di escape appropriati, quella query ti avviserà di una possibile iniezione SQL.

1) Non puoi rilevare in modo affidabile un tentativo di attacco analizzando staticamente il testo della richiesta.

2) I gestori di richieste scritte correttamente non hanno nulla da temere dagli attacchi di SQL injection.

Posso vedere due cose che potresti provare a fare.

Forse vuoi identificare richieste malevoli in modo da poter vietare gli IP di attacco. Sarebbe ragionevole farlo strumentando il codice di quotazione SQL (la parte che cita i dati in entrata in modo che sia sicuro inserirli in una query) per cercare elenchi di caratteri sospetti. Principalmente le cose che ti aspetti di inserire nelle query saranno semplici testo o numeri e trovare caratteri di punteggiatura è molto sospetto.

Forse ti piacerebbe avere un orologio da guardia posteriore per gli attacchi che avrebbero potuto riuscire, a causa di bug nell'elaborazione dei moduli. È necessario trattare tutte le query non riuscite come estremamente gravi, registrarle e inviare avvisi. La maggior parte dei tentativi di SQL injection falliscono perché stanno solo indovinando come strutturare l'SQL inserito.