SQLi-protection ORDER BY

Naviga le tue risposte
4

Quale sarebbe un buon controllo per rimuovere tutte le possibilità di SQL-injection su un ORDER BY col dove col è una variabile non sicura?

Attualmente rimuovo [^A-Za-z0-9_] dalla stringa in php. È troppo paranoico o forse anche non abbastanza?

EDIT:

Giusto per chiarire: sto cercando un modo per rimuovere qualsiasi SQLi da un ORDER BY $unsafeVariable - non una soluzione generale di prevenzione SQLi. Sto già usando query preparate e pdo :: quote dove necessario, ma dato che avevo bisogno di includere una variabile non sicura in una dichiarazione order by ho pensato di chiedere un'opinione a qualcun altro.

    
posta Filip Haglund 30.01.2013 - 13:13
fonte

3 risposte

3

La soluzione migliore è se si conoscono tutte le colonne ORDER BY consentite in anticipo e si controlla la variabile $ non sicura rispetto a quella lista bianca.
Un'altra opzione: dopo aver rimosso tutti i caratteri non validi, controlla che $ non sicura sia una sottostringa della query che stai creando. Sarebbe estremamente difficile abusarne.

    
risposta data 30.01.2013 - 20:29
fonte
1

Per favore non sentire che sto dando solo pochi collegamenti e non spiegazioni. Ho pensato che tutte le risposte ci fossero in quei link e sarebbe bello piuttosto che copiare lo stesso testo qui. Se vuoi controllare di più sulla sicurezza, allora quei collegamenti saranno utili.
Basta controllare link e avere un'idea su come prevenire sqli in php.
Per ulteriori informazioni sulla sicurezza di php, leggi link .

    
risposta data 30.01.2013 - 13:28
fonte
0

Considero la tua soluzione come protezione di primo livello dall'iniezione SQL o da qualsiasi attacco di injection code (XSS), è un requisito per cancellare i dati di input dell'utente prima di inviarli al database, ho confuso con alcune persone che consigliavano query appena preparate (parametrizzate query) e utilizzando la procedura memorizzata, poiché non esiste una logica per inviare parametri non sicuri al database se è possibile pulirli in precedenza, ma, per una maggiore sicurezza, sono necessari anche i metodi menzionati.

(nota: l'idea alla base della query parametrizzata è che il database può distinguere tra la query originale e i dati utilizzati per creare quella query) (owasp, 2012) [4]

alcune regole che uso sempre:

  1. Utilizza l'ultimo aggiornamento / la tecnologia più recente (aggiorna frequentemente, installa patch e correzioni)
  2. Pulisci i dati di input dell'utente prima di utilizzarli nella query
  3. Utilizza un utente con privilegi ridotti durante la creazione di query dinamiche, elimina il privilegio non richiesto per la query di selezione
  4. Monitora l'integrità di file e dati critici.

Link utili:

risposta data 30.01.2013 - 20:00
fonte

Leggi altre domande sui tag

Dov'è il limite tra un attaccante e una vittima (zombi) in un attacco DDoS Quanto è visibile un attacco WPS con reaver?