Senza contesto, presumo che l'autore si riferisca a campi di input in un'applicazione client. L'esempio più semplice da utilizzare sarebbe un modulo in una pagina HTML in un'applicazione web, sebbene ciò che sto per descrivere sia efficace praticamente per qualsiasi tipo di applicazione client.

Dato questo contesto, la risposta è no, non esiste una lunghezza massima del campo di input sufficientemente breve da proteggerti da SQL injection, perché non controlli la lunghezza massima del campo di input . L'attaccante lo fa. Quando il modulo contenente il campo di input si trova sul client (come in una finestra del browser sulla macchina dell'aggressore) è al di fuori del limite di fiducia e fuori dal tuo controllo. Può essere manipolato in qualsiasi modo l'aggressore vuole o ha bisogno, o evitato completamente. Ricorda, per un'app Web, tutto ciò che ottieni è una richiesta HTTP. Non hai idea di come sia stato creato e non hai motivo di credere che tutto ciò che hai chiesto di fare al browser sia realmente accaduto, che qualsiasi controllo di sicurezza lato client sia stato effettivamente eseguito, che qualsiasi cosa nella richiesta sia come inteso o in alcun modo sicuro.

Quindi no, la lunghezza del campo di input non è un meccanismo di prevenzione di SQL injection valido e mai, mai fidarsi dell'input che attraversa un limite di sicurezza senza convalidarlo.

No, non esiste una lunghezza troppo breve per essere sfruttabile (almeno in alcune situazioni).

Un filtro di lunghezza non è una protezione valida contro l'iniezione SQL e le istruzioni preparate sono davvero solo una difesa adeguata.

Un filtro di lunghezza è comunque una buona misura come difesa in profondità (così come i filtri interi, i filtri alfa, ecc.). Ci sono molte situazioni in cui ad es. un input valido non potrebbe mai essere superiore a 30 caratteri, ma dove uno sfruttamento significativo richiede di più. Dovrebbe (ma probabilmente non lo è) essere ovvio che qualsiasi filtraggio come difesa in profondità deve avvenire lato server poiché qualsiasi cosa lato client può essere semplicemente aggirata.

Bypass restrizione

Le clausole di restrizione (ad esempio AND / OR ) possono essere ignorate da due caratteri, il che può causare danni reali, non solo una query fallita. L'esempio più semplice è un accesso (altri esempi sarebbero l'eliminazione non autorizzata di dati aggiuntivi):

  SELECT * FROM users WHERE userid = [id] AND password = [password]  

Iniezione:

  id = 1 # password = wrong_password  

Payload: 2 caratteri

DoS

Gli attacchi DoS richiedono pochissimi caratteri. In un esempio MySQL, sono necessari 7 per la chiamata effettiva + x per i secondi dati + tutto ciò che è necessario per poter chiamare la funzione e correggere la query.

Esempio:

  SELECT * FROM users WHERE userid = [id]  

Injection (questa è un'iniezione valida, una forma più lunga sarebbe 1 AND sleep (99) ):

  sleep (99)  

Payload: 9 caratteri

Lettura dati

Se i dati viene visualizzato, la lunghezza dipende principalmente dal nome della tabella e della colonna. Presumo che il conteggio delle colonne sia uguale per tutte le tabelle (può succedere e salva i caratteri).

Esempio :

  SELEZIONA * DA commenti WHERE commentid = [id]  

Iniezione:

  1 unione seleziona * dagli utenti  

Payload: 27 caratteri.

Modifica dati

È anche possibile apportare modifiche non autorizzate al database con pochi caratteri.

Esempio:

  UPDATE users SET password = '[password]' WHERE id = [id]  

Iniezione (nella password):

  ', isadmin =' 1  

Payload: 12 caratteri

Funzionerebbe anche un bypass delle restrizioni (il risultato è che tutte le password ora sono vuote *):

  '#  

Payload: 2 caratteri

_{* L'esempio della password è usato per semplicità; le password dovrebbero essere sottoposte ad hashing rendendo impossibile l'esempio. L'esempio si applica ancora in tutte le situazioni simili (aggiornamento di un nome utente, aggiornamento delle autorizzazioni e così via)}

campi di input più piccoli possibile per ridurre la probabilità che un hacker sia in grado di spremere il codice SQL nel campo senza che venga troncato (il che di solito porta a un errore di sintassi T-SQL).

IMHO, questa è solo una merda. Usare la lunghezza dei campi di input per proteggere dall'SQL injection è un pessimo consiglio:

• L'unico modo corretto per proteggere dall'SQL injection è l'uso di un'istruzione preparata. I dati di input sono un parametro della query e non verranno mai utilizzati come testo SQL.
• La dimensione di un campo deve essere controllata lato server perché non puoi mai fidarti di ciò che viene fornito in una richiesta - potrebbe essere contraffatta - e dovrebbe essere utilizzato per disinfettare i dati prima dell'uso nel livello aziendale o nell'archiviazione del database.
• Consiglio di utilizzare qualcosa di diverso dalle best practice crea confusione per gli sviluppatori alle prime armi.

Considera la query:

  seleziona * da tweetsWHERE RowNum > = [offset] AND RowNum < [offset] + [limit]  

Se potessi inserire un singolo non intero (ad esempio, la lettera "a") per offset , la query risulterebbe in una sintassi errore e nessun post verrebbe visualizzato dando il tuo requisito "risultati non previsti dalla progettazione" per causare danni. Se puoi iniettare una stringa vuota, ottieni lo stesso effetto con un payload di lunghezza zero. Inserire un commento finale sarebbe uno spreco di due caratteri;)

Un utente malintenzionato può sfruttare questo in un attacco Denial of Service (diversamente da un allagamento di rete generalmente associato a DoS, tuttavia ancora un DoS). A seconda del servizio negato, ciò potrebbe essere catastrofico.

Poiché altre risposte suggeriscono che la lunghezza del campo non ha alcuna incidenza sull'impatto di SQL injection. Le istruzioni preparate e parametrizzate sono la strada da percorrere come indicato nel Cheat Sheet di OWASP SQL Injection Prevention.

No.

Semplice esempio di iniezione SQL di un carattere:

  ` 

Sarebbe generato un errore sarebbe un esempio di "restituzione di risultati non previsti dalla progettazione". Molte volte gli errori possono essere utilizzati per ottenere informazioni che aiuteranno in seguito in un exploit.

Sì.

La lunghezza massima è zero. L'unico modo per rendere sicuro l'input non attendibile tramite la lunghezza massima, senza altre convalide o controlli, è ignorare completamente l'input a partire dall'indice 0.

Ci sono molte altre (migliori) risposte qui, ma questa serve a rispondere alla domanda teorica su come stare al sicuro quando la lunghezza del campo è l'unico strumento a tua disposizione.

La lunghezza di un campo non avrà nulla a che fare con l'iniezione SQL, perché un attacco di questo tipo funziona semplicemente commentando il codice precedente e avviando il codice di attacco, quindi la lunghezza di qualsiasi campo non avrà effetto su questa strategia.

C'è molta teoria qui ma nessun vero esempio. Quando ho trovato una vulnerabilità di sql injection nel mondo reale (ora corretta), ho provato a utilizzare campi di input lunghi circa 30 caratteri. Questo è stato molto frustrante perché mi ci è voluto un po 'per capire che tutto dopo 30 caratteri era stato eliminato e 30 caratteri non mi lasciavano molto spazio.

(molti esempi di sql injection hanno sql semplice "come select * from table dove id = @id", sql del mondo reale di solito sarà molto più complicato)

Puoi ottenere fantasia con il tuo input e un esperto di sql potrebbe probabilmente utilizzare alcuni trucchi per ridurre il conteggio del carico utile. Ma non importa quanto tu sia difficile se vuoi selezionare un nome di tabella lungo, avrai bisogno di molti caratteri per questo.

Comunque, quando sono passato a utilizzare un campo di input con oltre 1k caratteri Ho trovato molto per sql injection.

Detto questo, come molti commentatori sopra di me hanno detto, la migliore difesa contro sql injection sono le dichiarazioni preparate