分析と広告のためのCookie
分析と広告のためにCookieを使っており、どちらもGoogleに送られます。拒否しても、目に見える動作は何も変わりません。プライバシーポリシーを読む
アドレスを貼り付けて、ブラウザーが見ているとおりに眺めてください。スキーム、ホスト、ポート、パス、クエリ、フラグメント、そしてクエリの各パラメーターを 1 行ずつ。分解にはブラウザーに組み込まれたパーサーを使います。クリックが実際にどこへ向かうかを決めているのと同じもので、境界の場面でこそ別の判断をする正規表現ではありません。
処理される場所
ファイルがないので、何もアップロードされません。計算はこのページの中で行われます。
順番待ちもアカウントもなし
お使いの機械の速さで答え、あなたが誰かを尋ねることはありません。
何度でも
回数は数えず、上限もありません。もう一度答えることに費用はかからないからです。
分解は組み込みの `URL` インターフェースから来ていて、手書きの正規表現からではありません。この種の道具が分かれる地点がそこです。WHATWG の仕様は、自作しているときには思いつかない規則で埋まっていて、面白い誤りはその規則の中に住んでいます。
一例がホストの正規化です。大文字小文字が揃えられ、末尾のピリオドが落ち、国際化ドメイン名は Punycode に変換されます。正規表現はすべてそのまま残すので、どのブラウザーにとっても同じである 2 つのアドレスのあいだに差を指摘します。
`https://[email protected]/` のホストは `example.com` ではなく `evil.example` です。アットマークより前はすべて資格情報です。規格に適合していて、最も古いフィッシングの手口のひとつの土台です。目は最初に見えた既知の名前で止まるからです。
だからホストにはここで専用の行があります。怪しいアドレスを調べる人は数える必要がなく、本当の行き先を読めばよい。同じ包みで来るものとして、`example.com.evil.example` という名前も `evil.example` にあるアドレスです。効いているのは最後のラベルの組だからです。
アドレスは分解されるだけで、開かれません。ホストへのリクエストもプレビューもリダイレクトの追跡もありません。これは欠けている機能ではなく判断です。怪しい URL を調べている人は、道具にそれを訪問してほしくない筆頭です。
訪問すれば何かを漏らしもします。リクエストはサーバーから出て、その IP と時刻は相手側のログに残り、1 回きりのアドレス——確認リンク、パスワード再設定——なら道中で使い切ってしまいます。分解は無害な操作で、ここで起きるのはそれだけです。
パスの中の `..` は解析の時点で解決されます。`/docs/a/../b` は `/docs/b` になります。正規化の一部であって、このツールが足しているものではありません。どのブラウザーもリクエストを出す前に同じことをし、サーバーが元の形を見ることはありません。
パスを比較したり、パスに対して権限を判断したりするすべてに効いてきます。アクセス規則を正規化後のパスではなく生の文字列に対して確かめる人は、実際に要求されるものとは別のものを確かめています。何十年も前からパストラバーサルと呼ばれてきた穴です。
`#` より後ろのものはすべてブラウザーに留まります。どのリクエストにも現れず、どのサーバーにも届かず、どのアクセスログにも載りません。プライバシー機能ではなく HTTP の性質で、両方向に切れます。
便利なのは、そこに置いた値がサーバーへ届かないからです。歴史的に OAuth のトークンがフラグメントを旅した理由でもあります。厄介なのは、それでも履歴に残り、一部のスクリプトのリファラー連鎖に残り、共有されたリンクに残るからです。「サーバーへ届かない」は「非公開である」ではありません。
ポートがそのスキームの既定——https なら 443、http なら 80——であるとき、パーサーはそれを省きます。冗長だからです。`https://example.com:443/` と `https://example.com/` は同じアドレスで、正規化がそれを見えるようにします。
2 つの URL 文字列の比較が、両方とも同じ意味なのに失敗する、よくある説明です。アドレスを比較する人は先にパーサーを通し、正規化された形を比べるべきです。ここの各行に出ているのがまさにその形です。
`htp://example.com` のような打ち間違いは拒否されません。スキームが `htp` のアドレスとして読まれます。パーサーの欠陥ではありません。仕様はあらゆるスキームを認めます。`mailto:`、`tel:`、`git+ssh:`、`spotify:` と何百もあり、あなたの世界で何が妥当かを知りうるものはありません。
実務上は、ここに予期しないスキームが出たら、打ち間違いを見つけたということです。そしてもうひとつ、「解析できるか」という検査はアドレスがウェブを指していることの検査ではありません。それには、スキームを明示的な一覧と突き合わせる必要があります。
`https://ユーザー:パスワード@host/` という形はいまも存在し、古いスクリプト、データベースの接続文字列、資料の例に現れます。フィッシングに最適だったのでブラウザーは使用を制限しましたが、ライブラリとコマンドラインの道具はいまも受け付けます。
ここではユーザー名を表示し、パスワードは表示しません。代わりに、存在するという表示が出ます。理由は平凡でそれでも成り立ちます。この結果はしばしばスクリーンショットやチケットに行き着き、すでに手元にあるパスワードをもう一度印字する必要はありません。
日本語のホスト名は Punycode に変換されます。`日本.example` は `xn--wgv71a.example` になります。これが DNS に実在する形です。名前解決の仕組みは ASCII しか知らず、読める表記はブラウザーが見せている補助です。
実際に問い合わせられるものを見せることには、セキュリティ上の効用があります。ホモグラフ攻撃はラテン文字に似た他の文字体系の字を使います。Punycode の形では一目で分かります。見慣れた名前の代わりに、意味のない字の並びが現れるからです。
いいえ。分解するだけで開きません。ホストへのリクエストも、プレビューも、リダイレクトの追跡もありません。怪しい URL や 1 回きりの URL では、それこそが肝心です。
アドレスにアットマークがある可能性が高いです。https://[email protected]/ ではその前はすべて資格情報で、ホストは evil.example です。規格に適合していて、非常に古いフィッシングの手口の土台です。
https の既定なので正規化が省くからです。https://example.com:443/ と https://example.com/ は同じアドレスです。2 つの URL のテキスト比較が失敗する、よくある理由でもあります。
仕様があらゆるスキームを認めるからです。mailto、tel、git+ssh をはじめ何百もあります。htp は構文としては妥当なスキームです。そこに出たことが、打ち間違いの手がかりです。
いいえ。ユーザー名は出ますが、パスワードは存在するという表示だけです。この結果はしばしばスクリーンショットやチケットに行き着き、そこに出る理由がありません。