base64でエンコードされたURLを使用する目的
機密データのPOSTからURIまで、またはリソースの表示など、あらゆる目的でbase64でエンコードされたURLを使用するWebサイト freshbooks.com を見つけました。
たとえば、Webサイトで請求書を表示するためのURLは次のとおりです（わかりやすくするためにURLの一部を省略しています）。
something.fresbooks.com/dmlld0ludm9pY2VGQjU1Mzc2
文字列dmlld0ludm9pY2VGQjU1Mzc2がデコードされると、viewInvoiceFB55376
セキュリティの観点から、URLをこのような形式で使用したり、プログラミングの便宜を図ったりする理由はありますか？私が考えることができる唯一の理由は、いくつかの自動化ツールがWebサイトのデザインに関する情報を抽出するのを防ぐためです。もしそうなら、このアプローチはあいまいさによるセキュリティとして特徴付けられていませんか？
この方法でURLを提示しても、セキュリティ上のメリットはまったくありません。これは、ウェブサイトを「本番対応」にするためのばかげた方法です（それが何であれ）。実際、プログラミングの利便性すらありません。それは正反対です。特にログファイル内のURLで特定の文字列を検索する必要がある場合は、デバッグがはるかに困難になります。
そのサイトの開発者は、暗号化されたURLなどを使用して、Webサイトの表示をより安全にすることを選択した可能性があります。ただし、これが セキュリティによるあいまいさ であるとは限りません。
彼らのウェブサイトが SQLインジェクション に対して脆弱であり、URLをエンコードすることでそれを隠そうとする場合、そしてあいまいさによるセキュリティです。彼らのウェブサイトがSQLインジェクションから十分に保護されている場合; [〜＃〜] xss [〜＃〜] ; [〜＃〜] csrf [〜＃〜] ;など、彼らはそのようなURLをエンコードすることを防いだので、それは単なる愚かさです。
注：URLをエンコードすると、特定の情報がショルダーサーファーから隠されたり、クロールやその他の数を減らすのに役立つ可能性があると人々が主張することを聞いたことがありますその種の引数の。上で述べた理由から、私はまだこのテクニックをばかげています。
Base64は、データにURLに対応していない文字が含まれている場合にURLでデータを渡すのに役立ちますが、それでもオプションはあります。
あなたがデコードしたものの構造は、実際にはエンコードされた文字列がパラメーター付きのコマンドであることを示唆しているようです。
私の推測では、これはセキュリティを強化するための見当違いの試みだと思います。
HTTP URLは、セキュリティ上の理由ではなく、アプリケーション上の理由により、そのWebサーバーに固有のBase64エンコードされている場合があります。
ASP.NET MVCの経験を生かして、状況に当てはまるかどうかはわかりません。
ブラウザやMVCフレームワークによって誤って解釈される可能性のあるデータをエンコードすることは、ユーザーフレンドリーではありませんが、完全に合理的です。 Base64は、UrlEncodingが機能しない場合に機能します。たとえば、私は/文字ペイロードとして別のサーバーに送信したいwww.server.com/invoice.aspx?filehash=somedata1293/323222、Base64エンコーディング、またはHTTP POSTは、カスタムルートなしでASP.NET MVCでfilehashの値を送信する唯一の方法です。
そのデータを取得したい場合は、Base64でエンコードする必要があります。
より良い解決策があるにもかかわらず、さまざまな文字セットをサポートする国際化されたアプリケーションでこのアプローチが採用されるのを見てきました。
ただし、Base64エンコーディングをセキュリティ対策として検討することはお勧めできません。初心者にとっては、多くの場合、カジュアルなURLの "ハッキング"が少し難しくなるためです。そして、はい、この場合、それは無名によるセキュリティです。