pregunta sobre piratería de seguridad de PHP, puede ser más que solo PHP

Question

pregunta sobre piratería de seguridad de PHP, puede ser más que solo PHP

#1 de Mark Buffalo (0 votos)
#2 de Benoit Esnard (0 votos)

2

Tengo un cuadro de entrada para INSERTAR en la base de datos. Está escrito en PHP DOP. Alguien escribió:

<"'>

y también:

' onClick='alert(1);

Supongo que estaban en dos cuadros de entrada diferentes. Pero de alguna manera, el usuario pudo modificar el campo a en la base de datos a un número negativo cuando la única manera (si lo está haciendo bien, presionando un botón) es incrementar en +1 o -1. Por ejemplo, el usuario presiona el botón "+1", aparecerá +1 en la base de datos. Si presionan "-1" en la base de datos. Tienen un número negativo de -50 o algo así. ¿Qué podrían haber hecho? ¿De qué es vulnerable mi sitio web?

Aquí está el código:

$insertQuery = $dbh->prepare("INSERT INTO fcomments (poster, lid, post_id, comment, time_stamp) VALUES(:user_id, :lid, :post_id, :comment, :timeNow)");
$insertQuery->bindParam(':user_id',$user_id);
$insertQuery->bindParam(':lid',$lid);
$insertQuery->bindParam(':post_id',$post_id);
$insertQuery->bindParam(':comment',$comment);
$insertQuery->bindParam(':timeNow',$timeNow);
$insertQuery->execute();

Parece que todos los valores están vinculados. ¿No está seguro de cuál podría ser el problema?

sql-injection databases php mysql injection

pregunta hackfree111 15.01.2016 - 16:55

fuente

2 respuestas

0

Su código maneja la inserción SQL correctamente. Tengo dos conjeturas sobre el ataque:

El atacante podría haber repetido la solicitud varias veces, y tu código no comprueba si ya ha votado la publicación.
El atacante ha enviado muchas solicitudes de voto negativo en un período de tiempo muy corto, lo que le permite explotar un tiempo de verificación / tiempo de uso condición de carrera .

respondido por el Benoit Esnard 15.01.2016 - 17:00

fuente

Lea otras preguntas en las etiquetas sql-injection databases php mysql injection

Linux (!) Arquitectura de red para el escenario CTF [cerrado] bind9 resuelve todas las consultas en una dirección: ¿un servidor comprometido?

score 0 · Accepted Answer

¿Son suficientes las declaraciones preparadas?

PreparedStatements no son suficientes por sí mismos.

Debería revisar su código y preguntarse qué es necesario y qué es posible. Recorra tanto el cliente como el servidor, y vea qué datos se envían, si es posible modificarlos, y qué hace. Mira qué cosas puedes hacer.

No puedo ver el resto de su código, pero a primera vista, este código parece ser vulnerable a múltiples Direct Object Reference exploits. Es posible que esté insertando valores en la base de datos sin verificar si estos valores son válidos, o si deberían modificarse, o si el usuario está incluso autorizado para cambiar esos valores.

INSERT INTO fcomments (poster, lid, post_id, comment, time_stamp) 
VALUES(user_id, lid, post_id, comment, timeNow

El hecho de que vincules estas variables no significa que no sean explotables. Probemos un caso de prueba. Hagamos algunos casos de prueba de ajax (supongo que 'lid' es una cantidad de upvote): callAjaxDatabaseUpdate(post_id, lid);

Ahora llamémoslo: callAjaxDatabaseUpdate(25, 100) ;

Esperas que sea exactamente como lo ingresaron, así :

INSERT INTO fcomments (poster, 100, 25, comment, time_stamp) 
VALUES(user_id, lid, post_id, comment, timeNow

¿Qué pasa si cambio los datos en tránsito? :(

Preguntas que debes hacerte

Veamos sus parámetros enlazados:

$insertQuery->bindParam(':user_id',$user_id);
$insertQuery->bindParam(':lid',$lid);
$insertQuery->bindParam(':post_id',$post_id);
$insertQuery->bindParam(':comment',$comment);
$insertQuery->bindParam(':timeNow',$timeNow);

¿El usuario debería poder enviar el user_id ? ¿Debería enviarse el lid ? Todo esto parece material que el usuario podría cambiar si lo está enviando a través del cliente.

Digamos que quieres hacer una publicación, ¿verdad? Vamos a hacer una publicación entonces:

postDataToForum(user_id, lid, post_id, comment);

Debido a que sabe quién está conectado en ese momento, puede tomar su user_id y usarlo para enviar elementos en su declaración de SQL, etc. No es gran cosa, ¿verdad?

Bueno, hay un problema potencial con eso: puedo presionar F11 e ir a la consola del desarrollador y cambiar esos valores, o podría usar un programa como TamperData para Firefox para averiguar qué se está enviando y luego modificar en tránsito.

Así que esperas esto:

postDataToForum(23, 100, 450, "Hi everyone");

Pero el intruso busca en su lista de usuarios, o incluso utiliza un número aleatorio, y altera los datos:

// user_id = 1 = admin.
postDataToForum(1, 100, 450, "I have altered the input. Pray I do not alter it further.");

Y luego muestra que el administrador ha publicado, en lugar del usuario. Este DOR exploit podría estar en todas partes en su aplicación web. En el caso de su upvote, el usuario podría haber ingresado "-1", y usted no lo verificó.