Evitar Inyeccion en MySQL

Iniciado por ZharkD, 13 Mayo 2010, 21:12 PM

0 Miembros y 2 Visitantes están viendo este tema.

ZharkD

Hola,

Pues hace unos dias me pase a leer unos temas que encontre por el foro ( http://foro.elhacker.net/desarrollo_web/evitar_inyeccion_de_sql_en_php-t32862.0.html ), sin embargo, estuve viendo que si una inscrutccion se envia, existe la posibilidad de que se ejecute ANTES de que los campos enviados sean validados, lo cual es preocupante.

Cita de: ESQUEMA
- Se carga la web
- Se llena el formulario
- Se envia
- Se procesan las instrucciones del formulario (instrucciones para "inyectar" base de datos)
- Entran las instrucciones para validar el formulario (aunque esten incluidas antes de <html>), o al menos eso creo.
- Se carga la web.

Una idea "tonta y simple" que me paso por la mente es "limitar los campos de texto" es decir, ajustarlos a un maximo de 20 caracteres cuando mucho. Eso podria evitar inyecciones sql?

Ademas, encontre algo que supuestamente (no lo eh comprobado por que aun estoy tratando de descifrar cada cosa que se hace) valida campos de un formulario desde el lado del cliente, lo que no se es si lo hace antes o despues de enviar el formulario:
http://web.ontuts.com/tutoriales/como-validar-un-formulario-con-php-y-javascript-jquery/

La parte de php es muy similar a la que yo utilizo, valido los campos de una manera muy similar desde el lado del servidor, sin embargo como les comento, tengo el temor de que las instrucciones puedan ser enviadas ANTES de que entre la validacion. Sera posible evitarlo limitando los campos de texto a un maximo de caracteres?

Gracias por su atencion y paciencia.

Shell Root

Cita de: ZharkD en 13 Mayo 2010, 21:12 PMUna idea "tonta y simple" que me paso por la mente es "limitar los campos de texto" es decir, ajustarlos a un maximo de 20 caracteres cuando mucho. Eso podria evitar inyecciones sql?
La iSQL, se caracteriza por tener una comilla simple para escapar la consulta inicial y modificarla por la iSQL. Así que limitar el numero de caracteres ingresados dentro de los textbox, no va a cumplir con tus necesidades, además dependiendo del metodo que uses, se puede bypassear el maxlength. Por ejemplo:
index.php En este ejemplos el limite de caracteres es de 5, pero modificando la peticion GET o POST, podemos agregar más valores.
Código (php) [Seleccionar]
<html>
<head><title>PoC</title></head>
<body>
<form action='index.php' method='POST'>
<input type="text" name="txtPoC" maxlength="5"><br>
<button name="btnEnviar" value="Enviar" type="submit"></button>
</form>
<?PHP
echo $_POST['txtPoC'];
?>
</body>
</html>


txtPoC=123456789....&btnEnviar=Enviar
Por eso no duermo, por si tras mi ventana hay un cuervo. Cuelgo de hilos sueltos sabiendo que hay veneno en el aire.

luiggy2

La verdad es que validarlo del lado del cliente es una tontería (si pones limitación de caracteres se modifica el formulario y punto, y si lo haces mediante javascript siempre se podrá bloquear).

Por consiguiente lo mejor es validarlo del lado del servidor. Si lo haces en php, mirate esto: http://es2.php.net/manual/es/function.mysql-real-escape-string.php.

Código (php) [Seleccionar]
mysql_real_escape_string();

La duda que plantes de que si se va a ejecutar antes o no se que, la verdad es que no me he enterado mucho, pero espero que con esto te sirva, si no, pregunta que para eso estamos.



Saludos!
" Las grandes ideas suelen salir la mayoría de veces de grandes estupideces "

ZharkD

#3
@Alex@ShellRoot
Wow... esa no me la sabia :S

@luiggy2
He revisado el link que me proporcionas de php.net y no entiendo muy bien "la finalidad" de la funcion, en el ejemplo #3, mencionan usar otra mas (stripslashes()), sin embargo mencionan que es requerido (o asi entiendo)  el "magic_quotes_gpc" y cuando visito la referencia de esa opcion me dice que ya esta obsoleta. Segun entiendo la finalidad de la funcion (stripslashes()) es remover las barras invertidas.

Para validar lo que estoy haciendo es comparar la cadena que genera el campo de texto, que solo acepte valor alfanumerico, de tal manera que las comillas, diagonales y demas regresan un error en el campo de texto e interfaz con el usuario "caracter invalido". Pero como menciono, si alguien escribe por ejemplo " '; mysql_query(...)" en el campo de texto, creo que pasara a ejecutarse antes de la validacion (o al menos eso creo), ya que la pagina "MANDA" mediante el POST los valores del campo de texto (los cuales segun mi analizis, se ejecutan) y despues verifica si son o no validos (aunque esten en la misma pagina/script).

Se me ocurrio algo aunque obio se vuelve mas tedioso pero creo que es mas seguro, y si cierro la conexion con la base de datos cada, digamos, "cierre de pagina" (una vez que se carga el script) y la abro despues de un if()?, de esta manera, garantizo que antes de if() podre validar los campos de texto y NO se podran realizar consultas anteriormente ya que no hay "conexion establecida", es fiable?

Shell Root

Por eso no duermo, por si tras mi ventana hay un cuervo. Cuelgo de hilos sueltos sabiendo que hay veneno en el aire.

BHK

si limitas a 20 carácteres puedo hacerte un infile y llamar a un archivo sql de instrucciones externas y hacer cualquier inyección que yo quiera, además estarias restringiendo a tus usuarios solamente no al atacante.

ZharkD

Cita de: BHK en 14 Mayo 2010, 00:51 AM
si limitas a 20 carácteres puedo hacerte un infile y llamar a un archivo sql de instrucciones externas y hacer cualquier inyección que yo quiera, además estarias restringiendo a tus usuarios solamente no al atacante.
wtf...!
ok ok mala idea y que tal lo de mi post anterior?

Gracias a todos por su cooperacion.

Shell Root

Cita de: ZharkD en 13 Mayo 2010, 23:37 PMSe me ocurrio algo aunque obio se vuelve mas tedioso pero creo que es mas seguro, y si cierro la conexion con la base de datos cada, digamos, "cierre de pagina" (una vez que se carga el script) y la abro despues de un if()?, de esta manera, garantizo que antes de if() podre validar los campos de texto y NO se podran realizar consultas anteriormente ya que no hay "conexion establecida", es fiable?
No le veo funcionamiento a eso, de igual manera la iSQL se realiza dentro del formulario de la pagina, que obviamente si la estamos visualizando, está establecida la conexión a la base de datos. Tal vez valdría en el caso de que la iSQL se realizará sin estar en el formulario de la pagina. De igual forma, no es la mejor forma de evitar una iSQL. Mirad el LINK que te deje en POST anteriores.
Por eso no duermo, por si tras mi ventana hay un cuervo. Cuelgo de hilos sueltos sabiendo que hay veneno en el aire.

ZharkD

#8
Aver si entiendo bien,

Me pase a leer algunos manuales en linea para comprender mejor los links que me dejaron arriba y esta es mi deduccion, por favor corrijanme si estoy mal:
"Una inyeccion se puede prevenir si se realiza la validacion DESPUES del $_POST pero ANTES de realizar mis consultas en las bases de datos."
A mayores palabras, un ejemplo:
Digamos que yo tengo un campo de texto (como dueño, script). Entonces proporciono ese campo a un visitante, el cual curiosamente ingresa " '); mysql_query(....); " entonces presiona enviar. Hasta ahora solo se ha asignado el valor de " '); mysql_query(....); " a la variable $_POST['ejemplo'] como contenido "textual" unicamente. Ahora bien, apra evitar que se genere la consulta que el visitante realizo, debo validar esa variable con algunas funciones como stripslashes(), mysql_real_escape_string() y otras mas. Se procede con una condicion, la cual establecera si la variable enviada es valida, en caso que lo sea generara mi consulta (mi script), en caso contrario, regresara un error en la webform y de esta manera evitara la inyeccion.

En resumen, una inyeccion NO procede hasta que el mismo script propio del dueño le da acceso tras generar una consulta del script, dando paso de esta manera a que la variable que solo era texto, se convierta en una instruccion para afectarnos.

Es correcta mi deduccion?

Shell Root

xD, la verdad, no entendí un fuck!  :rolleyes:
Por eso no duermo, por si tras mi ventana hay un cuervo. Cuelgo de hilos sueltos sabiendo que hay veneno en el aire.