Mitigare un tentativo di pirateria quando viene rilevato da un'app seduta dietro un WAF

Il principio generale è "difesa in profondità". In altre parole, se ogni livello della tua applicazione applica le regole che hai in atto, la tua architettura preverrà il comportamento peggiore. Le specifiche di ciò che fai dopo dipende in realtà dalla politica di sicurezza e dalle politiche in vigore per il tuo cliente. Ciascuno dei punti elenco che hai elencato sono buone idee, ma l'unica cosa che può dirti che è assolutamente necessario sono le politiche di sicurezza di cui hai bisogno.

Controllo

Di solito è una buona idea registrare tutti i tentativi fatti da un utente per fare qualcosa che non sono autorizzati a fare. Potresti non farne uso subito, ma se hai bisogno di fare una retrospettiva dopo essere stato violato, quei log ti aiuteranno a ricostruire quello che è successo.

Per quanto tempo mantieni i log, ecc. fa tutto parte delle tue politiche di sicurezza. Fai del tuo meglio per assicurarti che i registri non possano essere manomessi il più possibile.

401, 403, 404 o qualcos'altro?

C'è un po 'di dibattito che dipende dalla tua posizione sulla sicurezza.

• 401 non autorizzati: dà l'impressione che all'utente non sia consentito attivamente di fare qualcosa. Gli hacker possono utilizzare tali informazioni per trovare i limiti di ciò che qualcuno può e non può fare.
• 403 vietato: offre una risposta leggermente più ambigua in quanto potrebbe essere un problema di autorizzazione dei file. Gli hacker possono ancora usare queste informazioni per trovare i limiti di ciò che qualcuno può e non può fare.
• 404 non trovato: risposta ambigua che indica semplicemente che qualcosa non è presente.
• 400 cattiva richiesta: di solito significa che l'utente non ha fornito tutte le informazioni necessarie affinché la richiesta abbia esito positivo.
• Errore del server 500: sembra che non sia possibile rilevare eccezioni nel codice del server e gli hacker potrebbero tentare di utilizzarlo come vettore per provare a fare qualcosa di male.
• 502 gateway non valido: sembra che la tua applicazione non sia dietro un server proxy.
• 503 servizio non disponibile: sembra che l'applicazione stia implementando una nuova versione.

In conclusione, in genere, è meglio inviare una risposta nella serie 400 in linea con ciò che si ritiene ragionevole. Utilizzare codici di risposta non standard per allontanare le persone dall'odore dovrebbe essere riservato a cose estremamente sensibili. Una risposta nella serie 500 sembra un exploit potrebbe essere disponibile, che potrebbe ritorcersi contro per il suo scopo previsto.

Integrazione WAF

Come ho detto all'inizio, la difesa in profondità è qualcosa che fai a tutti i livelli. Dovresti mettere difesa adeguata a livello di applicazione anche se non si integra con il WAF.

Qualsiasi potenziale integrazione con il WAF deve essere discussa con il fornitore WAF. Tieni presente che potrebbe non essere possibile, poiché qualsiasi cosa che possa influire sul comportamento del WAF è anche un modo per causare un Denial of Service alla tua applicazione. Assicurati di poter autenticare per distinguere tra le comunicazioni provenienti dalla tua app anziché le comunicazioni provenienti da un processo illecito.

Problema che 403 in effetti, o 404 (ho sentito argomenti per entrambi, alcuni esperti di sicurezza dicono che persino emettere un 403 dà troppe informazioni all'intruso, un 404 è meglio che dicono). Registralo anche per analisi successive.

Se il firewall debba essere notificato o meno è discutibile, dipenderà dal firewall e dalle politiche interne dell'organizzazione.

Gli ambienti in cui ho lavorato tendevano a non farlo, tuttavia, una volta che l'intruso raggiungeva il server, il server / l'applicazione dovevano occuparsi di lui. Questo in parte nuovamente per evitare che l'intruso sapesse che il suo tentativo di intrusione è stato rilevato analizzando la risposta del firewall (che avrebbe saputo di aver ignorato, quindi ancora una volta ottenere un errore da esso fornisce informazioni sulla tua rete). / p>