ユーザーにテーブルの構造を開示することはどれほど危険ですか？
これが馬鹿げた質問なら、私は謝罪します。
最近、ウェブサイトへのリクエストが失敗した場合に、JSONレスポンスにエラーログアウトを埋め込んでいるウェブサイトを見つけました。この場合、DBの不一致があり、DBテーブルの構造を含むSQLリクエストを次のようにコンソールに出力しました。
これはどのように危険/危険なのですか、そしてなぜですか？
私の直感は、これは悪い習慣であり、安全ではないことを教えてくれますが、理由を正確に特定することはできません。
あなたが言及しているのは潜在的にエラーベースのSQLiの脆弱性であり、インバンド/クラシックSQLインジェクションとして知られるより大きなカテゴリーに分類されます。基本的に、これらの脆弱性により、攻撃者は攻撃を開始するだけでなく、同じ通信チャネルからデータベースに関する情報を収集することができます。実際にSQLiを試したかどうかはわからないので、単にエラーを発見しただけなので、これは潜在的な脆弱性にすぎないと言います。これは、許可を得れば、テストで確認できます。
潜在的に確認されているエラーベースのSQLi脆弱性は、データベース構造（おそらく指摘したとおり）に関する情報を提供し、攻撃者がデータベース（場合によってはデータベース全体）を列挙するのに役立ちます。
「私が信頼できない理由のない、こんにちは友好的なインターネットユーザーです。あなたが実行しようとしているクエリ（明らかに悪意がない）は、残念ながら正しくありません。次のクエリができるように、ここに私のデータベースの正確な構造があります。成功を収めるためにより適切に書かれています！」
このような詳細なエラーメッセージは、ライブサイトで無効にするか、アクセスが制限されたファイルに記録する必要があります。状況に応じて、絶対に必要以上の情報を提供しないことを認識しながら、ユーザーに400または500エラーを提供することをお勧めします。
テーブル構造を開示することは本質的に危険ではなく、アプリケーションにまだ存在していなかった新しいセキュリティの問題はありません。それはmay攻撃者がアプリケーションの既存のエクスプロイトを見つけるのを支援しますが、とにかく彼らはテーブル構造を解くことができるでしょう。
コードを確認したほとんどすべてのWebサイトのHTMLフォームの入力名は、実際には翻訳する必要がないため、db列とまったく同じです。通常、送信中に表示されない他の唯一の列は、id、created_at、deleted_at、author_idなどの明らかなものです。また、スキーマ全体を読み取ることができるが、それらのWebサイトはまだ安全であるオープンソースWebサイトが多数あることも考慮してください。
特にこの例の主な問題は、本番環境に残すことを意図していない開発用デバッグツールのようです。私の意見では、この例の情報は機密ではありませんが、多くの場合、デバッグツールは、パスワードを含む可能性のあるENV変数など、提供するのが非常に安全でない他の情報を提供します。
セキュリティに関心がある場合は、ユーザーが送信できるパラメータをフィルタリングして、ユーザーが自分のアカウントのロール列などを更新できないようにする必要があります。サーバーがそのパラメータを拒否した場合、ロール列があることを知っているユーザーは役に立ちません。