Le applicazioni web accessibili solo da una LAN possono essere considerate conformi agli stessi standard di sicurezza dei siti Web accessibili pubblicamente?

Sì. Assolutamente si.

Le tue ipotesi sulla tua rete interna hanno problemi:

• presumi che nessun utente malintenzionato possa mai ottenere il controllo di qualsiasi dispositivo nella tua rete, il che è una cattiva ipotesi da fare (vedi link , link ). Gli aggressori cercheranno un po 'di tempo per entrare in una rete, e c'è un mercato commerciale per acquistare host compromessi all'interno di aziende specifiche.
• si presuppone che solo gli utenti abbiano accesso, ma per quanto riguarda le terze parti, come i fornitori di servizi gestiti, gli appaltatori, i dipendenti temporanei? Inoltre, cosa succede se qualcuno si rompe in wifi? O guadagna l'accesso a una porta cablata (ad esempio un pwnplug )

Più in generale, c'è anche la questione del perché hanno due serie di pratiche / standard, quando sicuramente è più efficiente avere un unico standard che si applica ovunque?

Potresti trovare utile leggere il documento di Google su BeyondCorp, link .

Il tl; dr è che nella loro concezione della rete, fai affermazioni su utenti e dispositivi, ma non sulla rete - principalmente perché è più semplice assumere che tutte le reti siano ostili, piuttosto che assumerne alcune, e alcuni non lo sono (in parte, il costo di classificare erroneamente una rete come sicuro potrebbe essere molto, molto alto).

Una delle possibili ragioni per un simile approccio è che le perdite di Snowden hanno rivelato che le precedenti ipotesi sulla sicurezza della loro rete erano errate - la NSA sfruttò la fibra per attingere flussi di dati inter-DC (al momento non criptati).

Penso che la risposta di base alla tua domanda sia che il limite / il punto di demarcazione per la sicurezza non è più ai margini della tua rete, sono i dispositivi sulla tua rete. E in quanto tale, è sia più semplice, sia più realistico, concentrarsi sulla prevenzione di categorie di attacchi / abusi, piuttosto che considerare che una rete è "migliore" di un'altra. Potresti non aver bisogno di controlli così forti su una DMZ interna come faresti su una console esterna, ma assumere che la tua rete sia sicura è una pericolosa supposizione.

La superficie di attacco sulla rete interna e sulla rete esterna è diversa, il che significa che sono necessarie diverse misure di sicurezza. Ciò non significa che la superficie di attacco nella rete interna sia più piccola perché da un lato gli utenti sono solitamente più fidati e dall'altra parte ci sono dati più critici che sono spesso facilmente accessibili dall'interno.

Anche se tutti gli utenti sono affidabili, è comunque possibile che il loro sistema venga infettato da malware. A parte il fatto che molti degli attacchi che hai citato come CSRF, SQLi o XSS possono essere eseguiti in cross-origine, cioè è sufficiente che un utente interno visiti un sito Web esterno che utilizza il browser interno come trampolino per attaccare gli interni sistemi.

In sintesi: è necessaria una protezione adeguata anche per le reti interne, anche se tutti gli utenti possono essere considerati attendibili. Ciò è particolarmente vero se è possibile accedere sia alla rete interna sia a Internet dallo stesso sistema poiché ciò consente attacchi di origine incrociata da Internet contro i sistemi interni.

Alcune aggiunte alle risposte eccellenti:

• molte cose che dovresti fare per proteggerti da XSS (codificare correttamente i dati quando lo mostri, soprattutto) è anche necessario per prevenire una varietà di bachi che possono essere innescati da input perfettamente innocenti (non lo fai t desidera che un campo di testo venga interrotto solo perché contiene < o & nel posto sbagliato). Lo stesso vale per le iniezioni SQL (non si desidera che una query si interrompa perché esiste una citazione in un campo). Quindi devi comunque fare quella roba, anche se non è per sicurezza.

• c'è una strong tendenza per i browser a diventare sempre più restrittivi nei confronti dei siti non TLS, al punto che potrebbero diventare piuttosto inutilizzabili nel prossimo futuro (o per lo meno visualizzare così tanti avvertimenti che spaventerà i tuoi utenti).

• inoltre, anche se si stanno indirizzando solo gli utenti interni su una rete interna e potrebbero essere completamente fidati (vedere altre risposte per i motivi per cui non dovrebbero), le cose potrebbero cambiare in futuro. Potrebbe essere necessario aprire (parti di) il sito a utenti esterni (partner, fornitori, clienti ...). È molto più semplice prendere le giuste misure quando si sta facendo lo sviluppo iniziale piuttosto che aggiornare la sicurezza in un secondo momento.

Direi di no, principalmente a causa di questa citazione dal post originale specificato:

there are no outside users and the data inside the application is of not much use to attackers

La considerazione principale è che, anche in una rete interna, gli attori ostili possono ancora compromettere i sistemi che possono essere utilizzati per accedere alla tua applicazione web.

Il tuo modello di minaccia credo sia ancora una considerazione importante qui, e nonostante le preoccupazioni su cui un'applicazione può essere sfondata, se tutto ciò che stai proteggendo è il programma delle vacanze di Joe e gli inviti alle feste di Sally, potrebbe non valere la pena implementare HSTS, filtro HPKP e XSS, ecc.

La maggior parte dei malware che infetteranno le macchine locali non sarà progettata per eseguire una scansione di rete e trovare server Web intranet. Quelli che sono, probabilmente cercheranno pacchetti noti (anche se alcuni cercheranno solo nomi comuni e distruggeranno ogni modulo che possa trovare con exploit conosciuti)

Questo è simile alla sicurezza attraverso l'oscurità, ed è decisamente una cattiva pratica. Tuttavia, le preoccupazioni pratiche supereranno gli ideali in molti scenari. Consiglio comunque almeno un certificato autofirmato e HTTPS / TLS.

Un sistema come questo non può sopravvivere a un attacco mirato, ma dal momento che hai eliminato la superficie di attacco più comune (accesso pubblico a Internet), la maggior parte degli abusi automatici non troverà il tuo sito.

Crea un modello di minaccia. A seconda dei dati archiviati e delle minacce identificate, potresti scoprire che sono necessari standard di sicurezza diversi o che, tutto sommato, non c'è in realtà alcuna differenza cruciale.

Rispondere alla domanda in termini generali può andare in questo o quello, a seconda delle ipotesi assunte, come si può già vedere nelle risposte date. Ma alla fine, LAN o Internet pubblica è solo una variabile nel set e non puoi risolvere x = y + z con solo una delle variabili date.