web-dev-qa-db-ja.com

これらの暗号化されたURL値は安全ですか、それとも推測されますか？

サプライヤーの1人が、彼のWebページの安全なセクションに弱点を抱えていました。 URLのIDを変更することにより、自分のものではないデータを確認できました。

例えば：

契約と車を見せたが、そうした

他の数字を入れると他の車ができました。問題は、ほとんどの数字で、私たちの車ではなかった...

私たちは問題を知らせ、彼らはそれを修正しました。 URLは次のようになります。

 CAR 
 OLD URL 
 NEW URL

 1HTR701    
 https://supplier.org/showItem.do?contract.id=102210199&car.id=102334247
 https://supplier.org/showItem.do?values=Vod4UnO5hFROmmVBaiQWd9w8pkqti5OvrxjomCo9yNNSinKqUxYcUA%0D%0A

 1HTR801    
 https://supplier.org/showItem.do?contract.id=102210200&car.id=102334248
 https://supplier.org/showItem.do?values=Vod4UnO5hFROmmVBaiQWd7GlAD4zU43Z_yemm03qs7_vROna1Fd3GA%0D%0A

 1HTR802    
 https://supplier.org/showItem.do?contract.id=102210201&car.id=102334249
 https://supplier.org/showItem.do?values=Vod4UnO5hFROmmVBaiQWd38BWIjnkFKm8qQL3Ha-ibFo_kbZuctRLg%0D%0A

 1HTR803    
 https://supplier.org/showItem.do?contract.id=102210202&car.id=102334250
 https://supplier.org/showItem.do?values=Vod4UnO5hFROmmVBaiQWd0MJCJ7x4spAWvmXjtYiCibBrPzpvP3MnQ%0D%0A

しかし、私は彼らがこれをどのように修正したかについて混乱しています。特に戻る部分Vod4UnO5hFROmmVBaiQWdこれは、ある種のMD5またはその他のハッシュであると私に思わせます。他の部分が他の誰かに「推測可能」ではないことを願っています。

新しいURLがどのように構築されるかについてのアイデアはありますか？安全に見えますか？

web-applicationurlenumeration
5
Konerak

サイトにURLへのアクセス制御がある場合を除いて（最初に認証し、身元を証明し、次にサーバーがそのIDにそのURLを表示する権限があるかどうかを確認する必要があります）、いいえ、安全ではありません =。明らかな問題には、このようなサイトを通じてリンクを共有している人々（ドメインを編集せずに）、ブラウザが履歴内のURLを記憶している（共有コンピュータ上）、または誰か（内部または外部）がダンプして有効なURLのリストを共有していることが含まれます。

このタイプのセキュリティの脆弱性に使用される用語は「直接オブジェクト参照」であり、オブジェクトのIDを入力すると、通常はアクセスできない場合でもオブジェクトにアクセスできます。問題の唯一の真の解決策は、適切なアクセス制御です。 単にオブジェクトIDを推測するのを難しくしても問題は解決しません、ただし短期的には悪用を困難にする可能性があります。 URLにシークレットを入れても、実際には何も解決されません。実際の資格情報に依存するシステムが必要です。

さて、列挙については、コメントが指摘しているように、それは非常に疑わしいエンコーディングです。繰り返される接頭辞は、他に何をしていても、セキュアハッシュを使用していない（または正しく使用していない）ことを示しています。 URLからオブジェクトIDにマッピングしようとしていることを考えると、おそらくそれはリバーシブルエンコーディングです。

サーバーのみが知っている秘密鍵でURLクエリ文字列を暗号化すると、推測しにくいリンクが生成されますが、使用される暗号化のタイプによっては、暗号鍵を知らなくてもビットを反転して新しい有効なURLを生成できる場合があります（これを防ぐには、HMACや認証された暗号化スキームなどの整合性チェックを追加する必要があります。暗号化自体は、攻撃者が暗号文を改ざんすることを防ぐことはできません（一部の暗号化スキームでは、改ざんが簡単です）。いずれの場合も、このようなシステムは秘密のままのキーに依存しているため、単一障害点になります。

knownキーを使用したクエリ文字列の暗号化-たとえば、キーがその不変のプレフィックスにある場合-は完全に壊れています。使用されている暗号スキームを理解するには、（教育された）推測とチェックに少し時間がかかりますが、可能なシステムのスペースでは、検索にほとんど時間がかかりません。それがわかると、有効なURLを作成するのは簡単です。

これを行うための最も悪い方法（良い方法はありません。機密情報については、認証とアクセス制御を使用する必要があります）は、かなり長い（64ビット以上。GUIDはここでよく使用されます）、暗号で保護されたランダムな識別子を格納することです。データベースのすべての行に対して。次に、それらをURLに変換する前に、サーバー側の秘密鍵で暗号化します。これにより、有効なURLのリスト全体が危険にさらされる単一障害点（ランダムなIDはキーがないと役に立たない）を回避できます。また、IDトークンを定期的に変更して、それらのオブジェクトの古いURLを無効にすることもできます。 、または暗号化キーを変更してall古いURLを無効にします。 「この部分は数値であると想定し、ビットを反転して別の有効な数値を生成してみてください」と言う方法がないため、暗号文のビット反転に対して安全です。ビットの有効な組み合わせは、可能な識別子の検索スペースの予想外に小さい部分です。これは、識別子が連続的ではなく、それらのごくわずかな部分のみが使用されるほど長いためです。

しかし、私は再度強調する必要があります：これは、適切な認証と承認を配置するよりもはるかに悪い考えです。これを行った場合、次の値を推測しても攻撃者には何も得られないため、単純に増分する数値識別子に安全に固執できます。

7
CBHacking