La domanda di sicurezza informatica di PHP, potrebbe essere più che solo PHP

Question

La domanda di sicurezza informatica di PHP, potrebbe essere più che solo PHP

#1 da (0 voti)
#2 da (0 voti)

2

Ho una casella di input per INSERIMENTO nel database. È scritto in PHP DOP. Qualcuno digitato:

<"'>

e anche:

' onClick='alert(1);

Suppongo che fossero in due caselle di input differenti. Ma in qualche modo, l'utente è stato in grado di modificare un campo nel database in un numero negativo quando l'unico modo (se farlo correttamente, premendo un pulsante) è di aumentare di +1 o -1. Ad esempio, l'utente preme il pulsante "+1", farà +1 nel database. Se premono "-1" nel database. Hanno un numero negativo di -50 o qualcosa del genere. Cosa avrebbero potuto fare? Di che cosa è vulnerabile il mio sito web?

Ecco il codice:

$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();

Sembra che tutti i valori siano vincolati. Non sei sicuro di quale potrebbe essere il problema?

php sql-injection mysql databases injection

posta hackfree111 15.01.2016 - 16:55

fonte

2 risposte

0

Il tuo codice gestisce correttamente l'inserimento SQL. Ho due ipotesi sull'attacco:

L'autore dell'attacco potrebbe aver ripetuto la richiesta più volte e il tuo codice non controlla se ha già effettuato il downvoting del post.
L'autore dell'attacco ha inviato molte richieste di downvote in un brevissimo periodo di tempo, consentendogli di sfruttare un tempo di controllo / tempo di utilizzo condizioni di gara .

risposta data 15.01.2016 - 17:00

fonte

Leggi altre domande sui tag php sql-injection mysql databases injection

Conferma la firma di JWT o effettua la chiamata API (JWT vs. oauth) Come verificare se l'esecuzione del comando remoto "/ run timeout / T 5" ha funzionato sulla pagina HTML?

score 0 · Accepted Answer

Le Stanze preparate sono sufficienti?

Gli Stumenti Preparati non sono sufficienti da soli.

Dovresti esaminare il tuo codice e chiediti cosa è necessario e cosa è possibile. Passa sia dal lato client che lato server, e vedi quali dati vengono inviati, se è possibile modificarli e cosa fa. Guarda cosa puoi fare.

Non riesco a vedere il resto del codice, ma a prima vista questo codice sembra vulnerabile a più exploit Reference diretto . È possibile che si stiano inserendo valori nel database senza verificare se questi valori sono validi o che devono essere modificati o che l'utente è autorizzato a modificare tali valori.

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

Solo perché si vincolano queste variabili non significa che non siano sfruttabili. Proviamo un caso di test. Facciamo alcuni casi di test ajax (presumo che 'lid' sia l'importo in aumento): callAjaxDatabaseUpdate(post_id, lid);

Ora chiamiamolo: callAjaxDatabaseUpdate(25, 100) ;

Ti aspetti che sia esattamente così come è entrato, in questo modo :

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

Cosa succede se cambio i dati in transito? : (

Domande che devi pormi

Esaminiamo i parametri associati:

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

L'utente dovrebbe essere in grado di inviare user_id ? Dovrebbe essere presentato il lid ? Sembra tutto ciò che l'utente potrebbe cambiare se lo stai inviando tramite il client.

Diciamo che vuoi fare un post, giusto? Facciamo un post quindi:

postDataToForum(user_id, lid, post_id, comment);

Poiché sai chi è loggato in quel momento, puoi prenderne il user_id e usarlo per inviare cose nella tua istruzione sql, ecc. Non è un grosso problema, giusto?

Bene, ecco un potenziale problema: posso colpire F11 e andare nella console degli sviluppatori e cambiare quei valori, oppure potrei usare un programma come TamperData per FireFox per scoprire cosa viene inviato e quindi modificare in transito.

Quindi ti aspetti questo:

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

Ma l'intruso controlla l'elenco degli utenti o utilizza un numero casuale e modifica i dati:

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

E poi mostra l'amministratore che ha pubblicato, invece che l'utente. Questo exploit DOR potrebbe essere ovunque nella tua applicazione web. Nel caso del tuo upvote, l'utente avrebbe potuto inserire "-1" e non l'hai verificato.