¿Cómo puedo hacer que los programadores dejen de escribir código vulnerable a la inyección de SQL?

A veces se ocupa y delega tareas pequeñas a programadores junior. Pero si no presta suficiente atención, se encuentra con este tipo de código en producción:

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

}

Entonces, dado que he eliminado la lógica de administración de autenticación / sesión por brevedad, ¿quién puede decirme qué posible problema podría haber con esta muestra?

Puedes enseñarles. Todo el mundo hace esto al principio, incluso tú. Si este tipo de código llega a producción, es culpa de la gente mayor; No el junior.

Editar:

Una de las cosas que he hecho es que personalmente he tomado la iniciativa de pedirles a las personas que revisen mi código (incluidos los junior) antes de un lanzamiento. El código se revisa, los jóvenes lo ven como una experiencia de aprendizaje, las personas pierden el miedo a la revisión del código como un castigo y comienzan a hacer lo mismo.

Hackea su código frente a sus ojos y luego muéstrales cómo solucionarlo. Una y otra vez hasta que entiendan.

Puede ordenarles que tomen una clase tan pronto como se unan a su empresa, antes de que tengan acceso de control de fuente, que les presenta inyecciones SQL, secuencias de comandos entre sitios, falsificación de solicitudes entre sitios y otras vulnerabilidades comunes. Cubra los ejemplos cara a cara, descifre el código incorrecto frente a ellos, haga que descifren el código incorrecto y diríjalos al sitio de OWASP para obtener más información una vez que se "gradúen".

Además, puede ordenar el uso de una biblioteca personalizada que maneje esto por usted, pero esa es solo una solución secundaria, ya que se asegurarán de ejecutar consultas personalizadas cuando sea más conveniente.

Si tiene los recursos, también puede ser útil garantizar que más miembros senior del equipo verifiquen sus diferencias antes de comprometerse.

¡El conocimiento es poder!

Asumiendo que es la inseguridad a la que otros se han referido, como desarrollador de cualquier nivel, es fácil olvidar que getPost () no está asegurando los datos primero.

Una forma de evitar esto es:

1. Escriba una clase que obtenga todos los datos POST / GET y los escriba como está en una clase Singleton llamada 'insecure_data'. Luego borre las matrices POST / GET.
2. Desarrolladores que tienen que recuperar datos POST / GET de la matriz 'insecure_data', no las matrices POST / GET.

Cualquier desarrollador que recupere algo de una matriz llamada 'insecure_data' y no se moleste en asegurarlo es ignorante o vago. Si es lo primero, proporcione capacitación, después de lo cual debe ser lo último, y luego tiene un problema disciplinario, no de programación.

Una de las mejores guías que he leído sobre seguridad web es esta guía de seguridad de Ruby on Rails . Aunque es Ruby on Rails, muchos de los conceptos se aplican a cualquier desarrollo web. Animaría a cualquiera nuevo a leer esa guía.

El código que ha vinculado anteriormente es susceptible a un ataque de inyección SQL, porque las entradas HTTP que está utilizando en la consulta no se han limpiado mysql_real_escape_stringni por ningún otro medio.

En términos de su (supuestamente primordial) "¿cómo puedo hacer que los programadores dejen de hacer esto?", Diría que los asesora regularmente, explicando cuidadosamente el problema en cuestión (y las posibles consecuencias, etc.) y enfatizando La importancia de las vulnerabilidades de código (tanto en términos de inyección de SQL como scripting entre sitios, etc.) es probablemente la solución más sensata.

Si siguen estropeando a pesar de todo lo anterior (es posible que desee echar un vistazo a sus compromisos, etc. en lugar de descubrir "en vivo"), entonces el problema es que les está fallando como mentor, o que quizás necesiten encontrar algo más adecuado para ganarse la vida.