Consentire solo query SELECT

Salve. Devo aggiungere alcune funzioni al mio sito, e per farlo ho necessità di usare una pagina PHP che prende la query con $_POST. Temo che qualcuno, accorgendosi del funzionamento della pagina, potrebbe inviare una query tipo DROP Table nomeTabella, quindi stavo cercando se era possibile creare un account col solo permesso "SELECT", ma PhpMyAdmin non me lo fa creare perché dice che non ho il permesso di creare nuovi utenti. Esiste quindi un modo, usando solo PHP, di bloccare qualunque query che non sia una SELECT? Grazie in anticipo per l'aiuto.

Molto semplicemente: NON permettere l'esecuzione diretta di una query letta dall'input. Non è solo dei DROP TABLE che devi preoccuparti, anche tutte le altre operazioni sono potenzialmente pericolose se si consente all'utente esecuzione arbitraria di codice. Anche restringendosi alle SELECT, ti esponi a tutti i possibili attacchi di SQL Injection, per non parlare del fatto che qualcuno potrebbe semplicemente lanciare un SELECT username, password FROM users con effetti devastanti per la privacy :=):.

Ristruttura il codice per accettare in input, tramite POST, solo le minime informazioni necessarie per eseguire un'interrogazione. Verifica che queste siano accettabili (es. niente SELECT di campi che dovrebbero essere privati), quindi costruisci la stringa di query (meglio se con prepared statement) ed eseguila.

Nel database non ho nessuna informazione sensibile. Per la query, ci sono troppe variabili e non so se riesco a costruirla solo fornendo le informazioni minime. Comunque, considerando che per portare a termine un attacco SQL Injection l'utente dovrebbe avere anche permessi di scrittura, e considerando che Altervista non permette di creare nuovi utenti, stavo pensando di metter su un database su una VPS che ho, creare un account con privilegi di lettura soltanto, e fare una pagina php, sempre sulla VPS, che restituisce la risposta alla query in JSON, che poi scarico sul mio sito usando file_get_contents() e rappresento in tabella. Che dici? Tra l'altro, risparmio spazio sul sito e alleggerisco il carico sui server AV, visto che le mie query verranno gestite da un db esterno.

Benché possibile, mi sembra più complicato così che non parametrizzando le query.

Citazione:

---

alleggerisco il carico sui server AV

---

In realtà il carico aumenta: allo stato attuale il costo è di una chiamata HTTP per contattare la tua pagina, più un'interrogazione di database "diretta".
Se realizzi quanto dici avrai comunque bisogno della chiamata HTTP per contattare la tua pagina, l'interrogazione sarà spostata sul VPS, ma ci sarà una richiesta (e risposta) HTTP in più dal server AlterVista al VPS. Inoltre questa richiesta sarà HTTP, non su connessione diretta al database, questo vuol dire tempi di codifica e decodifica (in questo caso da/a JSON) e maggiore occupazione di banda (overhead dei pacchetti HTML). A questo vanno inclusi tempi dovuti a latenza e larghezza di banda.

Citazione:

---

risparmio spazio sul sito

---

Nella maggior parte dei casi il guadagno di spazio è trascurabile. Se, al contrario, i dati restituiti dalle query sono molti, rischi di perdere nei tempi di risposta.

L'idea di delegare una macchina diversa alla persistenza dei dati di per se non è sbagliata, però costa e quindi vale la pena farlo se sotto c'è un motivo solido. La difficoltà nello scrivere il codice che costruisca le query di solito non è tra questi.

Citazione:

---

per portare a termine un attacco SQL Injection

---

Non necessariamente, sono sufficienti permessi di lettura (anche se questo limita il tipo di attacchi).

Citazione:

---

In realtà il carico aumenta: allo stato attuale il costo è di una chiamata HTTP per contattare la tua pagina, più un'interrogazione di database "diretta".
Se realizzi quanto dici avrai comunque bisogno della chiamata HTTP per contattare la tua pagina, l'interrogazione sarà spostata sul VPS, ma ci sarà una richiesta (e risposta) HTTP in più dal server AlterVista al VPS. Inoltre questa richiesta sarà HTTP, non su connessione diretta al database, questo vuol dire tempi di codifica e decodifica (in questo caso da/a JSON) e maggiore occupazione di banda (overhead dei pacchetti HTML). A questo vanno inclusi tempi dovuti a latenza e larghezza di banda.

---

Ah, capito.

Citazione:

---

Nella maggior parte dei casi il guadagno di spazio è trascurabile. Se, al contrario, i dati restituiti dalle query sono molti, rischi di perdere nei tempi di risposta.

L'idea di delegare una macchina diversa alla persistenza dei dati di per se non è sbagliata, però costa e quindi vale la pena farlo se sotto c'è un motivo solido. La difficoltà nello scrivere il codice che costruisca le query di solito non è tra questi.

---

Vorrà dire che mi metterò d'impegno a scrivere il codice per costruire le query. Grazie per l'aiuto

Se hai bisogno di supporto ricorda che puoi chiedere qui sul forum :)

Citazione:

---

Originalmente inviato da mzanella

Se hai bisogno di supporto ricorda che puoi chiedere qui sul forum :)

---

Grazie, ma non penso avrò bisogno. Tra la guida di MySQL e quello che si trova su StackOverflow me la sto cavando da solo.