Dovrei preoccuparmi di SQL Injection per le Web App interne?

Esistono protezioni per indirizzare rischio - le protezioni hanno un costo (tempo / sforzo per codificare, nel tuo caso) e tali costi devono essere confrontati con i vantaggi / i costi di implementazione. Se il costo del rischio realizzato è inferiore al costo per implementare le protezioni, non ha senso implementare le protezioni.

Risposta breve: Sì! Implementa le migliori pratiche di sicurezza in qualsiasi applicazione che memorizzi dati sensibili o in grado di accedere ad altri server con dati sensibili, indipendentemente dal fatto che siano pubblici o meno.

Spiegazione

È una pratica fin troppo comune per le aziende investire nella protezione del proprio perimetro. Ciò significa che l'accesso da e anche a Internet è altamente limitato e protetto, ma all'interno della sicurezza della rete interna è molto più lassista.

Gli hacker lo sanno. Pertanto, spesso cercano di entrare nella rete interna e quindi condurre attacchi per aumentare la portata del loro accesso attraverso la rete. Come primo passo di un attacco, gli hacker spesso hanno avuto successo nell'invio di malware "a testa di ponte" (che indica un malware che consente loro di connettersi a una macchina su una rete interna per stabilire un punto d'appoggio) tramite attacchi di phishing, exploit web e altri mezzi.

Questo è il modo in cui si verificano le violazioni - ad es. la violazione dell'inno. Una volta all'interno della loro rete interna, gli hacker hanno trovato facile recuperare database con molti dati privati poiché erano poco sicuri. L'ipotesi che "è sulla rete interna - è sicuro" si è rivelata una follia in questo caso.

Alla fine, devi determinare cosa pensi che sia il rischio di accedere alla rete interna da una terza parte; e poi quanto dannoso sarà il compromesso di quei dati. Se ti rende un po 'preoccupato, ti consiglio di implementare SQL injection e altre protezioni exploit sull'applicazione interna.

Non ammetto difetti di SQL injection sulle nostre pagine web interne. I motivi che offro sono:

• Proteggi i tuoi siti Web da utenti interni malevoli.
• Non esiste un sito Web interno. Quando un utente del sito Web interno dispone di un browser utilizzato anche per siti Web esterni, non è possibile affermare che il sito Web interno sia segmentato da Internet esterno. Il mio sito interno si fida del mio browser e se il mio browser è compromesso da Cross-site scripting, malware, clickjacking, falsificazione di richieste Cross-site, una cattiva estensione, un exploit java, un exploit flash o qualsiasi altro attacco web comune, quindi l'attaccante posso usare il mio browser per attaccare i siti interni.
• I difetti di iniezione SQL su un target a basso valore possono dare un appiglio in attaccando un obiettivo con un valore elevato.
• Proteggere dall'iniezione SQL, specialmente se lo fai mentre sviluppi le tue app, è una pratica a basso costo con premi elevati.