Inyección SQL
¿Qué es?
La inyección de código es una vulnerabilidad que se puede explotar en todas aquellas aplicaciones que trabajen con una base de datos. Esta consiste en la modificación por parte de un usuario de las consultas que se realizan a la base de datos. Por lo general tiene origen en el incorrecto filtrado de los campos a los que tiene acceso el usuario de cara a introducir datos en la BD (base de datos). Una de las particularidades de este tipo de error es que se puede producir en cualquier lenguaje tanto de programación como de script.
Este tipo de vulnerabilidad puede provocar varias consecuencias como por ejemplo la validación correcta de usuarios que no están en nuestro sistema, el acceso por parte de un usuario a datos a los que no se debería tener acceso o problemas del tipo de manipulación y borrado de la BD.
Algunos ejemplos
Para los ejemplos me voy a basar en PHP, pero la mayoría de cosas aquí comentadas se hacen extensibles a otros lenguajes.
Ejemplo 1:
Supongamos que hemos implementado en una web un sistema de identificación de usuarios, nuestra sentencia para crear la consulta sería algo así:
sql_sentencia = “select pass from Usuario where usuario = ‘” . $login_user . “‘;”;
Donde login_user es una variable que tiene un valor proveniente de un formulario de identificación. Pongamos que el usuario que se a identificado es “Pedro”, lo cual haría que la sentencia SQL finalmente terminará así:
select pass from Usuario where usuario = ‘Pedro’;
Hasta aquí todo sería completamente normal. Pero si el usuario no tiene buenas intenciones en vez de introducir “Pedro” como usuario podría introducir lo siguiente:
Pedro’; drop table Usuario;
Esto daría lugar a lo siguiente:
select pass from Usuario where usuari = ‘Pedro’;
drop table Usuario;
El SQL se ejecutaría en orden. La primera sentencia tendría el funcionamiento esperado, pero la segunda nos borraría la tabla “Usuario” de nuestra BD con lo que ya tendríamos nuestro primer desastre.
Ejemplo 2:
Supongamos el mismo caso de implementación de un sistema de identificación, pero esta vez con el siguiente código:
sql_sentencia = “select id from Usuario where nombre = ‘” . $login_nombre . “‘ and pass = ‘” . $pass . “‘;”;
Y para la identificación nos basamos en si la consulta devuelve o no valor. Lo normal sería que el usuario hubiera ingresado su login y su contraseña y que hiciéramos la comprobación, si la select devuelve algún valor lo identificaríamos y si el resultado de la consulta esta vacío no lo haríamos. Ahora bien un usuario avispado podría hacer lo siguiente:
Usuario: Pepe (usuario que sabe que existe porque ha visto antes)
Password: ‘ or ‘a’='a’
El valor de “algo” or “true” como todos sabréis es “true” con lo cual conseguiría identificarse en nuestro sistema.
¿Como solucionarlo?
Para evitar problemas de seguridad con este tipo de ataques la única solución es una buena programación por parte la persona que implemente la aplicación. Para ello el programador debe tener en cuanta esta posibilidad y tratar de evitar que se de una situación adecuada para la inyección de código. En la mayoría de lenguajes de programación utilizados en Web existen formas faciles de evitarlo y poco a poco cambien en los lenguajes de escritorio, aun así si no existe en el lenguaje una forma especifica, siempre lo podemos implementar nosotros a mano.
En PHP por ejemplo para mysql existe la función “mysql_real_escape_string” que se encarga de escapar todos lo caracteres extraños de un parámetro introducido. Para el ejemplo uno, la creación de la sentencia quedaría algo así:
sql_sentencia = “select pass from Usuario where usuario = ‘” . mysql_real_escape_string($login_user) . “‘;”;
Espero que esto os sirva para a partir de ahora mejorar la seguridad de todo lo que programéis. Si alguien tiene algo que aportar o quiere ampliar la información o corregir algo, animaros y dejad vuestros comentarios.
Trabajo en grupo
Se dice que el ser humano es un ser social, que depende en gran medida del prójimo para desarrollarse, para desarrollar sus cualidades y descubrir sus carencias. A raíz de esto, siempre nos han nombrado el trabajo en grupo como algo positivo, una buena forma de aprender a hacer las tareas de manera cooperativa con otras personas para de esta forma alcanzar objetivos más grandes. En la mayoría de empresas se lleva a cabo este tipo de trabajo y realmente aporta muchas ventajas frente a un trabajo individual. Pero desgraciadamente, con el afán de preparar a la gente para la vida laboral se aplica en otros ámbitos donde, en mi modesta opinión, no debería hacerse.
Centrémonos inicialmente en el ámbito laboral. Esta claro que en un empresa es algo que funciona como se ha comprobado a lo largo de muchos años de ponerlo en práctica, pero también esta claro que en una empresa no se dan los mismos factores que en otro tipo de situaciones. En mi opinión, las circunstancias que en una empresa hacen que el trabajo en grupo triunfe son:
- Todo el mundo a pasado por una entrevista previa por el departamento de personal, que se supone a escogido a lo mejor que tenía su alcance, lo cual no tiene porque se verdad pero, es un principio.
- En una empresa la gente que esta allí, tiene unas cuarenta horas semanales en las que se van a ver seguro y van a poder cooperar y discutir las posibles mejoras o dificultades de una tarea a realizar.
- En una empresa todo el mundo sabe porque esta allí, para que le han contratado y que si no hace lo que debe quizas se quede en la calle. Ademas de que por lo general la mayoría de la gente solo tiene un trabajo y esta centrado en él.
- Quizás mucha gente afirme que trabajas en un grupo con gente desconocida y que eso es uno de las grandes desventajas, pero eso con un poco de tiempo, a ocho horas al día es una semana como mucho, esta solucionado. Por lo demas, todos tienen un objetivo común: el proyecto o en su defecto no irse a la calle.
- En una empresa si formas parte de un proyecto se te van a asignar unas tareas determinadas y una fechas de entrega planificadas. Que en muchas ocasiones no se ajustan a la realidad, es cierto, pero te las dan. Y si aparecen otras tareas son de tu proyecto, de lo que estas haciendo y relacionadas con él.
Desde mi punto de vista, estas son algunas de las cosas que hacen que en las empresas el modelo de trabajo en grupo funcione perfectamente. Pero claro, el problema viene cuando en sitios que no cuentan con estas condiciones se intenta aplicar el modelo de trabajo en grupo. Para no generalizar, diré que me estoy refiriendo al ámbito universitario. Cuando llegas a cursos superiores en muchas asignaturas se ven “obligados” a meterte en la dinámica de trabajo de una empresa para que conozcas como se trabaja en la realidad. Dejando de lado el hecho de que si realmente quisieran hacer esto tendrían que cambiar el plan de estudios completo y la filosofía decente, solo me voy a centrar en el aspecto de introducir, a la fuerza, la filosofía de trabajo en grupo.
Esta claro, y son indiscutibles sus beneficios, pero en el ambiente adecuado que es el nombrado anteriormente, en una empresa. Pero todo lo que en una empresa se torna en ventajas, en un proyecto de una asignatura se tornan en barreras a la hora de enfrentarse a ellas. Estas barreras serían:
- La gente que cursa la asignatura no tiene porque valer para nada. Puedes encontrarte desde la persona mas responsable y trabajadora, hasta a la mas desastrosa, vaga y caradura.
- La asignatura solo te proporciona una media de dos horas semanales para pasarlas en común con tus compañeros de grupo. Y la mayoría de esas dos horas se pasan escuchando explicaciones del profesor/a. Con lo cual las posibilidades de discutir mejoras o problemas son mínimas. Si ha esto le añadimos que el resto del tiempo cada uno puede ser de un pueblo, tener un horario diferente y un montón de otras tareas diferentes, pues pasa lo que pasa que para quedar todos algún día hay que hacer un estudio completo.
- Hay gente que va allí a probar suerte, gente que va a aprobar, … Si no sale bien solo te juegas una convocatoria y poco mas. Además hay que añadir que no solo tienes esta asignatura sino que tienes ocho mas, con lo cual no estas orientado a un solo objetivo.
- Al igual que en la empresa, es cierto que trabajas con gente desconocida, pero lo que en la empresa se solucionaba en una semana, unas cuarenta horas, aquí hace falta unas veinte semanas para alcanzar esta cantidad de horas en común. Teniendo en cuenta que un cuatrimestre son dieciséis semanas, probablemente acabéis la práctica y sigáis siendo desconocidos.
- Como siempre pasa, cada asignatura tiene sus propias practicas y sus propios proyecto, con lo cual olvídate que los miembros de un grupo estén todos centrados en las tareas de una en particular. Además, cada asignatura tiene sus fechas de entrega, que por supuesto se solapan unas con otras.
En definitiva, el trabajo en equipo es una gran ventaja aplicada en la situación adecuada, pero si la situación no es propicia no se debería forzar. Veo muy bien que en las universidades intenten enseñar a los alumnos algo sobre la vida real, pero se deberían plantear si estas medidas sirven de algo y benefician de algo al alumno, o si por el contrario solo van a a servir para dificultar el aprendizaje correcto de una materia. Quizás muchos profesores deberían de mirar las cosas con algo mas de perspectiva, no obcecarse tanto con sus pensamientos sobre como se deberían hacer las cosas y prestar mas atención a los problemas que surgen. Aun así como siempre los alumnos lo superarán todo y acabarán aprobando porque así son las reglas y si quieres avanzar toca sufrir y hacer, pero algo debería cambiar.
Quien no ha pensado alguna vez, “si lo hiciera yo solo terminaría antes y mejor”. ¿Quien no se ha tenido que dejar alguna asignatura porque en su grupo no trabajaba nadie? ¿Que opináis vosotros de todo esto?
