Quali sono alcuni potenziali attacchi che potrebbero essere fatti su un sito web che non gestisce correttamente la codifica url?

Question

Quali sono alcuni potenziali attacchi che potrebbero essere fatti su un sito web che non gestisce correttamente la codifica url?

#1 da (3 voti)
#2 da (2 voti)
#3 da (0 voti)

2

Circa un mese fa ero nel mezzo di una delle mie classi "Applicazioni distribuite" e il professore ci stava spiegando come "" "correttamente" "" autenticare gli utenti in un server.

Per dimostrare come impedire agli utenti di accedere a tutti i file in una determinata directory (cioè con nome "privato"), il professore ci ha mostrato un codice JSP simile al seguente pseudocodice:

String URI = uri.getRequest();
if (URI.contains("/private/") {
  if (userIsAuthenticated()) grantAccess();
  else redirectToLogInPage();
 }

Naturalmente, ho capito cosa c'era che non andava e cosa poteva essere un difetto di sicurezza. Se un utente richiede un URL come mysite.com/private%2Fmypage , l'URI non conterrà la stringa letterale "/ private /" in modo che l'utente possa accedere.

Ieri mi sono ricordato di quella lezione, quindi, per quanto ne fossi curioso, ho scoperto che non solo tutti i miei precedenti progetti web in Uni hanno avuto questa vulnerabilità, ma anche alcuni siti Web di aziende serie hanno questo problema. Puoi accedere a molte pagine in cui non dovresti essere in grado (sostanzialmente pagine del profilo utente quando non hai effettuato l'accesso), solo tramite la codifica percentuale di qualche carattere nell'URL.

Quindi, poiché ho capito che ci sono molte persone che non si preoccupano troppo di questo problema, sono un po 'confuso. Non è un grosso difetto? Quali potrebbero essere alcuni attacchi che potrebbero essere sfruttati sfruttando questo problema? Vorrei solo sapere, da un punto di vista teorico, se possibile, quanto male potrebbe ottenere questo problema per un sito che non gestisce correttamente la codifica url.

P.S: So che una soluzione plausibile potrebbe essere anche controllare se l'URL richiesto è codificato in percentuale e negare l'accesso ad esso. O anche se ci piacerebbe andare oltre e implementare una soluzione più sicura, potremmo utilizzare un Key Distributed Center come Kerberos. Tuttavia, non capisco perché tu possa trovare siti Web seri con questo difetto e non sembra un grosso problema per loro.

http url encoding web-application

posta Miquel Perez 17.01.2018 - 21:15

fonte

3 risposte

Leggi altre domande sui tag http url encoding web-application

Esistono ragioni tecniche per le quali gli attori statali potrebbero essere maggiormente in grado di effettuare attacchi informatici contro le infrastrutture critiche, rispetto alle persone fisiche? Come può un certificato SSL scaduto rendere il server e / o il client vulnerabili agli attacchi MITM? [duplicare]

score 3 · Answer 1

Quello che vuoi ottenere è applicare una certa sicurezza a / private / e altrimenti servire liberamente i contenuti. La pagina di accesso deve essere privata.

I server che gestiscono la sicurezza basata sul percorso sanno come gestire gli escape. Quello che cercano è portare sia il percorso che il modello in una forma "canonica". In questo modo, si assicurano che confrontino la barra con la barra e non con la sua URL escape.

Di solito la sicurezza dichiarativa batte la sicurezza programmata. Ciò implica che il percorso di test avvenga in un unico luogo, al di fuori dell'applicazione, in una libreria di terze parti scritta pensando alla sicurezza. Le probabilità sono che quelli che hanno scritto la libreria fossero consapevoli del fatto che un URL potrebbe contenere degli escape. Un altro vantaggio della sicurezza dichiarativa è che non ingombra il codice così tanto. Non avremo cose come:

delete_entry() {
if (rights.check("delete"))
   actually_delete();
 else {
   log_failed_attempt();
   throw new SecurityException("Not allowed to delete, the attempt has been logged.");
 }
}

Un programmatore distratto può dimenticare il controllo per una singola azione. Piuttosto, avere un sistema di annotazione di "azioni" che verrà controllato da un chiamante. Se manca il gestore di sicurezza, fallisci la chiamata in fase di esecuzione, questo significa che il programmatore ha dimenticato di "proteggere" la routine. "Le funzioni gratuite per tutti" devono avere un'annotazione @freeForAll.

Nel tuo caso, il server deve imporre che / private / sia servito solo se i visitatori hanno un token specifico, che non possono fabbricare da soli. Ad esempio, sarebbe errato verificare un cookie con il contenuto "authenticated: true", poiché i client potrebbero generare tale cookie senza visitare il login.

score 2 · Answer 2

Come affermato da @Razvan_P, il componente di sicurezza, se basato sulla posizione, dovrebbe essere qualcosa che sappia gestire le posizioni: -).

Ma è effettivamente un problema molto attuale (qualcosa come il trucco riflesso per i giocatori di CTF). Il "dominio" di sicurezza qui è principalmente aggirando i filtri di sicurezza . Tutti i filtri basati sulla posizione sono interessati. E su questo ci sono problemi su molti server HTTP (reverse proxy, load balancer), non solo applicazioni. Perché per la maggior parte di questi agenti la sicurezza non è il compito principale.

Ad esempio:

di solito ignorano che l'uso delle regole di riscrittura con mod_rewrite in apache non è lo stesso per le locazioni e gli argomenti delle stringhe di query (la successiva non è decomposta nell'URL prima dell'esecuzione nelle regole di riscrittura). E puoi trovare cattive (troppo semplici) regole di sicurezza sulle documentazioni online .
la codifica url viene applicata solo su alcuni caratteri dai browser, ma puoi anche codificare qualsiasi carattere normale, ad esempio %61 per a .
alcuni caratteri sono sempre codificati in url dai browser, ma non tutte le query provengono dai browser, possono accadere cose strane quando si usano caratteri bassi ascii ascii, come il byte NULL o il TAB (o backspace, FormFeed, ...)

In termini di architettura di sicurezza, dovrebbe essere applicata la difesa in profondità e un'applicazione non dovrebbe fare affidamento su un filtro precedente realizzato solo da un server HTTP (ad esempio, l'applicazione PHP dovrebbe applicare le regole ACL, anche se hai usato una regola mod_rewrite nell'apache httpd).

E per tornare alla tua prima domanda, sul dominio di sicurezza. Alcune domande relative agli errori di sintassi uri e posizione portano ad altri domini, non solo a bypass dei filtri di sicurezza, come crlf injection, HTTP Smuggling o inquinamento dei parametri HTTP.

score 0 · Answer 3

Come risolvi questo problema? Come scrive Razvan P , devi confronta sia l'URL che il frammento ( /private/ ) nella stessa forma canonica. In pratica, ciò significa che devi URL per decodificare l'URL prima di confrontarlo, in modo che %2F venga convertito in / .

Quanto è grave? Può essere davvero pessimo. In pratica significa che l'informazione che dovrebbe essere privata è pubblica. Può anche significare che persone non autorizzate possono modificare o cancellare informazioni. Quanto è grave questo dipende da cosa stai proteggendo, e varia da un po 'imbarazzante a pieno di catastrofi.

Perché questa vulnerabilità è così comune, anche su siti di grandi dimensioni? Bene, perché vediamo ancora persone vittime di SQLi o XSS, anche se è noto da decenni come gestirlo propriamente? Suppongo che la sicurezza sia complessa, che gli umani siano falsi, e il resto è storia.

Che cosa fai adesso? Prima di tutto, potresti voler riconsiderare se sbirciare su altri siti web sia una buona idea. A seconda della giurisdizione, provare a bypassare filtri di sicurezza del genere può essere illegale. In secondo luogo, dovresti considerare la divulgazione responsabile per i siti in cui hai trovato la vulnerabilità. Basta non farlo in modo da incriminarti.