Domanda:
L'utente non può navigare alla pagina web tramite l'interfaccia utente a causa delle autorizzazioni, ma può navigare nella pagina incollando l'URL. Come mi proteggo da questo?
Michael
2017-10-10 21:33:32 UTC
view on stackexchange narkive permalink

Nella mia applicazione, gli utenti hanno determinati ruoli con autorizzazioni. Queste autorizzazioni determinano quali elementi dell'interfaccia utente sono disponibili per loro nella schermata iniziale. Molti degli elementi rimandano ad altre pagine, che molti utenti non possono vedere perché le loro autorizzazioni non consentono loro di accedere a quella pagina web.

Ad esempio, un pulsante chiamato pulsante1 collega a una pagina casuale nell'applicazione, diciamo http://www.example.com/example.jsp . L'utente John, tuttavia, dispone di autorizzazioni impostate che non gli consentono di vedere button1 . Pertanto John non può andare su http://www.example.com/example.jsp.

Il problema che sto riscontrando è che se ho effettuato l'accesso come John, e Se incollo quell'URL, mi porterà alla pagina.

Ovviamente questo è un enorme rischio per la sicurezza se un attaccante ottiene l'URL a una pagina di amministratore, ad esempio. Quindi, come posso proteggermi da questo? Devo verificare l'utente per ogni singola pagina, controllare i permessi e assicurarmi che sia autorizzato a essere lì?

Ci sono centinaia di pagine in questa applicazione e sembra molto ridondante e non efficiente da includere codice su ogni pagina per farlo. C'è un modo più semplice per farlo rispetto al metodo che ho appena citato?

Sono curioso se questo è considerato lo stesso problema di "[Forced Browsing] (https://www.owasp.org/index.php/Forced_browsing)"?Quella pagina lo descrive come trovare pagine che non avrebbero mai dovuto essere pubbliche, piuttosto che aggirare i controlli delle autorizzazioni degli utenti.
@Michael Se l'esecuzione del codice su ogni pagina richiede effettivamente la modifica di ciascuna pagina individualmente, probabilmente stai facendo anche altre cose sbagliate.Se non disponi di controlli di sicurezza e integrità a livello di sito, dovresti aggiungerli il prima possibile.Gli sviluppatori hanno una formazione sulla sicurezza?Ci sono bandiere rosse ovunque qui e aggiustare le cose che trovi lascerà le cose che non hai trovato non risolte.
Poiché sembra che la tua applicazione sia basata su servlet, vale la pena guardare Spring Security (non devi usare Spring per usarlo, anche se Spring è fantastico).
Sì, ogni pagina e ogni azione distruttiva e ogni azione che espone dati privati.Quello che hai qui è chiamato "preoccupazione trasversale"
Le autorizzazioni non dovrebbero essere applicate nascondendo semplicemente gli elementi dell'interfaccia utente;) ma con le risposte penso che tu lo capisca ora
Provo sempre a cambiare l'URL ust per divertimento.Quando c'è solo un enable.php provo ad esempio disable.php.
Se attualmente stai eseguendo controlli di sicurezza a livello di client (il che è utile per evitare query inutili al server, ma in nessun modo protetto), potresti avere altri problemi di sicurezza, come le SQL injection.Assicurati che il tuo server gestisca correttamente tutti i dati che il tuo client gli invia (e sì, poiché tutti hanno già menzionato il tuo server devono assicurarsi che l'utente attualmente connesso sia autorizzato a eseguire la query HTTP corrente).
Non ho letto le parole magiche in nessuna risposta.**Fare.Non.Fiducia.Ingresso.Mai.**.
@usr-local-ΕΨΗΕΛΩΝ assolutamente, quella regola applicata accuratamente ti fa fare molta strada verso una ragionevole sicurezza.
@danbru1211 Pensavo di essere entrato accidentalmente in una cosa di rete fino a quando non ho capito che era solo una demo del prodotto che l'azienda stava vendendo.La "sicurezza" della password era un hash `md5` lato client, e si rompeva completamente se facevi qualcosa di simile a quello che hai descritto.Tuttavia, è un ottimo modo per eseguire test di penna davvero di base.
Ho uno script GreaseMonkey che mi permette di vedere ** tutti gli elementi nascosti ** sulla pagina premendo ** solo un tasto **!Immagina solo cosa posso fare al tuo sito web se mi preoccupo davvero di leggere il codice sorgente!
"* Il problema che sto riscontrando è che se ho eseguito l'accesso come John *" - Perché puoi accedere agli account degli altri a piacimento in primo luogo?
L'implementazione dell'interfaccia `javax.servlet.Filter` è quello che vuoi.Ti consente di elaborare ogni richiesta.Btw jsp è grossolanamente obsoleto e, a meno che non si tratti di un progetto universitario, dovresti eliminare rigorosamente Java EE e procedere con framework più moderni che hanno tutte queste necessità di base integrate.
Mi dispiace ma sembra che tu non abbia alcuna comprensione della sicurezza delle applicazioni web di base.Dovresti dare un'occhiata alla [OWASP Top Ten] (https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project).
Mi stupisce quanto sia comune questa situazione ...
Sette risposte:
Trickycm
2017-10-10 21:43:34 UTC
view on stackexchange narkive permalink

Devo verificare l'utente per ogni singola pagina?

Assolutamente. Non solo ogni pagina, ma ogni richiesta a una risorsa privilegiata, ad esempio richiesta POST per aggiornare dati, eliminare, visualizzare, ecc. Ecc. Non si tratta solo di visualizzare le pagine, si tratta di controllare chi può fare cosa sul tuo sistema.

Sembra che l'intero sistema di autenticazione e autorizzazioni sia danneggiato nella sua attuale implementazione. I passaggi per rimediare a questo problema sono troppo ampi per questa risposta. Varrebbe la pena fare una ricerca generale in questo forum e nella rete più ampia per trovare soluzioni adatte al proprio framework (JSP, ASP.Net, PHP, ecc.). La maggior parte dei framework dispone di funzionalità predefinite per risolvere questo problema.

Un buon inizio sarebbe questa guida di alto livello di OWASP: Sicurezza operativa: interfacce amministrative.

Voglio solo ribadirlo perché la tua risposta non è una cosa da poco da fare nella fase dei PO: Sì, questa è assolutamente la risposta corretta e unica.Ogni singola pagina deve applicare correttamente le regole di sicurezza.Sembra che tutto ciò che è in atto al momento sia la sicurezza lato client, che in realtà non fornisce alcuna sicurezza.Esistono modi per scrivere il codice in modo da poter applicare facilmente la sicurezza su ogni pagina, ma non esiste risposta che non implichi l'applicazione della sicurezza su ogni singola richiesta.Altrimenti non hai alcuna sicurezza.
Per essere un po 'più precisi di quello che dici Trickycm, idealmente, devi trovare una soluzione unificata per gestire sia i link di navigazione / pulsante / ... che la navigazione URL diretta.Dal momento che è unificato, hai meno possibilità di dimenticare una cosa.Perché se non lo è, significa che devi sempre gestire almeno due diverse dichiarazioni della stessa sicurezza (nota: attualmente ce l'ho e ho bisogno di unificarla,: 3).
Solo una nota: anche le ** richieste AJAX ** sono richieste e ** devono essere verificate **.Non importa che questa particolare richiesta AJAX debba avvenire solo da una pagina che ha già verificato l'utente.So che questo rientra in "ogni richiesta" nella risposta.assicurandomi solo che anche OP lo sappia.
Un punto in più: questo controllo deve essere eseguito ** sul server ** - non tramite codice javascript eseguito (o meno) sul client.Un utente malintenzionato può evitare di eseguire il codice javascript.
Infine: usare javascript per nascondere i collegamenti a cui l'utente non ha accesso va bene, ma è questione di avere una bella interfaccia utente, non di sicurezza.
Potrebbe essere utile includere il termine "autorizzazione" da qualche parte in questo post, poiché è anche un termine comune per descrivere il controllo / gestione delle autorizzazioni e quindi potrebbe essere utile nella ricerca.
@MartinBonner Preferirei "nascondere" i collegamenti in PHP - potrebbe essere più lento, ma se l'HTML non fosse mai generato per questi collegamenti, il cliente / utente non sarebbe più saggio anche se passassero il codice sorgente tramite un browserispettore.
@psosuna Perché sarebbe importante se il client / utente potesse trovare gli URL?Non possono * fare * niente con loro.Se provano a utilizzare questi URL, il server dirà semplicemente "Mi dispiace, non sei un amministratore".
@immibis per motivi di pulizia, semmai.Potrebbe essere che ci sia * l'unica pagina * nel sito che non impone la sicurezza (come dovrebbe essere!) E l'indirizzo ad essa può essere scoperto ispezionando la fonte sul lato client.Per mitigare questa possibilità è meglio non rivelarla, no?Meglio prevenire che curare, dico.
@psosuna: [scrollata di spalle] Non mi interessa molto dove nascondi i link.Il punto è che nascondere i collegamenti non riguarda la sicurezza, ma una buona UX.(Anche se è un caso in cui una buona UX non è certamente in conflitto con la sicurezza.)
@MartinBonner è totalmente d'accordo con te, ma in generale, la sicurezza riguarda i livelli.E anche se nascondere i collegamenti non è ovviamente sicurezza, può aiutare.Se c'è un bug da qualche parte nel controllo di sicurezza, non avere i collegamenti aggiunge ancora qualcosa, quindi preferisco anche non inviare i dati ai client in primo luogo.(Lo vedo come un altro livello).
A tutti gli effetti, tutte le risorse / richieste che il tuo server non sta autenticando e autorizzando direttamente devono essere considerate pubbliche.Se non controlli che la richiesta X provenga da un utente registrato con le autorizzazioni appropriate, la richiesta X è pubblica e può essere acceduta da chiunque, indipendentemente da ciò che fornirà la tua interfaccia utente.
Stilez
2017-10-11 22:42:57 UTC
view on stackexchange narkive permalink

La risposta rapida è sì, come hai capito. Ma non è necessario che sia l'enorme lavoro a cui stai pensando. (L'intera questione della sicurezza potrebbe essere grande, ma questa è solo una parte di essa). Hai problemi molto più seri di così.

Perché è importante

QUALSIASI COSA che crei sarà colpito dai tentativi di romperlo. Qualcuno sarà curioso. Qualcuno farà qualcosa che non ti saresti mai aspettato e che sfida il tuo pensiero. Qualcuno sarà curioso, o malizioso o ficcanaso.

Dovresti anche dare per scontato che il tuo software / app web verrà sottoposto a duri test con strumenti automatizzati . I server con un portale online (di quasi tutti i tipi) vengono scoperti dagli hacker entro decine di minuti dal primo accesso online e iniziano a essere indagati per una qualsiasi delle migliaia di possibili errori di sicurezza o sviste. Ciò significa che sondano ciò che è esattamente in esecuzione "dietro le quinte", nonché eventuali errori rilevabili che possono essere sfruttati (nella convalida dei dati, nella convalida del cross scripting, SQL o iniezione binaria, hacking JavaScript, i punti deboli possono sorgere costringendo qualcosa a fallire, quali dati possono essere esposti ...).

I tuoi server web verranno controllati in questo modo, costantemente, per ogni possibile codice web e errori di back-end, da centinaia se non migliaia di strumenti automatizzati. Questo va bene come gli umani e gli utenti, non al posto di.

Preferiresti che questo fosse molto lontano e portato alla tua attenzione con forza da critici, media e utenti arrabbiati, o portato alla responsabilità? O preferiresti risolverlo?

Come risolverlo

Non è un lavoro enorme in un certo senso. Si crea un framework di sicurezza e quindi ogni pagina lo importa o lo utilizza. I concetti per farlo non sono difficili e sono ben documentati. Quindi il numero di pagine non è un grosso problema.

La parte difficile del lavoro è che la sicurezza è difficile . Il tuo vero problema è che, dal fatto che ci sono questi problemi e stai facendo queste domande, non ne sai abbastanza per avere una speranza di farlo senza aiuto. Sul serio. Tu. Fare. No.

Non so quale sia la dimensione della tua squadra o delle risorse. Ne hai bisogno e probabilmente non hai alcuna speranza di farlo senza un aiuto esterno.

La mia vera preoccupazione qui

Detto questo, la mia vera preoccupazione non è l'app web . È la mentalità che suggerisce questa domanda.

Immagina che stia pensando di acquistare o utilizzare la tua app.

Non aiuta né rassicura il lettore il fatto che tu consideri la sicurezza come un ripensamento, un'interruzione del tuo lavoro o un inconveniente da risolvere in seguito (o non lo capisci abbastanza da averlo trattato in quel modo), e forse i problemi sono cose davvero fondamentali, come codificare correttamente l'URL di un pulsante .

La sicurezza è il tuo lavoro, perché per quanto tecnicamente meraviglioso sia il prodotto / servizio e chiunque siano i suoi utenti, il tuo prodotto reale è la fiducia e la rassicurazione che risponderai alle mie esigenze e non mi causerai un grave disastro.

Dovrei fidarmi della tua app con i miei dati? In questo momento, e mi dispiace dirlo, penso che potrei anche pubblicarlo su Google+ da solo. Sì, è "quella brutta" situazione e impressione, e no questo non è esagerato per l'effetto.

Mi dispiace.

Ora, se la tua app è valida, coinvolgi qualcun altro.

L'ultima parte di questo sembra suggerire che i clienti decidano sui prodotti in base alla sicurezza.Tranne che in alcune nicchie molto, molto specifiche, questo non è vero e da un PoV aziendale è un'idea orribile spendere più del necessario per requisiti non funzionali come la sicurezza come startup.Sì, tutti qui odiano questa mentalità, ma resta il semplice fatto che gli utenti non si preoccupano della sicurezza e anche se lo facessero non potrebbero giudicare cosa è sicuro e cosa no (non ci credi? Vai avanti e controlla ilnumeri utente di TextSecure / Signal con WhatsApp)
Stai pensando in anticipo.Non inizialmente, no.Ma una volta che un problema importante diventa noto, sì.Una volta che colpisce le recensioni, sì.Una volta che i social media iniziano a ricevere commenti come "Che cosa è successo e come potrebbe accadere" da più di una o due persone, sì.Le persone non cercano attivamente la sicurezza, ma guardano le recensioni e la conoscenza pubblica, se è disponibile, e lo sarà dopo un po '.(Sono d'accordo che sarebbe più bello se guardassero prima, ma se è un grosso problema, come indica l'OP, diventerà visibile abbastanza velocemente - proprio quando qualcosa va a rotoli e qualcuno lo pubblica con rabbia)
Silencer310
2017-10-11 02:46:02 UTC
view on stackexchange narkive permalink

Devi controllare il livello di autorizzazione utente per ogni richiesta (GET, POST, PUT, DELETE). La navigazione in una pagina, come nel tuo caso, è una richiesta GET. Un utente non dovrebbe essere in grado di pubblicare una richiesta anche senza autorizzazione.

Ora se hai bisogno di aggiungere il codice su ogni pagina della tua applicazione dipende dal framework della tua applicazione. Ad esempio, alcuni framework (Laravel, Express.JS) consentono di raggruppare le rotte e applicare un filtro a ciascuna richiesta per quella rotta, ed è qui che si inseriscono i controlli. Per le applicazioni in PHP semplice, dovresti avere il codice su ogni pagina, puoi usare l'istruzione "include" per ridurre al minimo la ripetizione dell'intero blocco del tuo codice.

HEAD o anche qualsiasi altro [strano metodo HTTP] (https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods) (a meno che tu non li blocchi * sempre *).
psosuna
2017-10-11 04:11:22 UTC
view on stackexchange narkive permalink

È già stato detto, ma sì, dovresti verificare le tue credenziali utente su ogni pagina. Se il tuo sito utilizza PHP, ad esempio, il modo più semplice per farlo è salvare l'utente connesso e il suo livello di privilegio nelle variabili di sessione, quindi eseguire una verifica di queste variabili di sessione all'inizio del codice. Questi vengono cancellati al logout (se è stata creata una logica di logout per cancellare queste variabili) o al timeout della sessione (il tempo per il timeout può essere definito, ma penso che il valore predefinito sia 5 minuti di inattività), quindi un utente non autorizzato non dovrebbe essere in grado di accedere una pagina. Altre tecnologie avranno una gestione simile.

Non voglio davvero sembrare condiscendente quando dico questo, quindi spero che tu non lo veda sotto quella luce, ma questa è una sorta di informazione di base . Se in qualche modo non l'hai imparato o non l'hai riscontrato nei tuoi studi personali, ti consiglio caldamente di prenderne atto e di leggere un po 'più in profondità su questo particolare argomento, perché è molto importante. Lo farai più e più volte per qualsiasi applicazione simile del genere.

Tieni presente che ci sono vari modi per farlo in modo semplice ed efficiente, e un mio suggerimento personale sarebbe quello di esercitarti a codificarlo nella tua logica in modo da capire appieno come funziona funziona, prima di tentare di utilizzare un framework. Provalo con diversi metodi di accesso e, una volta soddisfatto, puoi esaminare come i vari framework eseguono la gestione delle sessioni utente.

EDIT : ho inserito questo in un commento in basso, ma questa è in realtà una buona risorsa anche per OP: https://www.w3schools.com/ php / php_sessions.asp

Quali garanzie di sicurezza fornisce PHP per queste variabili di sessione?Sono memorizzati sulla macchina client;se no, come fa un client a identificare la sua sessione?I dati lato client sono crittografati?Esistono garanzie contro la condivisione dei dati lato client?
Ecco una rapida e semplice spiegazione delle sessioni PHP: https://www.w3schools.com/php/php_sessions.asp.Le informazioni e le variabili di sessione non vengono archiviate sul lato client, ma solo sul lato server.Una chiave viene fornita dal server al client.La chiave viene utilizzata per identificare la sessione in cui l'utente è al momento.
@jpmc26 un'ulteriore aggiunta: PHP = Hypertext * Pre- * processore.Ciò significa che il codice PHP viene eseguito sul lato server.Viene eseguito prima dell'HTML, quindi ci sono molte cose che non devono essere trasmesse alla macchina dell'utente.Questo è il motivo per cui PHP è una buona opzione per eseguire l'autenticazione, poiché i dati di input possono essere verificati prima che una risposta venga rispedita al client.
Oh, ho abbastanza familiarità con PHP come tecnologia lato server.(Lavoro su app web per vivere, ma non su PHP.;)) Ma so che * qualcosa * deve essere archiviato lato client affinché la sessione utente sia identificabile.Da qui le mie domande sul fatto che questi dati siano crittografati e cosa hai (per prevenire il dirottamento della sessione o condividere intenzionalmente la chiave con un altro utente).Vedi [questa critica] (https://security.stackexchange.com/a/18898/46979), per esempio.Non so se alcune di queste cose sono cambiate negli ultimi 5 anni, però.
@jpmc26 Penso che le critiche siano scarsamente mirate: si tratta di server condivisi configurati male in modo che gli utenti possano accedere ai dati degli altri.Piuttosto che crittografare, la risposta è mettere le sessioni in una directory a cui altri utenti non possono accedere;se non esiste tale directory, potranno comunque accedere alla tua chiave di decrittazione.Inoltre non ha nulla a che fare con il dirottamento della sessione, che generalmente descrive un utente malintenzionato che ruba l'identificatore di sessione * sul lato client *;la crittografia non sarebbe stata d'aiuto neanche in questo caso.
@jpmc26 Per paura di andare troppo fuori tema, mantieni le sessioni al sicuro con i token csrf.Ogni azione che intraprendi aggiorna il token (quindi richiedo qualcosa con il mio token => il server invia un nuovo token da utilizzare per la prossima cosa).
Majid Khan
2017-10-10 22:11:12 UTC
view on stackexchange narkive permalink

L'utente non deve essere in grado di navigare nella pagina indipendentemente dal fatto che digiti l'indirizzo o faccia clic sul collegamento.

Una soluzione generica al tuo problema è utilizzare un controllo degli accessi basato sui ruoli ( RBAC). Crea gruppi diversi e assegna utenti con privilegi uguali al gruppo corrispondente. Allo stesso modo, raggruppa pagine web e altre risorse all'interno di cartelle diverse; ciascuno di proprietà di un gruppo specifico. Avevo usato chgrp (cambia gruppo) per ottenere ciò su un sistema che esegue Linux incorporato con un server web leggero. Lo stesso può essere ottenuto nel server web Apache inserendo un file .htaccess e negando l'accesso come indicato in Stack Overflow.

Per gli elementi dell'interfaccia utente, dovrai creare pagine diverse (o nascondere gli elementi tramite il controllo di gruppo). Dovrai identificare l'utente (effettuando l'accesso e determinando il gruppo corrispondente) e quindi visualizzare le pagine web in base ai privilegi dell'utente.

Jester
2017-10-11 02:25:04 UTC
view on stackexchange narkive permalink

Solo un rapido suggerimento sull'implementazione, dato che avevi qualche dubbio su centinaia di pagine. Ad esempio, in ASP.NET MVC, è possibile creare un filtro globale o una pagina "base" da cui tutti gli altri potrebbero ereditare.

Quindi il codice, che è posizionato centralmente, potrebbe controllare il contesto / sessione dell'utente e confrontalo con un elenco di diritti / permessi / o appartenenza a un gruppo per la pagina corrente (forse una struttura di dati su ciascuna pagina o una ricerca nel database basata sul nome della pagina, ecc.).

Readin
2017-10-14 07:44:13 UTC
view on stackexchange narkive permalink

Altre risposte sono state molto generali, quindi aggiungerò questa perché sono state menzionate le pagine JSP, quindi penso di poter presumere che tu stia lavorando in Java.

Come tale , molto probabilmente puoi utilizzare i filtri per eseguire il codice ogni volta che viene effettuata una richiesta all'applicazione. Se utilizzi un framework di sicurezza come Spring, puoi configurare gli URL a cui è possibile accedere e da chi.



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...