Protezione delle applicazioni Web con solo un proxy inverso

Sulla base della mia comprensione, penso che non hai nemmeno bisogno di entrare nella rete interna per dimostrare che è una pessima idea. Un utente malintenzionato (che può essere un ex dipendente, un appaltatore di terze parti o un dipendente scontento esistente) con qualche contesto su questa applicazione interna non sicura, compresi dettagli come indirizzo host interno in cui è ospitata l'applicazione, < em> funzionalità importanti dell'applicazione, una certa conoscenza di aspetto generale dell'applicazione (questo ovviamente aiuterà a creare un sito web phising) e, naturalmente, il fatto che l'applicazione sia vulnerabile ai problemi più comuni delle applicazioni Web (in particolare Falsi di richiesta tra siti ).

Va bene. Sulla base delle ipotesi di cui sopra, posso pensare ai seguenti possibili attacchi:

• Trucca un utente interno nel fare una richiesta di modifica dello stato all'applicazione sfruttando una vulnerabilità CSRF . Questo può essere usato per sfruttare altre vulnerabilità comuni nell'applicazione inducendo un utente autenticato a visitare il tuo sito Web, dove il tuo JavaScript sarà in attesa di fare richieste all'applicazione con i tuoi payload , ma con il < em> cookie di sessione della vittima . È possibile inviare payload di iniezione per l'iniezione di comandi, SQL injection, XSS, ecc. Poiché si conosce la superficie di attacco, è possibile creare le richieste di conseguenza.

• Sfruttamento di un'implementazione di JSONP o CORS mal configurata nell'applicazione . Di nuovo, per questo, utilizzerai la vulnerabilità CSRF per fare una richiesta all'applicazione interna con i loro cookie di sessione. Ma questa volta, invece di eseguire una richiesta di modifica dello stato, il tuo JavaScript dannoso rileverà la risposta sensibile dall'applicazione (a causa di JSONP e CORS). Puoi leggere ulteriori informazioni al riguardo qui , qui e qui .

• Utenti interni di phishing (tramite avvelenamento della cache DNS, forse) . Ora che sai come si presenta l'applicazione intenal, puoi creare un sito Web di phishing o solo la pagina di accesso per l'applicazione e ospitarla su un indirizzo pubblico. È quindi possibile avvelenare la cache DNS del server DNS aziendale all'interno della rete o semplicemente modificando il file host dei sistemi interni (magari ingannandoli nel download di un malware). Quest'ultimo passaggio è un po 'complicato da sfruttare al di fuori della rete, ma spero che tu abbia l'idea. Ulteriori dettagli sull'avvelenamento della cache DNS nel caso in cui siate interessati a ulteriori letture: Avvelenamento della cache DNS e DNS . Una volta configurato, non c'è nulla che ti impedisce di phishing agli utenti interni perché l'applicazione non è su TLS (nessuna autenticazione)!

Ecco come si avvicina la tua situazione in generale.

Parla all'azienda

Ci sono tre cose su cui penso che i clienti possano realmente relazionarsi quando discutono della sicurezza delle loro applicazioni. (90% delle volte che gli utenti sono una nota a piè di pagina) .

1. IP (Proprietà intellettuale). Nessun cliente desidera che i suoi segreti siano disponibili per la loro concorrenza.
2. Immagine. Le aziende possono essere gentilmente motivate in migliori misure di sicurezza se la reputazione e l'immagine sono in gioco. Questo può essere particolarmente vero se il tuo cliente si trova in un ambiente altamente competitivo in cui una violazione potrebbe inviare utenti che si affollano alla concorrenza.
3. Denaro. Nulla spinge un'azienda ad agire più di quella minaccia di perdere denaro. In sicurezza, è il tempo e le spese per l'assunzione di ulteriori aiuti esterni, e in situazioni di conformità, sono anche le multe, che si sommano.

Parla con il team

Nel mondo della sicurezza, il rischio è il gioco che giochiamo e il nostro compito è convincere le aziende ad adattarsi. Dal punto di vista tecnico, noi del team di sicurezza consideriamo questo tipo di scenario come "QUESTA E 'UNA COSA DI BASE". Dal punto di vista delle imprese, il loro pensiero è "Qual è la reale possibilità che io possa essere compromesso?"

Non conosco il tuo cliente o la sua rete, ovviamente, ma ecco le basi su come iniziare (un tentativo di non dare giudizi quando si fanno domande):

• Qual è la loro "rete sicura come"? Fanno le migliori pratiche? Le cose restano aggiornate?
• Perché non vogliono applicare la sicurezza? Base di conoscenza? I soldi? Nel tuo caso il debug.
• La loro ragione per non fare qualcosa può essere risolta in un modo più sicuro? Mi viene in mente il debug in un ambiente di test.

Infine, parla al livello

Le piccole imprese non sono una società media che non è una grande società che non è una fortuna 500 mi cattura? Ci sono desideri, bisogni e capacità a tutti i livelli e se dovessi dire a un cliente di aver bisogno di altri 50K di dispositivi di sicurezza, avresti un business molto riluttante con cui lavorare.

Le tre cose su cui vorrei concentrarmi:

• Parla con il loro settore. Sapere come l'industria medica fa qualcosa è bello, ma se lavorano nei controlli industriali, a loro non importa.
• Speck al loro margine di profitto. Ciò risale alle mie precedenti affermazioni sulla dimensione di un'azienda. Un hamburger King non ha le risorse di Apple.
• Parla con le loro esperienze. Se la loro industria o competizione ha avuto una breccia, parlaci. Solitamente sapranno (la parola va in giro), se non l'hanno ascoltata, rafforza i concetti che potrebbero e sono probabilmente presi di mira.

So che questo non parla esattamente con il problema del proxy ma non posso essere specifico su una situazione client dettagliata senza conoscere il client.

Un utente interno con un browser che si connette anche all'esterno fornisce percorsi tra l'intranet e l'internet pubblico. Lo dico costantemente a chi mi dice "non preoccuparti, questa è un'app web interna".

HTTPS è necessario nel tuo caso. Questo non solo protegge dalla minaccia che hai citato, da qualcuno che ha violato la rete, ma anche dagli insider malintenzionati che non hanno bisogno di intrufolarsi. Oltre a esporre i dati sensibili in sé, senza https esporresti le credenziali in testo non crittografato, credenziali ciò potrebbe fornire un ulteriore accesso alle risorse interne. Il problema è peggiorato se il wireless è in uso internamente.

Sembra che gli utenti interni di queste applicazioni web non abbiano alcun controllo di accesso. Sento che il controllo degli accessi dovrebbe essere integrato nelle applicazioni stesse.

Se desiderano semplificare il debug, disponi di un ambiente di prova con i controlli di sicurezza disattivati.

Il nostro reverse proxy (Pound) fornisce davvero una funzionalità di sicurezza: agisce da intermediario tra client esterni e le nostre risorse web. Questo ci permette di usarlo per impostare la politica di accesso. Questo è uno dei tuoi livelli di protezione per le sensibili applicazioni Web interne che desideri proteggere, ma non penso che dovrebbe essere l'unico livello.

Personalmente farei 3 cose in questa situazione:

1. Mostra al cliente i dati sulla percentuale delle principali violazioni che sono il risultato del phishing (qualcosa come 95-97%)

2. Mostra inoltre che il phishing può portare direttamente a un utente malintenzionato lo sniffing del traffico sulla rete e può visualizzare ogni bit di dati che passa da questi servizi.

3. Identificare la quantità e la qualità dei dati che vengono trasmessi da questi servizi Web e presentarli al client insieme a un modello di rischio che tenta di quantificare il costo potenziale in relazione al traffico di tempo di attacco dell'utente.

Questo si riferisce principalmente alla mancanza di SSL, ma data la tua situazione, questo sembra essere il problema più urgente.

Buona fortuna con i tuoi sforzi. Capisco quanto sia difficile enfatizzare la sicurezza per un client riluttante. Tuttavia, devi sempre ricordare che il tuo compito è aumentare il valore del business, mostrare loro come puoi farlo e inizieranno a vedere la tua prospettiva.

Gli attacchi informatici più comuni sono riassunti molto bene nell'annuale Rapporto di violazione di Verizon: link

Come si può leggere qui, gli attacchi di phishing e di furto di credenziali sono due delle minacce più comuni. Pertanto, se un sistema interno viene compromesso da qualcuno che fa clic accidentalmente su un collegamento dannoso, un utente malintenzionato si trova ora all'interno della rete, probabilmente in grado di visualizzare tutto il traffico non TLS nella subnet di quel sistema. Quindi, tale utente malintenzionato può acquisire credenziali e accedere al server Web internamente senza mai utilizzare il proxy inverso.

Inoltre, se le persone riutilizzano le credenziali (comuni), potrebbero non sapere che le loro password vengono inviate in chiaro. Un utente malintenzionato potrebbe quindi utilizzare tali credenziali su ALTRI sistemi, forse con successo in alcuni casi. Questo non solo apre il business fino a possibili violazioni, ma la responsabilità se questo viene scoperto (io non sono un avvocato - per favore discuti con il procuratore e / o le compagnie di assicurazione).

Spero che questo aiuti a rendere il tuo caso.

Ci sarà infine un caso in cui un'azione perfettamente autorizzata a livello di proxy sarà in grado di provocare un comportamento imprevisto in un componente back-end. È una questione di quando , non se . Questa è una pessima idea. I tuoi istinti su questo sono corretti. Fai tutto il possibile per convincere il tuo cliente che non dovrebbero procedere lungo questo percorso.