Rilevamento dei set di dati interessati dall'iniezione SQL

Naviga le tue risposte
0

Supponendo di sapere che una delle mie applicazioni è stata attaccata da un'iniezione SQL, come posso identificare set di dati modificati o selezionati?

Sulla fonte ovvia ci sono i registri del webserver. Questo dovrebbe permetterci di identificare la vulnerabilità e il codice iniettato. Di solito, il registro del server web registra solo richieste GET ma nessuna richiesta POST. Questo limita l'uso dei log del server web.

So che MySQL e altri DBMS hanno diversi tipi di file di registro, ad es. per query lente. Ci sono altri posti che potrebbero aiutare in questo caso? Ci sono impostazioni o regolazioni che dovrei applicare in anticipo e che semplificheranno l'analisi?

    
posta Stefan Braun 20.05.2016 - 21:58
fonte

1 risposta

1

Se hai già avuto un attacco SQL injection:

MySQL per impostazione predefinita non registra tutte le query [1], poiché ciò avrebbe un impatto significativo sulle prestazioni. Inoltre, non è sufficiente considerare solo le tabelle a cui si accede direttamente all'applicazione web.

  • Se non hai abilitato la registrazione o il controllo, determina quali tabelle saranno considerate "di valore elevato" nel database principale. Pensa: users , user_creditcards , oauth_keys . Tutto ciò che potrebbe produrre un guadagno (guadagno finanziario, ulteriore accesso, password) per il tuo aggressore. Questi sono probabilmente compromessi.
  • Considerare anche qualsiasi altro database a cui l'utente utilizzato dall'applicazione web ha accesso.
  • Utilizzare la replica? [2] Trova il periodo di tempo di attacco nei log di accesso e ispeziona i Binlogs MySQL disponibili per quel momento. Ciò fornirà solo query modificabili ( UPDATE/INSERT/DELETE/CREATE/ALTER/DROP ).
  • La tua rete è monitorata? Il database è su un host diverso e la connessione non è crittografata? Chiedere ai membri della sicurezza di rete se hanno acquisizioni del traffico di rete. Esamina le acquisizioni con Wireshark [3].
  • Determina se LOAD DATA INFILE / INTO OUTFILE [4] era disponibile per l'utente del database. In tal caso, è necessario inoltre esaminare ulteriormente il server che ospita il database per ulteriori segni di compromesso.

Se stai cercando di progettare una procedura di risposta agli incidenti / tattiche di difesa o linee guida di configurazione:

  • Considera l'utilizzo di un plug-in di controllo [5]. Determina le tue tabelle di alto valore. Controlla l'accesso a tali tabelle da parte degli utenti interessati. Il registro risultante può contenere query altamente sensibili e proteggere di conseguenza. Implementa criteri di conservazione.
  • Considerare l'implementazione di un WAF per catturare le indicazioni degli attacchi. Verifica se è possibile segnalare un IP come sospetto e registrare tutto il suo traffico per un periodo. Di nuovo, questo genera dati sensibili. Proteggi di conseguenza.
  • Limita l'utente del database sull'applicazione web al minimo indispensabile a cui dovrebbe poter accedere. Ciò significa anche considerare se è possibile limitare i pattern di accesso per l'utente del database: deve essere in grado di SELECT * FROM secrets o avrebbe senso limitare l'utente dell'applicazione a una stored procedure ala CALL findSecretByIdentifier('MySecretIdentifier'); ?

Risorse:

[1] link

[2] link

[3] link

[4] link

[5] link

    
risposta data 22.05.2016 - 12:26
fonte

Leggi altre domande sui tag

protocollo di sessione SSL rispetto al protocollo di connessione SSL certificati X509 / SSL in pratica