web-dev-qa-db-ja.com

URLで予約されているセミコロンは何ですか？

RFC 3986 URI：汎用構文 仕様では、セミコロンが予約済み（サブデリム）文字としてリストされています。

reserved    = gen-delims / sub-delims

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

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

「;」の予約目的は何ですかURIのセミコロンの？さらに言えば、他のサブデリムの目的は何ですか（「＆」、「+」、「=」の目的しか認識していません）。

urluricharacterrfc3986
33
Nicole

セクション3.3の終わりに説明があります。

階層パスのドットセグメントを除いて、パスセグメントは一般的な構文では不透明であると見なされます。 URI生成アプリケーションは、多くの場合、セグメントで許可されている予約文字を使用して、スキーム固有または間接参照ハンドラ固有のサブコンポーネントを区切ります。たとえば、セミコロン（ ";"）と等号（ "="）の予約文字は、そのセグメントに適用可能なパラメーターとパラメーター値を区切るためによく使用されます。カンマ（ "、"）の予約文字は、同様の目的でよく使用されます。たとえば、あるURIプロデューサーは「name; v = 1.1」などのセグメントを使用して「name」のバージョン1.1への参照を示し、別のURIプロデューサーは「name、1.1」などのセグメントを使用して同じことを示す場合があります。パラメータタイプは、スキーム固有のセマンティクスによって定義できますが、ほとんどの場合、パラメータの構文は、URIの逆参照アルゴリズムの実装に固有です。

つまり、URLに何かの区切りリストが必要な場合は、部分に;が含まれていても、内容がパーセントである限り、;を区切り文字として安全に使用できるように予約されています。エンコードされます。言い換えれば、あなたはこれを行うことができます：

foo;bar;baz%3bqux

foo、bar、baz;quxの3つの部分として解釈します。セミコロンが予約文字でない場合、;と%3bは同等であるため、URIは4つの部分として誤って解釈されます：foo、bar、baz、qux。

35
Mark Byers

仕様の 古いバージョン に戻ると、意図がより明確になります。

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

各パスセグメントには、セミコロン「;」で示される一連のパラメータを含めることができます。キャラクター。

FTP URI sに起源があると思います。

7
McDowell

セクション3.3でこれについて説明します -これは、URI生成アプリケーションが便利な場合に使用できる不透明な区切り文字です。

階層パスのドットセグメントを除いて、パスセグメントは一般的な構文では不透明であると見なされます。 URI生成アプリケーションは、多くの場合、セグメントで許可されている予約文字を使用して、スキーム固有または間接参照ハンドラ固有のサブコンポーネントを区切ります。たとえば、セミコロン（ ";"）と等号（ "="）の予約文字は、そのセグメントに適用可能なパラメーターとパラメーター値を区切るためによく使用されます。カンマ（ "、"）の予約文字は、同様の目的でよく使用されます。たとえば、あるURIプロデューサーが「name; v = 1.1」などのセグメントを使用して「name」のバージョン1.1への参照を示し、別のURIプロデューサーが「name、1.1」などのセグメントを使用して同じことを示す場合があります。パラメータタイプは、スキーム固有のセマンティクスによって定義できますが、ほとんどの場合、パラメータの構文は、URIの逆参照アルゴリズムの実装に固有です。

5
Paul Dixon

現在の使用法には、興味深いいくつかの規則があります。これらは、セミコロンまたはコンマをいつ使用するかを示します。 「RESTfulWebサービス」という本から：

句読文字を使用して、同じ階層レベルで複数のデータを区切ります。アイテムの順序が重要な場合はコンマを使用します。..順序が重要でない場合はセミコロンを使用します。

4
Frank Schwieterman

2014年以降、パスセグメントは 反射ファイルダウンロード攻撃 に寄与することが知られています。送信したものをすべて反映する脆弱なAPIがあると仮定しましょう（URLは明らかに修正され、現在は修正されています）。

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

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

これはJSONであるため、ブラウザーでは無害であるため、レンダリングされませんが、ブラウザーは応答をファイルとしてダウンロードすることを提案します。これが（攻撃者にとって）役立つパスセグメントです。

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

セミコロン（;/setup.bat;）の間のすべてはではなくWebサービスに送信されますが、代わりにブラウザーはそれをファイル名として解釈します。 。API応答を保存します。これで、setup.batというファイルがダウンロードされ、インターネットからダウンロードしたファイルを実行する危険性について質問することなく実行されます（名前に"setup"という単語が含まれているため）。内容はWindowsバッチファイルとして解釈され、calc.exeコマンドが実行されます。

防止：

  • aPIの入力をサニタイズします（この場合、英数字のみを許可する必要があります）。脱出は十分ではありません
  • レンダリングされないAPIにContent-Disposition: attachment; filename="whatever.txt"を追加します。グーグルは実際に攻撃を容易にするfilename部分を欠いていました
  • aPI応答にX-Content-Type-Options: nosniffヘッダーを追加します
2
kravietz

次のユースケースを見つけました。

HTMLエンティティの最後の文字：
https://en.wikipedia.org/wiki/List_of_XML_and_HTML_character_entity_references

HTMLまたはXMLドキュメントでこれらの文字エンティティ参照の1つを使用するには、アンパサンドの後にエンティティ名とセミコロンを入力します（例：アンパサンド（ "＆"）の場合は＆）。

Apache Tomcat 7（または新しいバージョン？！）はpath parameterとして使用します：
https://superevr.com/blog/2011/three-semicolon-vulnerabilities

Apache Tomcatは、「パスパラメータ」をサポートするWebサーバーの一例です。パスパラメータは、セミコロンで区切られた、ファイル名の後の追加コンテンツです。セミコロンの後の任意のコンテンツは、Webブラウザのランディングページに影響を与えません。これは、 http://example.com/index.jsp;derp が引き続きindex.jspを返し、エラーページを返さないことを意味します。

URIスキームは、それによってMIMEとデータを分割します。
https://en.wikipedia.org/wiki/Data_URI_scheme

オプションの文字セットパラメータを含めることができ、セミコロン（;）で前の部分と区切ることができます。

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

また、IIS5とIIS6には、ファイルのアップロード制限を回避するバグがありました。
https://www.owasp.org/index.php/Unrestricted_File_Upload

ファイル拡張子のブラックリスト化この保護は、次の方法で回避される可能性があります。..禁止されている拡張子の後、許可されている拡張子の前にセミコロン文字を追加する（例： "file.asp; .jpg"）

結論：
URLでセミコロンを使用しないでください。セミコロンを使用すると、誤ってHTMLエンティティまたはURIスキームが生成される可能性があります。

0
mgutt