Come posso impedire ai programmatori di scrivere codice vulnerabile all'iniezione SQL?

Question

Come posso impedire ai programmatori di scrivere codice vulnerabile all'iniezione SQL?

#1 da (24 voti)
#2 da (20 voti)
#3 da (8 voti)
#4 da (3 voti)
#5 da (1 voti)
#6 da (0 voti)
#7 da (0 voti)

11

A volte ti diverti e deleghi piccoli compiti ai programmatori junior. Ma se non presti abbastanza attenzione ti ritrovi con questo tipo di codice in produzione:

class DivtoggleController extends Zend_Controller_Action {

    public function closeAction() {
        /* ... code removed for brevity ... */

        $req = $this->getRequest();
        $formData = $req->getPost();

        $d = $formData['div'];
        $i = $formData['id'];

        $dm = new Model_DivtoggleManager();
        $rs = $dm->setDivToggleById($d, $i);

    }

}


class Model_DivtoggleManager extends Zend_Db_Table {

    public function setDivToggleById($div, $id) {
        $result = $this->getAdapter()->query(
           "update div_toggle set " . $div . "=1 where id=" . $id
        );
    }

}

Quindi, dato che ho rimosso per brevità la logica di autenticazione / gestione delle sessioni, chi può dirmi quale possibile problema ci potrebbe essere con questo campione?

sql php training

posta Roger Halliburton 14.04.2011 - 22:02

fonte

7 risposte

Leggi altre domande sui tag sql php training

Qual è il nome idiomatico di una variabile usa e getta? [chiuso] Come funzionano esattamente i diritti di codice esclusivo? [chiuso]

score 24 · Answer 1

Puoi insegnare loro. Tutti lo fanno all'inizio, anche tu. Se questo tipo di codice lo rende in produzione, è colpa della gente anziana; non junior.

Modifica

Una delle cose che ho fatto è che personalmente ho iniziato a chiedere proattivamente alle persone di rivedere il mio codice (compresi i ragazzi) prima di un rilascio. Il codice viene rivisto, i giovani lo vedono come un'esperienza di apprendimento, le persone perdono la paura della revisione del codice come punizione e iniziano a fare la stessa cosa.

score 20 · Answer 2

20

Inserisci il loro codice davanti ai loro occhi, quindi mostra loro come aggiustarlo. Ancora e ancora fino a quando non capiscono.

risposta data 14.04.2011 - 22:08

fonte

score 8 · Answer 3

Puoi imporre loro di prendere una lezione non appena entrano nella tua azienda, prima che abbiano accesso al controllo del codice sorgente, che li introduca alle iniezioni SQL, allo scripting cross-site, alla falsificazione delle richieste cross-site e ad altre vulnerabilità comuni. Copri gli esempi faccia a faccia, rompi il codice cattivo davanti a loro, fai in modo che rompano il codice sbagliato e indirizzali al sito OWASP per maggiori informazioni una volta "diplomati".

Puoi inoltre richiedere l'uso di una libreria personalizzata che gestisce questo per te, ma questa è solo una soluzione secondaria in quanto saranno sicuri di eseguire query personalizzate quando ciò diventa più conveniente.

Se possiedi le risorse, assicurati che più membri senior del team possano verificare le loro differenze prima di impegnarsi anche in questo caso.

La conoscenza è potere!

score 3 · Answer 4

Supponendo che sia l'insicurezza a cui altri hanno fatto riferimento, come sviluppatore di qualsiasi livello, è facile dimenticare che getPost () non sta proteggendo i dati per primi.

Un modo per aggirare questo è:

Scrivi una classe che ottiene tutti i dati POST / GET e li scrive come è in una classe Singleton chiamata 'insecure_data'. Quindi deselezionare gli array POST / GET.
Gli sviluppatori devono recuperare i dati POST / GET dall'array 'insecure_data', non gli array POST / GET.

Qualsiasi sviluppatore che recuperi qualcosa da un array chiamato 'insecure_data' e non si preoccupa di proteggerlo è ignorante o pigro. Se è il primo, fornire formazione, dopo di che deve essere il secondo - e quindi si dispone di un problema disciplinare, non di programmazione.

score 1 · Answer 5

Una delle migliori guide che ho letto sulla sicurezza web è questa guida alla sicurezza di Ruby on Rails . Sebbene sia Ruby on Rails, molti dei concetti si applicano a qualsiasi sviluppo web. Vorrei incoraggiare chiunque di nuovo a dare a questa guida una lettura.

score 0 · Answer 6

0

Il codice che hai collegato sopra è suscettibile a un attacco di SQL injection, perché gli input HTTP che stai utilizzando nella query non sono stati puliti con mysql_real_escape_string o con altri mezzi.

risposta data 14.04.2011 - 22:05

fonte

score 0 · Answer 7

Per quanto riguarda la tua (presumibilmente esagerata) "come posso fare in modo che i programmatori smettano di fare questa" domanda, direi che li sto mentendo regolarmente, spiegando attentamente il problema in questione (e le potenziali ricadute, ecc. ) e sottolineando l'importanza delle vulnerabilità del codice (sia in termini di SQL injection che di cross-site scripting, ecc.) è probabilmente la soluzione più sensata.

Se continuano a rovinare nonostante tutto quanto sopra (potresti voler controllare i loro commit, ecc. piuttosto che cercare "live"), allora il problema è che tu li mancano come mentori, o forse hanno bisogno di trovare qualcosa di più adatto da fare per vivere.