Percorsi relativi nelle applicazioni web

Gli URL relativi possono essere vulnerabili a Sovrascrittura percorso relativo .

L'idea principale è che il client e il server analizzeranno l'URL in modo diverso, in modo che possano definire la directory corrente in modo diverso.

Ad esempio, immagina di avere una pagina situata a /forum/index.php . Costruiamo un URL semplice che verrà analizzato in modo diverso dal client e dal server: /forum/index.php/ .

• Il server vedrà /forum/index.php e / verrà analizzato come percorso informazioni da un server web Apache. Definirà la directory corrente come /forum/
• Il client non ha modo di sapere che index.php non è una directory, quindi definirà la directory corrente come /forum/index.php/

Ciò ti consente di reindirizzare la posizione prevista di un link o una fonte di un foglio di stile / script, consentendoti di inoltrare l'escalation ad attacchi più avanzati come XSS.

Se qualcuno ti dice che qualcosa non va, allora devono essere in grado di dirti perché è sbagliato. E l'utilizzo di collegamenti relativi non ha alcun impatto sulla SEO con nessuno dei principali motori di ricerca (almeno negli ultimi 10 anni).

Se qualcuno inferisce dalla presenza di URL relativi in HTML che il servizio è vulnerabile agli attacchi di attraversamento di percorsi, allora hanno un lavoro sbagliato.

• nel corso normale degli eventi, questi vengono convertiti in percorsi canonici nel client
• è considerata una buona pratica dal punto di vista dello sviluppo utilizzare i percorsi relativi in modo tale che un'applicazione possa essere distribuita in un vhost multi-tenant e per la gestione del codice

Non sto dicendo che l'applicazione non sia vulnerabile - ma non c'è nulla nella domanda per supportare questa asserzione.

Pur dimostrando in un test in doppio cieco che un'applicazione non è vulnerabile agli attacchi path traversal, dovrebbe essere banale per un amministratore di sistemi competente deliberare deliberatamente uno scenario (file con permessi appropriati in un percorso noto al di fuori del percorso dell'applicazione) da testare.

Credo che potrebbe avere a che fare con l'attacco di attraversamento del percorso. Il che significa che qualcuno potrebbe sostituire il percorso relativo a quel file con il percorso relativo a un altro che potrebbe essere:

• un altro file da quel server che contiene informazioni sensibili in modo che in questo modo possano avere accesso ai contenuti di quel file e potrebbero leggerlo
• un altro file da un server remoto e se il server che archivia l'applicazione tenta di caricare un file dal relativo percorso specificato, caricherà invece questo file dal server remoto, che potrebbe contenere malware o un'altra forma di attacco

Potrebbero anche usare questa vulnerabilità esattamente per il path traversal, il che significa che cambierebbero quel percorso verso le cartelle madri e così via nella gerarchia superiore delle cartelle e caricheranno ogni possibile file che hanno trovato lì. In questo modo, otterranno informazioni su assolutamente ogni file che memorizzi su quel disco.