È possibile violare l'istruzione preparata e le stored procedure con una stringa di query sql non sicura

Question

È possibile violare l'istruzione preparata e le stored procedure con una stringa di query sql non sicura

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

1

Recentemente quando stavo guardando un codice che sembra più o meno come questo:

 $query = "call someProcedure(?,?,{$unsafeString})";

Poi c'è un codice dove viene preparato l'elenco degli argomenti e dopo questo, viene generata una dichiarazione preparata dalla stringa query

Dato che unsafeString proviene dall'utente, non viene convalidato o scappato e viene interpolato nella stringa di query. Mi stavo chiedendo, può essere una seria minaccia e come può essere sfruttato?

Ho provato ad aggiungere una seconda istruzione alla fine, ma sembra che le istruzioni preparate mi consentano di eseguire solo la prima query e ho anche provato a utilizzare la selezione select per ottenere alcuni valori da dB, ma sembra che alcune stored procedure non consentano fallo.

Quindi mi stavo chiedendo, posso affermare che questo è sicuro? o ci sono alcune possibilità di sfruttarlo?

php sql-injection mysql

posta user902383 22.02.2017 - 16:44

fonte

3 risposte

Leggi altre domande sui tag php sql-injection mysql

La modalità di trasporto IPsec può impedire DPI dal proprio ISP? Questo sistema di voto è sicuro dal punto di vista della teoria delle informazioni?

score 1 · Answer 1

A meno che non si stia eseguendo qualche SQL dinamico all'interno di una procedura o non si usi mysqli_multi_query () dovresti essere sicuro a questo punto ma dal momento che non stai eseguendo l'escape o la convalida dell'input dell'utente e se $ unsafeString è memorizzato in un database, un utente malintenzionato può utilizzarlo in un secondo momento e sarebbe difficile individuare. Pertanto cambierei in istruzioni preparate ovunque nel codice in modo da gestire tutti i dati, anche uno memorizzato nel database in modo sicuro.

EDIT:

Chiarimento

A seconda del modo in cui gestisci i dati nell'applicazione, e poiché non vi è un posto nel codice in cui non si usano le istruzioni preparate, sarebbe sicuro presumere che ci siano altri luoghi in cui non si può nemmeno usarlo. Se ad esempio gestisci dati precedentemente memorizzati con una chiamata a

$query = "call someProcedure(?,?,{$unsafeString})";

esiste la possibilità che tu gestisca quella stringa in un modo non sicuro in cui il codice iniettato nei dati potrebbe essere eseguito. Ad esempio, concatenando i dati con un'istruzione SELECT. Questo tipo di vulnerabilità è difficile da individuare poiché è probabile che i dati già archiviati nel database siano sicuri.

Inoltre, non sfuggendo o convalidando l'input, ti stai aprendo a un attacco XSS a seconda, corso su come gestirli successivamente o.

score 1 · Answer 2

1

Non ci sono abbastanza informazioni fornite. Dovremmo vedere la stored procedure sul backend per sapere se questo è vulnerabile o meno. Ti dirò che è sicuramente una bandiera rossa però.

risposta data 23.02.2017 - 04:56

fonte

score 0 · Answer 3

Se l'input dei dati non è validato o scapato, potrebbe essere vulnerabile a SQL Injection, perché una stored procedure potrebbe avere query dinamiche senza dati convalidati o scansionati, anche se si utilizzano stored procedure, si dovrebbe usare una dichiarazione preparata. Il rischio è inferiore utilizzando Stored Procedure, perché la deduzione della logica interna è più complicata; Inserimenti, aggiornamenti, selezioni potrebbero essere parte di una stored procedure, d'altra parte se non c'è una vulnerabilità di SQL Injection, si potrebbe infrangere la logica della stored procedure cercando di trovare un'iniezione SQL e potrebbe portare a risultati imprevisti, quindi Penso che un argomento non validato e senza escape implichi un rischio e che dovrebbe essere mitigato.