protección contra injection

[navajito]

buenas tardes,

he estado leyendo cosas acerca de sql injection y ando detrás de adoptar una medida que descubra los caracteres más probables en un ataque como pueden ser "--", " ' ", "select", "drop", "update", "delete", etc. en las cajas de texto de mis formularios y en caso de encontrarlos no permita continuar devolviendo una página de error personalizada.
pero no tengo ni idea de como hacerlo ni por donde empezar.

como siempre os agradecería cualquier comentario, siempre los aprovecho y si algunas veces no he respondido a ellos es porque no he terminado de resolver el problema y no puedo mostrar la solución definitiva.

[Geri]

Deberias verificar todas las variables que envias y que entran. Podrias utilizar htmlentities(); o htmlspecialchars(); con esto las comillas y demas signos los convierte todos al lenguaje html. Por ejemplo tienes un formulario de contacto y envias las variables por el metodo POST
<?
if(isset($_POST['enviar'])){

//recoges los datos del formulario y con el htmlentities las comillas las convierte a html
$titulo=htmlentities($_POST['titulo']);
}
else{?>
<form ......>



</form>
<?
}?>

[MarioNunes]

Buenas, yo tengo una clase con unos metodos con expresionres regulares para controlar la entrada de valores.

metodo:

- numerico
- alfanumerico
- alfa

asi controlo lo que pueden introducir y cada metodo me devuelve un valor de verdadero o falso.

Un saludo.

[Manu_Leon]

no entiendo que es injection (perdonen mi ignorancia). De que tipo de ataques hablamos, en que consisten, si lo pueden resumir lo agradeceria...

[MarioNunes]

Buenas Manu Leon,

Un ejemplo sería un ataque de login y password :)

Que los parametros que introduces para validarte llevan comandos sql para engañar a la consulta cuando se ejecuta y así que se le de como válida.

Hay muchos programadores que han cometido este error, yo el primero :) pero con la experiencia y a base de meteduras de pata... se va aprendiendo,

Un saludo.

[jam1138]

Iniciado por Manu_Leon

no entiendo que es injection (perdonen mi ignorancia). De que tipo de ataques hablamos, en que consisten, si lo pueden resumir lo agradeceria...

www.php.net/security.database.sql-injection

También para el autor del tema, claro (lease las técticas de protección).

[navajito]

se me ha ocurrido esto, pero no sé, me parece una exageración, una salida de tono, una cosa extravagante, en mi pueblo se dice parir un niño con dos cabezas. el caso es que sirve, que detecta si alguien introduce en algún campo del formulario alguna de las palabras que dan paso a una instrucción sql.

en realidad ahora tengo el problema con el bucle foreach porque me devuelve tantas lineas como campos tiene el formulario y yo no quiero eso. quisiera en cambio mostrar una sola linea diciendo escuetamente, por ejemplo, el formulario no está correctamente cumplimentado.

pero si veis cualquier fallo, o no os gusta, o quereis comentar algo positivo o negativo pero no una recomendación a leer algo os quedaré muy agradecido.


foreach($_POST as $name=> $value){

if (ereg(insert, $value ) || ereg(update, $value ) || ereg(delete, $value ) || ereg(drop, $value ))
{
echo '$value contiene la palabra "insert,delete,update,drop,etc"</br>';
}else{
echo '$value no contiene la palabra "insert,delete,update,drop,etc"</br>';
}
}

[jchernandez]

Hola MarioNunes yo también he hecho una clase con unos tres comanditos para controlar el SqlInyection, a ver, me imagino que el tuyo está mejor, si lo podes postear aquí sería bueno xD.

[Manu_Leon]

interesante la propuesta de navajito, bloqueando el uso de esas palabras incluso alguna mas (union x ejemplo) es muy dificil realizar consultas mysql.

[Manu_Leon]

http://www.phpinsider.com/php/code/SafeSQL/
por lo visto es una clase muy util para anular injection... hechenle un vistazo...

[$thisone]

Holas.

Que una persona ponga en un formulario la palabra insert, union, select no tiene ningún peligro. El peligro está, entre otras cosas, en las comillas. Y para escaparlas existen funciones.

No hay que crear complejas funcion/clases para controlar esos datos. Simplemente hay que modificarlos silensiosamente y punto.

http://php.grn.es/manual/es/function.addslashes.php

Saludos ;)

[xknown]

Para evitar ese tipo de ataques, en mi opinión simplemente basta con aplicar el método addslashes:

Código PHP:

  // formatting-functions.php --> Wordpress
function global_sanitize( $array ) {
    foreach ($array as $k => $v) {
        if ( is_array($v) ) {
        $array[$k] = global_sanitize($v);
        } 
        else {
            if ( get_magic_quotes_gpc() )
                $array[$k] = trim($v);
            else
                $array[$k] = addslashes( trim($v) );
        }
    }
    return $array;
}
// Lo invocan:
$_REQUEST = global_sanitize($_REQUEST);
$_SESSION = global_sanitize($_SESSION);
// etc 
   

Saludos

[Manu_Leon]

umm, llevas razon, pero si el problema son als comillas, par algo esat el javascript, se comprueba que no peuda llevar comillas el formulario ni ningun tipo de caracter extraño, solo letras numeros y guion bajo _
es decirsi introducen un = o una ' o " o / o o ; o aglo extraño, javascrip no deja mandar el formulario

[johnnylee]

si, pero en ciertos navegadores como mozilla firefox, se pueden deshabilitar las funciones javascript que tenga la pagina... al menos eso he probado yo que pasa con las funciones del lado del cliente; no se si tambien pueda deshabilitar las funciones de parte del server...

Saludos.

[Manu_Leon]

joder, pues si eso es asi :O:O:O :S:S

[navajito]

gracias,

lo que propongo se complementa con una conexión en la que el parámetro usuario tiene permisos limitados, en mi caso solo haría falta utilizar las palabras insert, update, select, delete. pero no tengo mucha experiencia con los permisos, solo manejo los que me ofrece mi servidor en modo gráfico.

en cuanto al enlace estoy muy mal de inglés.

y sí, se puede desactivar javascript en cualquier momento no solo firefox como dice johnnylee.

[navajito]

gracias,

sí, poner en un campo del formulario insert, update o cualquier palabra reservada sql y después enviarlo no hace ningún daño a nadie, todo depende de la sintaxis con la que se acompañe, pero me parecía evidente que es imprescindible utilizar cualquiera de estas palabras tarde o temprano para realizar un ataque.

en cuanto a addslashes ( string cadena ) me parece que la ventaja que tiene es que no devuelve ningún error y el atacante no puede estar seguro de lo que está ocurriendo.

pero lo que no comprendo -y es que todo esto se me da muy mal- es como llegan estas cadenas al servidor y en realidad que es lo que pasa cuando se aplica esta función.

por otra parte me pregunto que es mejor en estos casos utilizar lo más previsible, que siempre será lo más estudiado por los atacantes, o utilizar algo raro como propone MarioNunes.

[navajito]

gracias,

estoy convencido de que tu código da buenos resultados pero no tengo ni idea de como lo hace, no tengo mucha experiencia y no soy partidario de utilizar cosas de las que no tengo la menor idea de como funcionan, utilizo algunos códigos de terceros complejos para mí pero tengo cierta capacidad para modificarlos y adaptarlos, en tu caso no es así, no sé por donde cogerlo, tendré que estudiar más.

[$thisone]

Holas.

He perdido un poco el hilo de este tema, pero digo:

La seguridad de una página no puede depender de cosas en las que el cliente puede intervenir(javascript, cookies, etc). Es que...no se como explicarlo...pero lo mas lógico sería que aprendierais a relizar estos ataques(inyección sql, xss, etc) para así saber en que se basan y poder pararlos.

Como ya e dicho antes...hay que usar addslashes() para cadenas que vallan a ir a la base de datos. Y htmlentities() o htmlspecialchars() para cadenas que se impriman por pantalla en las que el cliente puede tener acceso a ellas(ya sea mediante la URL, mediante cookies, etc).

Siento no poder explicarme mejor pero es que cuando repartieron el don de la palabra falté a clase xD

Saludos ;)

[navajito]

de momento, no tengo interés en aprender a atacar bases de datos, ni estoy intentando aprender a hacerlo aprovechándome de vosotros, no soy tan ingenuo.

dicho esto lo que os propongo es que si alguien con conocimientos de sql injection quiere atacar ***amablemente*** mi base de datos podría servir para detectar si está efectivamente protegida. los datos que guardo no tienen más valor que el trabajo del volver a entrarlos pero no me gustaría tener que hacer todo el trabajo otra vez. no guardo ninguna información importante pero por favor no me hagáis un destrozo si conseguís entrar.

ir directamente aquí

http://www.carloszcom.com/base5

sugiero que os registreis antes de hacer el ataque, y después volvais a atacar utilizando el usuario "visitante_38" y la clave "navajito".

os advierto que la página es experimental y no está bonita, ni tan siquiera clara por lo que puede que requiera algún esfuerzo por vuestra parte comprender como funciona.

insisto en que en cualquier caso no os voy a preguntar como lo habeis logrado.

[$thisone]

Holas.

En ningún momento he echo apología de el hacking ni nada parecido. LO que quiero dar a enteder que lo primero que hay que saber es en que consiste el ataque para poder pararlo.

Saludos ;)