Qual è il punto e virgola riservato agli URL?

Question

Il RFC 3986 URI: Generic Syntax spec elenca un punto e virgola come (sub-delim) carattere riservato:

reserved = gen-delims/sub-delims 

gen-delims = ":"/"/"/"?"/"#"/"["/"]"/"@" 

sub-delims = "!"/"$"/"&"/"'"/"("/")" 
      /"*"/"+"/","/";"/"=" 

Qual è lo scopo riservata del ";" del punto e virgola negli URI? Del resto, qual è lo scopo delle altre sub-delimitazioni (sono a conoscenza solo degli scopi per "&", "+" e "=")?

Answer 1

C'è una spiegazione alla fine della sezione 3.3.

parte dot-segmenti in percorsi gerarchici, un segmento di percorso è considerata opaca dal generico sintassi. Le applicazioni di produzione di URI utilizzano spesso i caratteri riservati consentiti in un segmento per delimitare lo specifico dello schema o sottocomponenti specifici per lo strumento di deduprera-assegnazione . Ad esempio, il punto e virgola dei caratteri riservati è spesso utilizzato da punto e virgola ("=") per delimitare i parametri ei valori di parametro applicabili a tale segmento. Il carattere riservato (",") della virgola è spesso utilizzato per scopi simili. Ad esempio, un produttore URI utilizza un segmento come "nome; v = 1.1" per indicare un riferimento alla versione 1.1 di "nome", mentre un altro potrebbe utilizzare un segmento come "nome, 1.1" a indicano lo stesso. I tipi di parametri possono essere definiti dalla semantica specifica dello schema , ma nella maggior parte dei casi la sintassi di un parametro è specifica per l'implementazione dell'algoritmo di dereferenziazione U2 .

In altre parole, si è riservato in modo che le persone che vogliono un elenco delimitato di qualcosa nella URL possono tranquillamente utilizzare ; come delimitatore, anche se le parti contengono ;, fino a quando i contenuti sono cento codificati. In altre parole, si può fare questo:

foo;bar;baz%3bqux 

e interpretarlo come tre parti: foo, bar, baz;qux. Se il punto e virgola non fosse un carattere riservato, ; e %3b sarebbero equivalenti, pertanto l'URI sarebbe interpretato erroneamente come quattro parti: foo, bar, baz, qux.

Answer 2

Section 3.3 covers this - è un delimitatore opaca un'applicazione URI produttrice può usare se conveniente:

A parte dot-segmenti in percorsi gerarchici, un segmento di percorso è considerato opaco dal generico sintassi. Le applicazioni di produzione di URI utilizzano spesso i caratteri riservati consentiti in un segmento per delimitare lo specifico dello schema o sottocomponenti specifici per lo strumento di deduprera-assegnazione . Ad esempio, i caratteri riservati del punto e virgola con punto e virgola (";") vengono spesso utilizzati per i parametri delimitatore e per i valori di parametro applicabili a tale segmento. Il carattere riservato virgola (",") è spesso utilizzato per scopi simili. Per esempio , un produttore di URI potrebbe utilizzare un segmento come "nome; v = 1.1" a indicare un riferimento alla versione 1.1 di "nome", mentre un altro potrebbe utilizzare un segmento come "nome, 1.1" a indicare lo stesso. I tipi di parametri possono essere definiti da semantica specifica dello schema, ma nella maggior parte dei casi la sintassi di un parametro è specifica all'implementazione dell'iter di dereferenziazione dell'URI .

Answer 3

L'intento è chiaro se si torna al older versions del disciplinare:

path_segments = segment *("/" segment) 
    segment  = *pchar *(";" param) 

Ogni segmento di percorso può comprendere una sequenza di parametri, indicato dal punto e virgola ";" carattere.

Credo che abbia le sue origini in FTP URI s.

Answer 4

Ci sono alcune convenzioni intorno al suo uso corrente che sono interessanti. Questi parlano quando usare un punto e virgola o una virgola. Dal libro "RESTful Web Services":

Utilizzare caratteri di punteggiatura per separare più porzioni di dati allo stesso livello di gerarchia. Utilizza le virgole quando l'ordine degli oggetti è importante, ... Usa il punto e virgola quando l'ordine non ha importanza.

Answer 5

Dal 2014 è noto che i segmenti di percorso contribuiscono a Reflected File Download attacks. Supponiamo che abbiamo un API vulnerabili che riflette tutto ciò che inviamo ad esso (l'URL è stato vero a quanto pare, ora risolto):

https://google.com/s?q=rfd%22||calc|| 

{"results":["q", "rfd\"||calc||","I love rfd"]} 

Ora, questo è innocuo in un browser come è JSON in modo che non sta per essere reso ma il browser offrirà piuttosto di scaricare la risposta come un file. Ora ecco i segmenti di percorso venire ad aiutare (per l'attaccante):

https://google.com/s;/setup.bat;?q=rfd%22||calc|| 

Tutto tra un punto e virgola (;/setup.bat;) sarà non inviato al servizio web, ma invece il browser interpreterà come il nome del file. .. per salvare la risposta dell'API. Ora, un file chiamato setup.bat verrà scaricato ed eseguito senza chiedere informazioni sui pericoli di eseguire i file scaricati da Internet (poiché contiene la parola "setup" nel suo nome). I contenuti saranno interpretati come file batch di Windows e verrà eseguito il comando calc.exe.

Prevenzione:

• disinfettare ingresso del API (in questo caso si dovrebbe solo consentire caratteri alfanumerici); la fuga non è sufficiente
• aggiungi Content-Disposition: attachment; filename="whatever.txt" su API che non verranno renderizzate; Google mancava la parte filename che in realtà ha reso l'attacco più facile
• aggiungere X-Content-Type-Options: nosniff intestazione alle risposte API

Answer 6

ho trovato i seguenti casi d'uso:

suo il carattere finale di un'entità HTML:
https://en.wikipedia.org/wiki/List_of_XML_and_HTML_character_entity_references

Per utilizzare uno di questi riferimenti ad entità carattere in un HTML o XML documento, inserire una e commerciale seguita b y il nome dell'entità e un punto e virgola , ad esempio & per la e commerciale ("&").

Apache Tomcat 7 (o versioni più recenti ?!) ci come path parameter:
https://superevr.com/blog/2011/three-semicolon-vulnerabilities

Apache Tomcat è un esempio di un server web che supporta "Path Parametri". Un parametro path è un contenuto extra dopo il nome di un file, , separato da un punto e virgola. Qualsiasi contenuto arbitrario dopo un punto e virgola fa non influenza la pagina di destinazione di un browser web. Ciò significa che http://example.com/index.jsp;derp restituirà ancora index.jsp e non una pagina di errore.

URI Schema divide da esso MIME e dati:
https://en.wikipedia.org/wiki/Data_URI_scheme

può contenere un parametro di caratteri facoltativo, separata dalla parte precedente da una virgola (;).

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUA 
AAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO 
9TXL0Y4OHwAAAABJRU5ErkJggg==" alt="Red dot" /> 

E c'era un bug in IIS 5 e IIS6 per bypassare i file restrizioni di upload:
https://www.owasp.org/index.php/Unrestricted_File_Upload

estensioni di file blacklist Questa protezione può essere bypassata da: ... con l'aggiunta di un carattere punto e virgola dopo l'estensione proibita e prima di quello consentito (ad esempio "file.asp; .jpg")

Conclusione:
Non utilizzare il punto e virgola negli URL o potrebbero generare accidentalmente un'entità HTML o uno schema URI.