Come devo rilevare e rispondere ai cattivi attori che eseguono iniezioni SQL?

0

SQL Azure ha un componente logico chiamato Rilevamento delle minacce . Presumo che cerchi SQL Injection, ma anche prove di comandi pericolosi come sp_exec.

Mi piacerebbe espandere questo ambito e anche ispezionare i seguenti aspetti del traffico degli utenti per l'iniezione SQL e altri tipi di comportamento hacking ...

  • HTTP GET / POST (o altri verbi)
  • Intestazioni client (che verrebbero visualizzate nelle soluzioni di gestione dei registri)
  • Cookie non inviati dal mio sito

Supponendo che qualcosa sopra faccia scattare un allarme, qual è la risposta più appropriata:

  • Blocca l'indirizzo IP
  • Reauthenticate l'utente
  • Blocca l'account
  • Contrassegna la sessione?

Quale classe di strumenti di sicurezza sarebbe appropriata per questo tipo di attività (nel cloud) e dove posso saperne di più sui modi intelligenti di gestire le diverse tecniche di risposta / mitigazione?

    
posta random65537 06.08.2016 - 15:55
fonte

1 risposta

1

Il modo giusto per agire è rifiutare la richiesta (richiesta di fallimento prima di iniziare qualsiasi codice di applicazione / query SQL) e registrare l'evento con informazioni di debug complete nel database, assegnare un numero ad esso ed emettere il numero sullo schermo.

Questo dovrebbe essere non lo stesso database di quello operativo, dovrebbe essere un database di servizio in cui normalmente si memorizzano i registri delle operazioni.

Se si tratta di una chiamata API, quindi inserire questo numero nella casella del messaggio di errore. Questo è trattare i falsi positivi per una volta, e in secondo luogo affrontare i tentativi riusciti di iniezioni.

Tuttavia non puoi impedire "seleziona 1;" argomenti da passare ogni volta perché è sempre possibile passare "selezionare 1;" da qualche parte e tale richiesta dovrebbe essere bloccata prima di raggiungere il codice dell'applicazione. Inoltre, questo è meglio implementato su "layer" dedicato dove la richiesta viene decodificata e controllata per questo tipo di cose come mod_security fa.

Non c'è modo di bloccare l'utente e disconnetterlo perché ci sarà un impatto troppo grande, è anche sul livello sbagliato - è il livello di codice dell'applicazione e non il livello di sicurezza dedicato.

    
risposta data 06.08.2016 - 16:09
fonte