Sebbene la risposta di Kyle Fennell sia molto valida, vorrei offrire una ragione per spiegare perché si consiglia di progettare in modo sicuro le applicazioni interne.

Un gran numero di gli attacchi coinvolgono attori interni

Esistono molte versioni differenti di questo fattoide. "Il 50% di tutti gli attacchi riusciti inizia internamente", "Due terzi di tutte le violazioni dei dati coinvolgono attori interni", ecc.

Una statistica che ho trovato è stata DBIR 2019 di Verizon, in che affermano:

Il 34% [delle violazioni dei dati analizzate] ha coinvolto attori interni

Qualunque sia il numero esatto, una quantità significativa di attacchi coinvolge attori interni. Pertanto, basare il tuo modello di minaccia su "è interno, quindi è sicuro" è una cattiva idea .

Secure Software Development non solo previene gli abusi, ma anche l'uso improprio

• Abuso: l'utente fa qualcosa di dannoso per il proprio guadagno
• Uso improprio: l'utente fa qualcosa di dannoso perché non saperne di più

Il motivo per cui parlo di un uso improprio è perché non tutto ciò che danneggia l'azienda è fatto intenzionalmente. A volte le persone commettono errori e, se le persone commettono errori, è bene che le macchine impediscano che tali errori abbiano conseguenze diffuse.

Immagina un'applicazione in cui tutti gli utenti possono fare tutto (perché l'impostazione delle autorizzazioni richiede molto tempo , non è stato pensato durante lo sviluppo, ecc.). Un utente commette un errore e cancella tutto. Ciò porta l'intero reparto a un punto morto, mentre l'IT subisce un attacco di cuore e si precipita nella sala server con il backup della scorsa settimana.

Ora immagina la stessa applicazione, ma con un sistema di autorizzazioni ben definito. L'utente tenta accidentalmente di eliminare tutto, ma elimina solo le attività assegnate. Il loro lavoro si interrompe e l'IT unisce i dati del backup della scorsa settimana con i dati correnti. Due dipendenti non potrebbero svolgere alcun lavoro produttivo oggi, invece di 30. Questa è una vittoria per te.

"Interno" non significa esente da malintenzionati

Alcune aziende sono tecnicamente un'unica azienda con più squadre, ma sono fratturate in modo tale che le squadre competono tra loro, piuttosto che lavorare insieme. Potresti pensare che ciò non accada, ma Microsoft è stato così per molto tempo.

Immagina di scrivere un'applicazione che deve essere utilizzata internamente da tutti i team. Riesci a immaginare cosa accadrebbe una volta che un dipendente capisce che potresti bloccare altri dipendenti per 30 minuti eseguendo uno script che ha creato? I dipendenti di "quell'altro team" verrebbero costantemente esclusi dall'applicazione. L'help desk sarebbe occupato per la 5 ^a volta di questa settimana cercando di capire perché a volte le persone resterebbero escluse dall'applicazione.

Potresti pensare che questo sia inverosimile , ma saresti sorpreso di quanto alcune persone si spingerebbero per ottenere quel dolce dolce bonus alla fine dell'anno per avere prestazioni migliori rispetto a "l'altra squadra".

"Interno" non rimane "Interno"

Ora, nel 2020, la tua applicazione verrà utilizzata solo da un piccolo gruppo di persone. Nel 2029, l'applicazione verrà utilizzata internamente da alcune persone, da alcuni fornitori e anche da alcuni appaltatori. E se uno dei tuoi fornitori scoprisse un difetto nella tua applicazione? E se vedessero che uno dei loro concorrenti ha condizioni molto migliori?

Questa è una situazione in cui non vorresti trovarti e che avresti potuto evitare.

Riutilizzo del codice dall'applicazione "interna"

Scrivi un'applicazione interna che esegue alcune operazioni di accesso al database. Funziona bene per anni e nessuno si è mai lamentato. Ora devi scrivere un'applicazione che accede agli stessi dati, ma esternamente. "Facile!", Pensa il programmatore alle prime armi. "Riutilizzerò semplicemente il codice che già esiste."

E ora sei bloccato con un'applicazione esterna in cui puoi eseguire iniezioni SQL. Perché all'improvviso, il codice che è stato creato "solo per uso interno", senza giochi di parole, viene utilizzato esternamente. Evitatelo mettendo a posto il codice interno in primo luogo.

Sarà sufficiente seguire OWASP?

La risposta a questa domanda è un'altra domanda "Basta per cosa?". All'inizio può sembrare nitido, ma illustra il problema. Che cosa vuoi proteggere esattamente?

Definisci un modello di minaccia per la tua applicazione, che includa chi pensi possa essere una minaccia per la tua applicazione in che modo, quindi trova le soluzioni per queste singole minacce. OWASP Top 10 potrebbe essere sufficiente per te, o potrebbe non esserlo.

Sì, le applicazioni interne dovrebbero essere protette con la dovuta diligenza e sì OWASP può essere una buona guida per proteggere la tua applicazione. Guarda anche il Security Development Lifecycle (SDL) di Microsoft, è un processo di garanzia della sicurezza incentrato sullo sviluppo del software.

Perché?

• Difesa in profondità . Un utente malintenzionato potrebbe violare le difese della rete. Metti più livelli di protezione tra loro e i tuoi dati.
• Le minacce esterne non sono le uniche. Le vulnerabilità delle applicazioni possono essere sfruttate anche da minacce interne .

Altri hanno già menzionato alcuni punti positivi su dipendenti malvagi, infiltrazione, difesa in profondità ... ma è molto più pratico di così. Posso attaccare la tua applicazione intranet interna da una pagina web casuale.

Le persone fanno clic sui link tutto il giorno. A volte perché un collega ha visto qualcosa che desidera condividere, a volte dai risultati di ricerca (o dagli annunci), a volte un'immagine di un simpatico gatto con mille voti positivi da un sito come reddit, a volte da email di phishing.

Ci sono un molti modi in cui un utente malintenzionato può indurti a fare clic su un collegamento. Scegliamo l'immagine del gatto: per quelle migliaia di altre persone che hanno votato positivamente l'immagine del gatto carino, era innocuo. Fino a quando qualcuno fa clic su la cui azienda utilizza il fantastico sito Web Intranet che non segue le linee guida OWASP.

Fare clic su collegamenti a pagine dannose dovrebbe essere per lo più innocuo: gli aggiornamenti regolari per il browser mantengono è protetto e non consente al sito Web di accedere al resto del computer. Ecco perché è così facile farti fare clic su un collegamento, perché è "per lo più innocuo". Ma ciò non significa che avere una pagina, che esegue codice JavaScript, all'interno della rete aziendale di destinazione non sia un vantaggio per l'attaccante.

La pagina con l'immagine del gatto potrebbe contenere qualcosa del genere:

  1. <img src = cute_cat.jpg>2. <iframe name = hiddenframe style = 'display: none'>< / iframe>3. <form action = 'http: //intranet.local/addUser.php? Username = joseph&password = 123456' id = myform target = 'hiddenframe'>4. <input type = submit style = 'display: none'>5. < / form>6. <script> document.getElementById ('myform'). Submit () < / script>  

All'apertura della pagina, in modo completamente invisibile, questo sarà in grado di chiamare la pagina addUser.php sulla tua applicazione intranet. Se hai effettuato l'accesso (come di solito sono al lavoro), il browser aggiungerà felicemente il tuo cookie di accesso (contenente il token di sessione mediante il quale la intranet riconosce che sei tu). L'aggressore ora ha un account sul tuo sistema. Per le persone senza l'applicazione intranet, non farà nulla.

Questo è un esempio di un attacco CSRF (Cross-Site Request Forgery) (più alcune altre cattive pratiche), che seguendo le linee guida OWASP impedire. Una breve panoramica di ciò che fa questo codice:

1. Mostra l'immagine del gatto per far sembrare la pagina innocua
2. Aggiungi una cornice nascosta (sottopagina) in cui la pagina intranet verrà caricato.
3. Aggiungi un modulo che verrà inviato alla tua intranet, chiamando la pagina addUser con un nome utente e una password, scelti dall'aggressore.
4. Nascosto Il pulsante di invio è necessario affinché il modulo funzioni.
5. Fine del modulo.
6. Chiama submit () sul modulo, in modo che il pulsante di invio si attivi.

Se la pagina addUser.php non ha (o controlla) token anti-CSRF, questo attacco è possibile al 100% e molti siti erano vulnerabili a questo nel passato. Un esempio? L'intranet della mia scuola in cui sono stati registrati i voti. Avrei potuto inviare a un insegnante un collegamento a una consegna digitale e la pagina avrebbe potuto (oltre a mostrare la mia consegna) aver cambiato i miei voti (o quelli di chiunque altro!) In background.

È ancora comune oggi. Ecco un altro esempio, molto più semplice (e meno dannoso):

  1. <img src = 'cute_cat.jpg'>2. <img src = 'http: //intranet.local/logout.php'>  

Questo chiama solo la pagina di logout. Il browser si aspetta un'immagine da quella pagina logout.php , ma se non c'è immagine (perché è una pagina di logout), scarta semplicemente il risultato. Nel frattempo, l'applicazione intranet ti disconnette. Se l'aggressore riesce a attivarlo ogni 2 secondi da una scheda che mantieni aperta per un po ', potresti non essere in grado di utilizzare l'Intranet perché continui a essere disconnesso.

Ricordi la gigantesca violazione di Capital One nell'agosto 2019?

La causa principale era una vulnerabilità SSRF (server-side request forgery) in un'app Capital One interna.

Quindi sì, devi preoccuparti del design sicuro sulle app interne.

Quale piattaforma? Prima di ritirarmi, dovevo assicurarmi che qualsiasi cosa scrivessi non potesse non non riuscire a gestire tutte le eccezioni. qualsiasi eccezione non gestita presenterebbe all'utente un pop-up che lo prega di inviare dati a Microsoft che potrebbero contenere informazioni personali che Microsoft promette di non utilizzare.

Ovviamente, la maggior parte degli utenti farà prontamente clic su OK senza leggere. E indipendentemente dal fatto che Microsoft onori questa promessa, l'invio dei dati renderebbe l'ospedale passibile di accusa ai sensi dell'HIPAA. E HIPAA richiede a Microsoft di segnalarci se rileva informazioni sul paziente.

MacOS ha un popup simile e se l'utente non lo disattiva in anticipo nelle impostazioni, IOS invia i dati senza chiedere .

E poi c'è Android, codificato da uno dei maggiori concorrenti della NSA.

Quindi, la risposta è "sì" per ognuna di queste piattaforme.

Assolutamente al 100% sì”.

Per tutti i motivi addotti e per uno pratico molto importante: non si sa mai in quale giorno qualcuno nella gestione decide di mettere quella cosa sul Internet. "Funziona così bene, i nostri appaltatori esterni dovrebbero usarlo." o qualche altro motivo.

Vuoi rifattorizzarlo completamente quando ciò accade?

Una cosa molto comune che accade in un'azienda è che le persone apprezzino l'utilizzo di uno strumento interno, lo menzionino a un partner o cliente e poi si chieda a gran voce che lo strumento sia reso disponibile agli utenti esterni.

Sì, utilizza alcune precauzioni di sicurezza sullo strumento e non impedirti di proteggerlo in futuro. Le cose più semplici fanno molto, come "creare un utente dedicato invece di root per questo processo" e "limitare la visibilità dell'utente e del processo solo alle cose di cui lo strumento ha bisogno".

Pubblicherò qui una dichiarazione piuttosto generale, ma se la tua applicazione è codificata in modo professionale e segue le migliori pratiche, dovrebbe essere già abbastanza sicura fuori dagli schemi. Almeno le vulnerabilità più comuni come SQL injection non dovrebbero essere sfruttabili.

E i framework di sviluppo disponibili oggigiorno ti semplificano effettivamente il lavoro. D'altra parte, se dai la priorità alla velocità di sviluppo rispetto alla qualità, se sei bloccato con le linee guida di codifica degli anni '90, se non usi query parametrizzate ... allora stai cercando guai.

Per lo meno dovresti reprimere la tua applicazione per assicurarti che gli errori più evidenti non siano presenti nel tuo codice e che uno script kiddie non possa compromettere il tuo sistema lanciando un attacco automatico.

Come dice Tom, le cose che sono isolate oggi potrebbero essere esposte su Internet domani, a causa di una decisione di gestione o di un'errata configurazione del router / firewall. L'applicazione potrebbe essere scoperta per sbaglio, senza che tu te ne accorgessi, o dopo che hai lasciato l'azienda.

E rimarrai sorpreso di come i dipendenti annoiati trascorrono il loro tempo libero. Una volta ho trovato un port scanner sulla postazione di lavoro di un impiegato amministrativo che non è assolutamente esperto di computer. Lo strumento non è atterrato lì per caso. Troppo spesso, i dipendenti sono l'anello debole di qualsiasi organizzazione.

Quindi il livello appropriato di paranoia dipende dal tipo di risorse a cui la tua intranet sta dando accesso. Se le risorse sono piuttosto sensibili e l'applicazione viene hackerata un giorno, il tuo lavoro potrebbe essere in linea se l'indagine forense mostra che il tuo codice era sciatto e non rispettava le pratiche di sicurezza minime. La peggiore delle ipotesi è che vieni citato in giudizio dal tuo datore di lavoro / cliente per negligenza professionale - sicuramente deve accadere di tanto in tanto.

Mi chiedo cosa sia successo ai ragazzi IT che hanno lavorato in Equifax?

Considera anche la topologia di rete. Se l'intranet è ospitata internamente e collegata direttamente alla tua LAN, allora è un gateway per la tua LAN e altre risorse. Se sono un attaccante e voglio entrare nel tuo sistema, cercherò punti deboli, percorsi indiretti ma trascurati.

Quindi riformulerei la domanda in questo modo: In quali circostanze non è necessario progettazione software sicura?

Pensa al tuo datore di lavoro / cliente, ma pensa anche alla tua reputazione. C'è una buona probabilità che un giorno qualcun altro guarderà il tuo codice. Ad esempio un altro ragazzo IT che ha il compito di migrare l'applicazione in futuro, qualsiasi cosa. Qualcuno che forse è più informato di te e non avrà niente di carino da dire quando guarderà il tuo codice.