Come posso convincere i programmatori a smettere di scrivere codice vulnerabile all'iniezione SQL?

11

A volte ti impegni e deleghi piccole attività a programmatori junior. Ma se non presti abbastanza attenzione ti trovi 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 la logica di gestione dell'autenticazione / sessione per brevità, chi può dirmi quale possibile problema potrebbe esserci con questo esempio?

php sql training

— Roger Halliburton
fonte

Perché questo non è memorizzato in un semplice cookie?

— Darknight,

1

@Darknight, stai presupponendo che ci sia una sessione in cui conservare i cookie. La presenza o meno è irrilevante per il problema di sicurezza più ampio.

— Roger Halliburton,

24

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

Modificare:

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

— John Kraft
fonte

2

+1 Devo essere d'accordo. Non puoi incolpare un programmatore junior (presumibilmente) perché hai assunto un livello di conoscenza che potrebbe non possedere. (Detto questo, si potrebbe piace pensare tali questioni sono ben noti in questo giorno ed età Poi di nuovo, mi piacerebbe. Piace pensare che ero talento e bello, etc.) :-)

— John Parker

Una dichiarazione abbastanza equa. Immagino che dovrei fare una domanda di follow-up chiedendomi perché il management insista nel lanciare il codice in produzione che non è stato approvato dai programmatori senior. Rischio il mio lavoro per un problema di sicurezza minore?

— Roger Halliburton,

1

@Roger Halliburton: Beh, se quel problema di sicurezza viene in qualche modo sfruttato, qual è il peggio che potrebbe accadere? E perché evidenziare i problemi di sicurezza ti costerebbe il tuo lavoro? Il management non vuole avere a che fare con questo?

— FrustratedWithFormsDesigner

1

@Roger - è solo secondario fino a quando non vieni violato. :) Penso che la messa in produzione del codice senza revisione (indipendentemente dal livello dello sviluppatore) sia un fallimento. Sfortunatamente, è una pratica molto comune in molte aziende; e, in effetti, di solito ci vuole un grande oh- $ 4! t prima che la direzione inizi a valutare cose come le revisioni del codice.

— John Kraft,

1

@Roger: tutto il codice dovrebbe essere rivisto, non solo il codice scritto da programmatori "junior". Anche i programmatori senior commettono errori.

— Dean Harding,

20

Hack il loro codice davanti ai loro occhi, quindi mostrare loro come risolverlo. Ancora e ancora finché non capiscono.

— Joe Phillips
fonte

4

Inviateli via email ogni mattina: "A proposito, ieri sera ho lasciato di nuovo il tuo database tramite un'altra vulnerabilità di SQL injection che hai lasciato nel tuo codice. So quanto ti piace ripristinare i backup del database!: D"

— Ant

2

@Ant: Sii gentile. Fallo poco dopo il backup pianificato, non poco prima.

— Donal Fellows,

@Donal: fallo poco dopo il backup, quindi informa che il backup non è riuscito e lasciali sudare per il resto della giornata prima di ripristinare il backup durante la notte.

— jwenting

8

Puoi incaricarli di seguire un corso non appena si uniscono alla tua azienda, prima che abbiano accesso al controllo del codice sorgente, che li introduce a iniezioni di SQL, scripting tra siti, contraffazione di richieste tra siti e altre vulnerabilità comuni. Copri esempi faccia a faccia, rompi codice errato davanti a loro, falli rompere codice cattivo e indirizzali al sito OWASP per maggiori informazioni una volta "diplomati".

È inoltre possibile imporre l'utilizzo 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 disponi delle risorse, può essere utile anche assicurare che più membri senior del team verifichino le differenze prima di impegnarsi.

Sapere è potere!

— yan
fonte

3

È meglio eliminarli prima che si uniscano alla tua azienda. Se stai assumendo qualcuno per scrivere qualcosa che utilizza SQL, non fai domande di intervista sui bordi di iniezione sull'incompetenza.

— Wooble,

Sono generalmente d'accordo, ma un noleggio junior molto intelligente e ambizioso è molto, molto più economico di uno "sviluppatore PHP con N anni di esperienza", che non è garantito per essere molto migliore. Gli sviluppatori junior intelligenti possono raccogliere queste cose molto rapidamente ed essere un vero vantaggio.

— gennaio

3

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

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 cancellare gli array POST / GET.
Gli sviluppatori devono recuperare i dati POST / GET dall'array 'insecure_data', non dagli array POST / GET.

Qualsiasi sviluppatore che recupera qualcosa da un array chiamato 'insecure_data' e non si preoccupa di proteggerlo è ignorante o pigro. Se è il primo, fornisci formazione, dopodiché deve essere il secondo - e poi hai un problema disciplinare, non di programmazione.

— Dan soffia
fonte

Wow, è inutilmente contorto e ancora non risolve il problema. Non si tratta di cancellare l'input solo per divertimento, ma di cancellare i dati che si stanno inserendo nel database e tali dati potrebbero teoricamente provenire da qualsiasi luogo, da un modulo Web o da un'e-mail o da un documento XML che qualcuno carica. In tutti questi casi è necessario eseguire lo scrub quando si passa al database.

— Roger Halliburton,

@RogerHalliburton Naturalmente non risolve tutto, ma si tratta di un concetto (una sorta di modello di progettazione, se si vuole), piuttosto che una misura di sicurezza completamente concretizzati per rendere insicuri i dati sguardo insicuro.

— Dan soffia il

Ah, capisco. Ma stai solo combattendo la natura umana, se dici a qualcuno "Questo oggetto è insicuro a meno che non sia contrassegnato come sicuro" e provano a usarlo per qualcosa, il più delle volte lo segnalano come sicuro senza realmente controllare. Bene, goditi l'incremento della reputazione.

— Roger Halliburton,

Dal punto di vista di uno sviluppatore junior, vedere solo $ insecure_data solleva una bandiera in un modo che non si vede solo $ postdata (o qualsiasi altra cosa). L'idea nasce da "Fa sembrare sbagliato il codice sbagliato" di Joel Spolsky . Se la natura umana dei tuoi sviluppatori è tale da ignorare quella bandiera rossa, allora devi fornire molta formazione o ottenere alcuni nuovi sviluppatori.

— Dan soffia il

Non tengo Spolsky su un piedistallo. Si tratta di sviluppatori che ignorano facilmente tabulazioni incoerenti, non ci penseranno due volte sull'uso di qualcosa che si chiama "insicuro".

— Roger Halliburton,

1

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

— mistagrooves
fonte

2

Tutti sanno che Ruby non è sicuro.

— Roger Halliburton,

5

@Roger: "Tutti conoscono" ogni sorta di cose che potrebbero essere o non essere vere. Sostengo un approccio alla programmazione basato sulla realtà, non basato su un sentito dire.

— Donal Fellows,

0

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

— Ryan
fonte

1

oh, pensavo che stessimo rispondendo a questa domanda come una domanda di prova:]

— Ryan,

I downvotes sono un po 'scadenti, dal momento che la formulazione della domanda è stata modificata ex post: P

— Ryan,

0

In termini di domanda (presumibilmente prioritaria) "come posso far smettere ai programmatori di fare questa" domanda, direi che li tutorano regolarmente, spiegando attentamente il problema in questione (e le potenziali ricadute, ecc.) E sottolineando l'importanza delle vulnerabilità del codice (sia in termini di iniezione SQL che di scripting cross site, ecc.) è probabilmente la soluzione più sensata.

Se continuano a fare casino nonostante tutto quanto sopra (potresti voler dare un'occhiata ai loro commit, ecc. Piuttosto che scoprire "dal vivo"), allora il problema è che stai fallendo come mentore, o che forse hanno bisogno di trovare qualcosa di più adatto da fare per vivere.

— John Parker
fonte