Seguridad

Vamos a abordar juntos otro par de párrafos sobre SQL injection. En esta ocasión te escribo sobre una variante de esta técnica que se basa en la posibilidad de ejecutar varias consultas, usando el estándar SQL, separadas entre sí con el signo de puntuación punto y coma (;).

Con una pequeña y rápida prueba, un hacker puede comprobar si nuestro formulario es vulnerable a SQL injection, y si debe  usar una comilla sencilla (‘) o comillas dobles (“). Una vez hecho esto únicamente ha de separar el valor legítimo del código malicioso usando dicha comilla, y con el punto y coma finalizar la consulta legítima para iniciar una nueva consulta con la función que el hacker desee realizar sobre la base de datos. Parece difícil, pero cuando veas un ejemplo verás que es realmente sencillo.

Estoy convencido de que si lo piensas detenidamente coincidirás conmigo en que, usualmente, la finalidad de nuestras aplicaciones es la de servir  a nuestros usuarios de interfaz para  el manejo de extensas bases de datos. Estas bases de datos están diseñadas para facilitar la consulta y el transporte de información hacia el usuario y, en sentido opuesto, para recibir y almacenar información entregada por el mismo. Cada vez que un usuario consulta o envía información a la base de datos de tu aplicación, está participando en la construcción de un código que ejecutará una acción en dicha base de datos. Ahora que hemos dicho esto, pregúntate ¿podría un usuario ilegítimo aprovechar esta pequeña participación para desvirtuar el código y hackear tu base de datos?.

 Te cuento más cosas a tener en cuenta cuando procesas información recibida de tus usuarios. En primer lugar quiero que sepas que es conveniente que chequees la longitud de los valores recibidos para prevenir ataques de denegación de servicio o de desbordamiento de buffer. En PHP se puede usar la función strlen() para comprobar la longitud del dato recibido antes de procesarlo.

If (strlen($edad) > 3 ) exit ($edad . " es un valor inválido para el campo edad";)

 Y ahora hablemos del formato. Cuando comprobamos el tipo de variable y su longitud puede parecer que tenemos todo el trabajo hecho, pero no  es del todo cierto. Una fecha de nacimiento y un correo electrónico pueden estar contenidos en una variable del tipo cadena de caracteres, pero tienen aspectos bien distintos, formatos diferentes. La fecha puede estar separada por barras, usar dos caracteres para indicar el día en cifras, tres para indicar el mes en letras y dos para indicar el año en cifras; algo así como 12/jun/78. El correo electrónico contiene dos secciones bien diferencias por el signo @ y finaliza con un punto y una extensión del tipo com, es, tv, org, etc. Otro ejemplo: metroSetenta@gmail.com. En el momento en que nuestro código debe interactuar con el de otras aplicaciones como, por ejemplo, gestores de correos, bases de datos o sistemas subyacentes, el formato usado es esencial para la prevención de errores y brechas de seguridad.

 Este es uno de esos pasos que ya te conté que tienes que dar para conseguir el correcto y seguro funcionamiento de tu aplicación. No es necesario tener un nivel de formación en informática a la altura de poder generar errores del tipo buffer overflow, porque si tu aplicación espera un valor numérico y un usuario maligno introduce texto, lo mejor que puede pasar es que tu programa no funcione correctamente. Se trata, pues, de una gran brecha potencial en la seguridad de tu aplicación. Los tipo de datos, a grandes rasgos se pueden dividir en tres: Cadenas de texto, números y booleanos.