Foro de elhacker.net

Hola gente.. les comento que en mi web, tengo algunas entradas y salidas de datos, que me gustarian mejroarlas en seguridad.. para evitar SQL Inyection.

Supongamos en el metodo INSERT:
$res = mysql_query("INSERT INTO mails (mail) VALUES ('" . $_POST['mail'] . "')");

Y en el metodo SELECT:
$res = mysql_query("SELECT calle FROM locales WHERE calle = '" . $_POST['direccion'] . "' ORDER BY calle");
while($row = mysql_fetch_array($res)){
   echo $row['calle'] . "<br />";
}

Y que me dicen del UPDATE???

Si usas php>=5 y mysql>=4.1 lo mejor es que uses prepared statments (http://php.net/manual/en/pdo.prepared-statements.php)
Si no, tienes que escapar los caracteres especiales, utilizando mysql_real_escape_string($_POST['VAR']) o htmlentities($_POST['VAR'],ENT_QUOTES)

De todos modos hay mucha información sobre esto en el foro (http://www.google.es/search?q=evitar+sql+injection+site%3Aforo.elhacker.net&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:ca:official&client=firefox-a)

Saludos!

pd:y seguramente este hilo debería ir en el subforo de php :P

Ohhh por dios.. no me gusta todo eso que se ve ahi..!!!
Porque tanto codigo?

En cada consulta SQL, con poner mysql_real_escape_string($xxx) ya es suficiente?
Y al presentar los datos en la web, colocar el htmlspeciacharacters() de php (no recuerdo si se escribiía así :P)

Para intentar protegerte de inyecciones SQL tienes softwares como este:

http://www.greensql.net/

Pero si quieres algo mas personalizado, puedes crear dentro del motor de BD procedimientos almacenados y pasarle cierta cantidad de parametros, tambien existen en php creo que magic_quotes... (O no se bien, en Perl se conoce como placeholder) en php no se como se llame esta tecnica, pero tambien se utiliza dentro del lenguaje scripting para intentar evitar las inyecciones SQL.

Veré el Software, y lo del magicquotes..

porque esta sentencia: "INSERT INTO mails (mail) VALUES ('" . mysql_real_escape_string($_POST['mail']) . "')"
Me sigue ingresando perfectamente..

Que significa que te sigue ingresando perfectamente?
Con mysql_real_escape_string lo que consigues es que los caracteres especiales como las comillas simple se escapen con \', asi te aseguras que no cierran la primera comilla y añaden codigo.
Por lo tanto si a $_POST['mail'] se le pasa: '); drop database bd;-- Puedes estar seguro de que en mails se habrá insertado "'); drop database bd;"-- y no se habrá borrado la base de datos.

Y añadir capas de software para prevenir esto como comenta ^Tifa^ siempre está genial, pero programar bien para evitarlo tampoco cuesta nada y es aún más seguro

Saludos!

Huy.. es verdad... que idiota.. creí que tambien en la base de datos iba a aparecer el \'

Perfecto entonces... FUnciona perfectamente el "ingresado" de datos :D

Los amo...

Y en cuanto al UPDATE, hay que hacer lo mismo, o no?

Y para evitar XSS, imprimo los campos con htmlspecialchars? o htmlentities?

Si, hay que hacer lo mismo siempre que construyas sql dinámicamente a partir de la entrada del usuario, en el caso de que construyas el sql con un campo numérico debes comprobar también la entrada con un is_numeric() para que no haya inyección.

Pues si, para evitar xss con htmlspecialchars ya te vale puesto que convierte solo lo peligroso, aunque yo siempre utilizo htmlentities por costumbre, te transforma todos los tags posibles aunque la mayoría no sean necesarios teniendo bien puesto el encoding :P
Tienes que vigilar siempre todo get, post y cookie. No se que libro que leí hace mucho empezaba con: "La entrada del usuario es siempre incorrecta y peligrosa hasta que se demuestre lo contrario"

Después así sobre seguridad web relacionado también te quedaría prevenir CSRF sin tener en cuenta todo lo más simple: path traversal, rfi, lfi, etc...

Saludos!

Jamas entendi CSRF (tampoco investigue mucho)
Acabo de leer los otros items, y no me imagine esas vulnerabilidades.

A la web la tengo en un hosting, así que creo que varias vulnerabilidades estan evitadas por software..

Nadie conoce algun libro o algun documento donde se hablen de las vulnerabilidades mas generles a nivel web?

cross site request forgery... el ejemplo mas burdo es cuando muestras un link en una imagen (el link de eliminiar algo por ejemplo) pero solo lo puede ejecutar alguien con permisos, sin embargo no pide un token asi que al "ver la imagen" el que tiene permisos, ejecuta alguna accion sin su consentimiento :P

Lo del csrf es muy sencillo, mira:

Imaginemos que tienes un enlace como este: http://foro.elhacker.net/borrar_usuario.php?nick=Skeletron que solo puedes ejecutar cuando estas logueado.
Si yo consigo de algún modo que "hagas click" en el enlace conseguiré que borres tu usuario
Para evitarlo la aplicación web tiene que hacer que esa url no sea siempre válida, para ello lo que se hace es que cuando tu accedes a tu perfil y se muestra el enlace "borrarme" se añade al final un valor aleatorio quedando el enlace asi: http://foro.elhacker.net/borrar_usuario.php?nick=Skeletron&token=adsfadsfadfsafdas además se guarda el token en una variable de sesión.
Entonces en borrar_usuario.php se comprueba que el token existe y corresponde con la variable de sesión.
Así un usuario malintencionado necesitaría tu token para que funcionara, pero como éste cambia en cada formulario ya no es posible.

De todos modos es un ejemplo para que se entienda, el token tambien puede pasarse por post (es lo más común y lo mejor) o por cookie claro y como comenta Nakp si no previenes csrf hay muchos modos de que te obliguen a "hacer click".

Claro claro claro.. ya entendí...
Sería como "cerrarle la puerta" al link, que se no se ejecute la operacion, a no ser que se cumpla otra condicion antes..

Podria ser tambien que el admin tenga que ir a algun lugar de la administracion, y haga click en "habilitar borrado de usuarios", y dentro de borrarusuarios.php que mire si en la base de datos si han precionado ese boton...

Como un boton que habilita un boton :P

Ya entendi, ya entendi!!!...

En cuanto a evitar el acceso a direcctorios haciendo el ../../../../, supongo que mi hosting tendrá algun tipo de proteccion para ello!!!!!!.... igualmente, no utilizo algo así en la web... Pero lo tendré en cuenta para alguna vez ;)

Y que me dicen de los ataques: rfi, lfi, ???