Comment puis-je amener les programmeurs à arrêter d'écrire du code vulnérable à l'injection SQL?

Parfois, vous êtes occupé et déléguez de petites tâches à des programmeurs débutants. Mais si vous n'y prêtez pas suffisamment attention, vous vous retrouvez avec ce type de code en production:

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
        );
    }

}

Donc, étant donné que j'ai supprimé la logique de gestion de l'authentification / session par souci de concision, qui peut me dire quel problème possible il pourrait y avoir avec cet exemple?

Vous pouvez leur apprendre. Tout le monde le fait au début, même vous. Si ce type de code entre en production, c'est la faute des personnes âgées; pas le junior.

Éditer:

L'une des choses que j'ai faites est que j'ai personnellement pris la décision de demander aux gens de réviser mon code (y compris les juniors) avant une version. Le code est révisé, les juniors le voient comme une expérience d'apprentissage, les gens perdent la peur de la révision du code comme punition et commencent à faire la même chose.

Piratez leur code devant leurs yeux puis montrez-leur comment le corriger. Encore et encore jusqu'à ce qu'ils comprennent.

Vous pouvez les obliger à suivre un cours dès qu'ils rejoignent votre entreprise, avant d'avoir accès au contrôle de code source, ce qui les initie aux injections SQL, aux scripts intersites, à la falsification de requêtes intersites et à d'autres vulnérabilités courantes. Couvrez les exemples en face à face, cassez le mauvais code devant eux, faites-les casser le mauvais code et dirigez-les vers le site OWASP pour plus d'informations une fois qu'ils auront obtenu leur diplôme.

Vous pouvez également exiger l'utilisation d'une bibliothèque personnalisée qui gère cela pour vous, mais ce n'est qu'une solution secondaire car ils seront sûrs d'exécuter des requêtes personnalisées lorsque cela deviendra plus pratique.

Si vous avez les ressources, il peut également être utile de s'assurer que les membres les plus expérimentés de l'équipe vérifient leurs différences avant de s'engager.

La connaissance, c'est le pouvoir!

En supposant que c'est l'insécurité à laquelle d'autres ont fait référence, en tant que développeur de tout niveau, il est facile d'oublier que getPost () ne sécurise pas les données en premier.

Une solution consiste à:

1. Écrivez une classe qui obtient toutes les données POST / GET et les écrit telles quelles dans une classe Singleton appelée «insecure_data». Désactivez ensuite les tableaux POST / GET.
2. Les développeurs doivent récupérer les données POST / GET à partir du tableau «insecure_data», et non les tableaux POST / GET.

Tout développeur qui récupère quelque chose dans un tableau appelé «insecure_data» et ne prend pas la peine de le sécuriser est soit ignorant, soit paresseux. Si c'est le premier, offrez une formation, après quoi ce doit être le second - et alors vous avez un problème disciplinaire, pas un problème de programmation.

L'un des meilleurs guides que j'ai lu sur la sécurité Web est ce guide de sécurité Ruby on Rails . Bien qu'il s'agisse de Ruby on Rails, de nombreux concepts s'appliquent à tout développement Web. J'encourage toute personne nouvelle à lire ce guide.

Le code que vous avez lié ci-dessus est susceptible d'une attaque par injection SQL, car les entrées HTTP que vous utilisez dans la requête n'ont pas été nettoyées avec mysql_real_escape_stringou tout autre moyen.

En ce qui concerne votre question (probablement prioritaire) "comment puis-je amener les programmeurs à cesser de faire cela", je dirais que les encadrer régulièrement, expliquer soigneusement le problème en question (et les retombées potentielles, etc.) et mettre l'accent sur l'importance des vulnérabilités du code (à la fois en termes d'injection SQL et de script intersite, etc.) est probablement la solution la plus judicieuse.

S'ils continuent de gâcher malgré tout ce qui précède (vous voudrez peut-être jeter un œil sur leurs engagements, etc. plutôt que de découvrir "en direct"), alors le problème est soit que vous leur échouez en tant que mentor, soit que ils ont peut-être besoin de trouver quelque chose de plus approprié pour vivre.