Quien sabe como hacer para que no te realicen SQL Injection en tu web. Lo que he logrado es que no me ataque mediante los formularios bloqueando algunos caracteres con los que puedes realizar SQL Injection. Lo que no he podido hacer es controlar esto en las url. Si tengo est url http://localhost:90/prueba.php?valor=35 y le agrego esto despues ';drop table prueba; la sentencia en la base de datos quedaria haci: select * from prueba where id= '35';drop table prueba;' y lo cual te borrara la tabla prueba. Como puedo hacer para controlar esto.
prueba pasarlas a url amigales y prueba a pasar consultas inportantes atraves de post y no por get, ademas prueba el str_replace(), y remplaza algunos caracteres como lo ago yo, de esa forma remplazas el ' quedara como '' y el sql la toma como texto y no como parte de la consulta
a que te refieres con url amigables ?? y en ese proceso en especifico me es imposible pasarlas por post probare con str_replace() a ver que onda gracias
url amigables son las url que no llevan ? y = es decir tu url podria ser http://localhost:90/prueba/valor/35 o http://localhost:90/prueba/35.html de esta forma es mas dificil para otros saber que parametros estas utilizando, claro que necesitas conocimientos de htaccess, pero usa el str y resplaza los caracteres como '
el iframe no es nada mas que la muestra una pagina dentro de otra por ende igual puede ocurrir aunque es mas raro que ocurra, ya que la persona que quiere hacer el sql injection tiene que buscar la url en el codigo fuente y darse el trabajo de abirlo directamente y asi...
Hola, Siempre debes evaluar el dato que esperas recibir. Si es id=algo Y "algo" es un id de un registro, debe ser un número, por lo tanto puede usar la función is_numeric() Ejemplo: if (!is_numeric($id)) die(); En la actualidad hay muchos sitios webs con este problema, que parece tan simple de resolver que sorprende, ejemplo: http://www.chileescena.cl/index.php?seccion=epoca-de-oro http://www.chileescena.cl/index.php?seccion=' Si se fijan, están más preocupados de los efectos javascript que de algo más importante. Saludos @sotelio
muy cierto, almenos yo manejo un sitio en el cual no puedo dar el id por ende invente un modo de verificar el id unico sin tener que darlo, atraves de un año, tipo y un dato unico de lo que quiero mostrar de esa forma realizo filtrado entre los contenidos iguales o parecidos.
El fallo es sencillisimo: Code: [COLOR="#FF0000"]SELECT * FROM[/COLOR] El fallo de este codigo es el "*" que por ese pego alguien puede aplastar tu web. La solución sería cambiarlo por: Code: [COLOR="#FF0000"]$id = (int)$_GET['id']; $query = mysql_query( "SELECT * FROM noticias WHERE id = '$id'");[/COLOR] Si quitamos la * y lo sustimos por un nombre mas concreto el bug quedaría corregido.
tu punto de vista es incorrecto como muestra en el ejempo es un tema de los datos que se pasan por url que le puedan agregar algun texto adicional probocando que php no lo reconosca y que sql realice las 2 acciones sin que se de cuenta. como muestra el ejemplo el hace el select en base a un id pero junto al valor que se esta pasando por url alguien externo agregar como en este caso un drop que hace que automaticamente la consulta borre toda la base de datos como es el ejempo. select * from prueba where id= '35';drop table prueba;' como ya dije la solucion podria ser por url amigable, por str_replace que realice cambios en algunos caracteres o incluso que reemplace textos como drop, como la comilla simple y el ; tambien puede probar a utilizar un usuario que tenga permisos fijos que no tenga la posibilidad de eliminar tablas o bases de datos, de esta forma se le agrega una proteccion adicional
Eso es incorrecto, actualmente existen herramientas como el Tamper Data de Firefox que permiten manipular envios POST como si fueran GET. El tema consiste en que siempre se debe mejorar la seguridad desde los scripts por lado del servidor. La mejor forma de mejorar la seguridad que me han resultado son haciendo dos cosas fundamentales: 1.- Sanitizar TODAS las entradas del usuario según listas blancas de carateres (Ej: si se pide un número de telefono, verificar si el texto solo tiene números) 2.- Convertir las entradas resultantes en el tipo de datos esperados a usar y revisar si la conversión se pudo hacer (Ej: si el usuario introduce su Edad, aplicar int($edad) para convertir a int. 3.- Siempre tratar la seguridad desde los códigos del servidor, las validaciones de javascript, por ejemplo, no sirven para nada. La unica función que tienen es de reducir la carga en el servidor. Hoy en día ni siquiera te puedes confiar del referrer. 4.- hacer un sistema de registro donde se almacenen todas las peticiones de documentos, revisando este log periódicamente te permite saber si alguien está tratando de inyectar una consulta SQL, en las web que administro he visto varios de estos intentos y ninguno les ha resultado xD. Saludos.
