Ci sono rischi potenziali per consentire a un utente Web MySQL di avere autorizzazioni di creazione, modifica e rilascio di PHP

Naviga le tue risposte
2

Lasciami prefisso la mia domanda con alcune informazioni sul nostro ambiente. Abbiamo un server web con oltre 100 siti web. Il server Web ha una corrispondente versione di MySQL Server 5.7. Ogni sito Web PHP ha un database MySQL con un utente MySQL ad esso collegato che ha solo le autorizzazioni impostate per poter accedere al suo database. In precedenza abbiamo dato solo le autorizzazioni utente, SELECT, UPDATE, DELETE e INSERT del sito web. Ora ci troviamo in una situazione in cui dobbiamo ora concedere all'utente le autorizzazioni Crea, Alter e Drop. Mi sto chiedendo quali sono i potenziali rischi per la sicurezza che ci sottopongono dando a questi utenti del sito Web queste autorizzazioni aggiuntive.

La prima cosa ovvia che posso pensare è con il permesso DROP, qualcuno potrebbe ovviamente abbandonare tutte le tabelle e tutti i dati andrebbero persi. Penso che potremmo essere in grado di ristrutturare il nostro codice per non richiedere DROP. Se questo è il caso e abbiamo solo bisogno di aggiungere CREATE & Alterare all'utente, quindi, qual è la situazione peggiore? Il database è anche bloccato da IP per accedere solo all'interno della nostra rete, quindi l'unico modo in cui un utente potrebbe accedere al database direttamente sarebbe attraverso un'iniezione SQL attraverso il sito web.

    
posta matwonk 02.01.2018 - 21:35
fonte

2 risposte

1

Purtroppo non ho molta familiarità con PHP, quindi non posso fornire alcun suggerimento su come questo possa essere sfruttato in modo specifico dal codice, ma voglio sottolineare altri dettagli. Dal punto di vista dell'ingegneria della sicurezza, si apre una seria quantità di opportunità di attacco. Prima di tutto, i motivi per evitare DROP sono ovvi. Oltre a ciò, se si verifica un'iniezione SQL, l'utente potrebbe aver creato uno script che crea una quantità infinita di database e potenzialmente DOS il sistema, un attacco tramite script che utilizza ALTER può anche causare il caos nel database. Puoi controllare alcune di queste cose nel back-end ma comunque concedere troppa energia a un utente

È difficile proporre qualcosa senza la fonte, ma perché non provi a isolare le azioni "pericolose" all'interno del server passando la richiesta a una verifica di back-end e poi hai root o un altro utente privilegiato che altera il database?

    
risposta data 02.01.2018 - 22:20
fonte
1

Non penso che tu abbia significativamente ridotto la sicurezza del sistema.

In precedenza, qualcuno poteva scrivere una query come: 

DELETE FROM importantTable where year(now()) <> 49

Questo significa che elipora la protezione "DELETE ALL" di MySQL, ma alla fine, la dichiarazione rimuoverà tutti i tuoi dati, supponendo che tu non viva ai tempi di Julius Cesar.

Il mio punto è che se c'è una volontà malevola di cancellare i tuoi dati, le tue modifiche non migliorano le probabilità degli attaccanti.

La mia preoccupazione è più di sicurezza. Supponendo che un programmatore scriva uno stile "James Bond ALTER TABLE": lascerà cadere il tavolo e poi lo ricrea. Questo va bene finché la tabella non contiene dati, ma causerà la perdita di dati.

Il fatto che il tuo database sia accessibile da PHP o da un altro sistema è irrilevante. È comunque importante capire l'acume delle persone che implementano il codice. Quante volte si registra nei registri un DROP negato? Questo "non dovrebbe essere successo" e dal fatto che hai rifiutato DROP, potresti aver conservato i dati.

    
risposta data 02.01.2018 - 22:43
fonte

Leggi altre domande sui tag

È ancora possibile eseguire un attacco di dizionario online da una singola macchina, senza anonimizzazione? Chiarimento sulla definizione di Cipher Suite in Wikipedia