SQL Injection es el nombre dado a la manipulación de datos SQL a través de los objetos de entrada. ¿Pero cómo defenderse de él dentro y fuera del Scriptcase? ¡Vealo ahora!
En primer lugar, si aún no ha leído el post sobre ‘SQL Injection: Inyectando datos desde Inputs’, le aconsejamos que eche un vistazo, pues para el entendimiento de este post abajo, será necesario tener una idea de lo que es el SQL Injection. ¿Quieres mirarlo ahora? ¡Haga clic aquí!
Cómo protegerse del famoso SQL Injection
Como todos ya vieron en el post anterior el SQL Injection es el nombre dado a la manipulación de datos SQL a través de objetos input.
A partir de ahora usted aprender a defenderse de este deface dentro y fuera de nuestro querido Scriptcase.
Defensa a través de Scriptcase
En el caso de que no se encuentre en el sistema operativo, es posible que el usuario no pueda acceder a la base de datos.
Esto es responsable de cuidar la seguridad de nuestros campos de entrada contra el famoso sql de inyección.
Vamos a entender cómo funciona.
A continuación podemos observar cómo el select se comporta con relación a los datos insertados en el input, esto utilizando este select:
sc_select(rs, “SELECT * FROM sec_users WHERE login = ‘{user}’ AND pswd = ‘{pass}’”);
La imagen arriba muestra detalles de lo que ya habíamos visto en el post anterior, pero observe ahora la imagen de abajo y vea cómo funciona la macro dentro de nuestro select:
sc_select(rs, “SELECT * FROM sec_users WHERE login = “.sc_sql_injection({user}).” AND pswd = “.sc_sql_injection({pass})).
Entonces, antes de utilizar la macro “sc_sql_injection” nuestro código quedaba abierto a interpretaciones, ahora con el uso de la macro de forma correcta, Scriptcase percibió rápidamente que se estaba inyectando un valor anormal y colocó una barra invertida antes del valor del campo login , de esta forma la validación del select quedaría:
SQL generado:
SELECT * FROM sec_users WHERE login = ‘\’ OR 1=1; — ‘ AND pswd = ”
Interpretación:
Me trae todo de la tabla sec_users donde el login es igual a \ o 1 es igual a 1 y el resto comenta.
Lógicamente no tendremos ningún login llamado “\”, por lo que la inyección de la persona estará bloqueada.
Por lo tanto, siempre es importante utilizar esta macro para buscar o insertar información en la base de datos.
Para obtener más información sobre cómo utilizar esta macro, acceda a:
https://www.scriptcase.net/docs/es_es/v9/manual/14-macros/01-general-view/
Cómo protegerse fuera de Scriptcase, en PHP puro
Para que esté libre de usar SQL Injection, se deben tomar ciertas medidas. Algunas de las acciones serán realizadas en el servidor de base de datos, otras deben ser garantizadas por el código fuente, o sea, en nuestro caso el PHP.
Podemos utilizar a través de PHP la función addslashes (), que por señal es la misma función utilizada por la macro “sc_sql_injection”.
Esta función tiene por objetivo insertar una barra invertida antes de cada aspa simple y la doble ala encontrada en la variable pasada, este proceso se conoce como “escape”. Si la directiva de configuración de PHP “magic_quotes_gpc” está activada, el escape se realiza automáticamente sobre los datos de COOKIES y los datos recibidos a través de los métodos GET y POST. En este caso, no debe efectuarse el tratamiento con addslashes (). La función get_magic_quotes_gpc (), disponible en las versiones de PHP desde 3.0.6, devuelve la configuración actual de la directiva magic_quotes_gpc. Vea el ejemplo de cómo utilizar esta función:
Otra forma de protegerse también es a través de MYSQLI en PHP. Si usted todavía utiliza las funciones de la lib mysql (), “CORRA”, porque además de casi no ser utilizada, es totalmente vulnerable a las invasiones de este tipo. En ella, todas las queries se pasan manualmente. Pero, por supuesto, yo no hablaría de correr de esta lib sin citar una alternativa, la clase mysqli, ésta utiliza parámetros en “bind” para no haber ninguna concatenación directa y en ese medio del “bind” la clase trata el input para nada funcionar como una la inyección.
Vea un pequeño ejemplo de cómo utilizar:
Entendiendo el código:
# Aquí instamos a la clase mysqli, pasando como parámetro el servidor, usuario, contraseña y nombre de la base de datos.
$ mysqli = new mysqli (‘servidor’, ‘usuario’, ‘contraseña’, ‘database’);
# Con nuestra clase ya instanciada, vamos a hacer la llamada del método preparar para “preparar” la consulta que recibirá los valores.
# Donde tenga “?” (Interrogación) serán los lugares donde entraron los valores.
# Obs .: No es necesario preocuparse por las comillas en el caso de cadenas.
$ stmt = $ mysql-> prepare (“SELECT name, email FROM sec_users WHERE login =? AND pswd =?”);
# Después de nuestra instrucción estará preparada con la cadena de la consulta y las interrogaciones, vamos a definir qué variables entraron
# en qué lugares y sus tipos a través de la función -> bind_param (“cadena de tipos”, “variables en orden”).
$ stmt-> bind_param (‘ss’, $ login, $ contraseña);
# Donde tiene ‘ss’ usted debe colocar las iniciales del tipo de variable.
# Por ejemplo: $ login y $ contraseña son cadenas, entonces ‘ss’. Si era $ valor y $ contraseña, entonces ‘ds’.
# Los tipos permitidos son:
# i – variaciones enteras
# d – variables dobles
# s – variables de cadena
# b – variables que proporcionan datos para un blob
# Después de definir qué lugares las variables ocuparon, ejecutaremos la instrucción.
($ stmt-> ejecute ()) {
# Otra función legal de la instrucción es que podemos hacer algo parecido al proceso inverso de bind_param.
$ stmt-> bind_result ($ name, $ email);
# La función bind_result, asignará los valores obtenidos en las consultas, en nuestro caso name y email, en variables que nosotros
# elegimos los nombres, preferí mantener el nombre, pero podría haber colocado $ var1 y $ var2, siendo que $ var1 recibira el nombre
# y $ var2 el email.
# Y ahora tomamos todos los resultados imprimirlos en la pantalla con los nombres de las variables que definimos en el bind_result ().
mientras que (stmt-> traer $ ()) {
echo “Nombre de usuario: $ name \ n Correo del usuario: $ email \ n”;
}
}
?>
Obviamente nunca estaremos 100% protegidos, pues si las empresas más grandes como Facebook, Google y muchos otros que invierte millones en seguridad de datos y son realmente eficientes en lo que respecta al asunto, logran deshacerse de los ataques de hackers imaginen a los programadores comunes. Pero es claro que siempre podemos dificultar las cosas.
Así que es eso personal, espero que les haya gustado el post. Aconsejo que para mejor entendimiento de una lectura en la documentación de las funciones y alternativas citadas arriba.
También podría gustarte…