Qual è il punto e virgola riservato ai negli URL?

Question

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

reserved    = gen-delims / sub-delims

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

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

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

Answer 1

C'è una spiegazione alla fine della sezione 3.3.

  

A parte dot-segmenti in   percorsi gerarchici, un segmento di percorso è   considerata opaca dal generico   sintassi. URI applicazioni che producono   spesso utilizzano i caratteri riservati   consentito in un segmento per delimitare   schema-specifico o   dereference-handler specifici   sottocomponenti. Ad esempio, la   punto e virgola ( ";") e di uguale ( "=")   caratteri riservati sono spesso usati   ai parametri di delimitare e parametro   valori applicabili a quel segmento.   La virgola ( "") carattere riservato è   spesso utilizzato per scopi simili.   Ad esempio, un produttore potrebbe URI   utilizzare 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   indicare lo stesso. tipi di parametri   possono essere definite con regime specifico   semantica, ma nella maggior parte dei casi il   sintassi di un parametro è specifico per   l'attuazione del URI   dereferencing algoritmo.

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 virgola non fosse un carattere riservato, il ; e %3bwould essere equivalente in modo che l'URI sarebbe interpretata in modo errato come quattro parti: foo, bar, baz, qux

.

Answer 2

L'intento è più chiara se si va di nuovo a versioni precedenti del disciplinare:

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

  

Ogni segmento di percorso può includere un      sequenza di parametri, indicati dal virgola ";" carattere.

Credo che abbia le sue origini nel FTP URI s.

Answer 3

sezione 3.3 copre questo - è un delimitatore opaca un URI produttrici di applicazione può utilizzare se conveniente:

  

A parte dot-segmenti in   percorsi gerarchici, un segmento di percorso è   considerata opaca dal generico   sintassi. URI applicazioni che producono   spesso utilizzano i caratteri riservati   consentito in un segmento per delimitare   schema-specifico o   dereference-handler specifici   sottocomponenti. Ad esempio, la   punto e virgola ( ";") e di uguale ( "=")   caratteri riservati sono spesso utilizzati per   parametri delimitare e parametro   valori applicabili a quel segmento. Il   virgola ( "") carattere riservato è   spesso utilizzato per scopi simili. Per   ad esempio, un produttore potrebbe utilizzare un URI   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" per indicare   lo stesso. Tipi di parametri possono essere   definita dalla semantica schema-specifici,   ma nella maggior parte dei casi la sintassi di un   parametro è specifico per il   attuazione del URI   dereferencing algoritmo.

Answer 4

Ci sono alcune convenzioni in tutto il suo uso corrente che sono interessanti. Questi parlano quando utilizzare un punto e virgola o virgola. Dal libro "RESTful Web Services":

  

Utilizzare caratteri di punteggiatura per separare più pezzi di dati allo stesso livello della gerarchia. Utilizzare le virgole quando l'ordine degli elementi questioni, ... Utilizzare il punto e virgola quando l'ordine non importa.

Answer 5

Da 2014 segmenti di tracciato sono noti per contribuire a Reflected attacchi file scaricare . 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 di JSON in modo che non sta per essere reso, ma il browser piuttosto offrirà per scaricare la risposta come un file. Ora ecco il percorso segmenti vengono a aiuto (per l'attaccante):

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

Tutto ciò 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 API. Ora, un file chiamato setup.bat verrà scaricato ed eseguito senza chiedere circa i pericoli di gestione dei file scaricati da Internet (perché 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
• add Content-Disposition: attachment; filename="whatever.txt" sulle API che non stanno andando essere resi; Google mancava la parte filename che in realtà ha reso più facile l'attacco
• add X-Content-Type-Options: nosniff intestazione alle risposte API

Answer 6

ho trovato i seguenti casi d'uso:

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

  

Per usare uno di questi riferimenti ad entità carattere in una HTML o XML   documento, inserire una e commerciale seguita dal nome dell'entità e un   virgola, per esempio, e per la 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". Parametro Un percorso è contenuto in più dopo un nome di file,   separati da una virgola. Qualsiasi contenuto arbitrario, dopo un punto e virgola fa   non pregiudica la pagina di destinazione di un browser web. Ciò significa che    http://example.com/index.jsp;derp sarà ancora tornare index.jsp, e non   qualche pagina di errore.

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

  

Si può contenere un set di parametri carattere facoltativo, separato dalla   precedente parte 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 a restrizioni upload di file di bypass:
https://www.owasp.org/index.php/Unrestricted_File_Upload

  

estensioni di file Blacklisting Questa protezione potrebbe essere bypassati da: ...   aggiungendo un carattere virgola dopo l'estensione proibito e   prima che il permesso uno (per esempio "file.asp; .jpg")

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