何か問題が発生した場合、WebページにMySQLクエリエラーを表示しても安全ですか？
以下の詳細を含むエラーWebページに詳細なクエリを表示しても安全ですか？
** INSERTステートメントがFOREIGN KEY制約「ABC」と競合しました。データベースで競合が発生しました**ステートメントは終了しました。[INSERT INTO **] **
この種のエラーを表示することが侵入テスターやハッカーの助けになることは知っていますが、私はこれに光を当てる誰かが必要です。この情報をSQLインジェクションなどにどのように使用できますか？それとも、そのような機密情報を表示しても大丈夫ですか？
エンドユーザーは、環境の悲惨な詳細を見ることはありません。
代わりに、一般的な「申し訳ありませんが問題が発生しました」ページを表示する方が専門的です。少なくとも訪問者はあなたがあなたのウェブサイトに存在する本当のエラー処理メカニズムを持っていることを見ることができます。
ただし、これらのエラーはmysqlエラーログに書き込まれ、電子メールまたはその他の方法でITチームへの通知をトリガーする必要があります。これらのエラーは発生しないはずなので、サイトに障害が発生しているか、サイトが攻撃を受けている可能性があります。
いいえ、他の方法では存在しない追加のSQLインジェクション攻撃ベクトルを作成するため、安全ではありません。例：挿入にSQLインジェクションフローがある場合、挿入は呼び出し元に結果行を報告しないため、これは一種の「ブラインド」インジェクションです。しかし、潜在的な挿入エラーメッセージをクライアントに戻す場合、これをいわゆる「XPath」インジェクションに対して脆弱にします（詳細は この論文 を参照）。本質は、データ型xmlの変数を計算することになっているxml関数を注入することです。関数の引数の1つは、selectステートメントと文字列連結によって再び計算できるxpath変数です。有効なxpathを提供する代わりに、選択を行います（例：「select password_hash where users where id = 'admin'」）。したがって、DBはインジェクションを通じて意図的に間違っているINSERTを実行します。結果は次のようなエラーメッセージになります
'bb9af55cd325deaa89bb7b4e36085b4d'は有効なxpathではありません
このようなエラーメッセージを呼び出し元に表示する場合、これを使用して基本的にDBを列挙できます。私はこれが最近起こっているのを見ました。エラーメッセージは30文字にカットされ、一度に選択できるのは1つの列と1つの行だけでしたが、それでもDB全体を列挙することは可能でした。
MySQLの詳細が本番サーバー上のWebサイト/アプリケーションのメインユーザーインターフェースを介して公開されるべきではない理由について、他の人が正当に触れています。
しかし、次のようにエンドユーザーにエラーを表示すると、より広範囲で、より高レベルの問題が発生します。
それは基本的に、サーバー/サイトが適切に管理されていないという考えを電報で伝えます。
詳細の内容ではなく、詳細がそもそも公開されているため、あなたがハッキングのより的確な標的であることを意味します。
アプリケーション開発者（システム管理者など）としてのあなたの態度は、最終製品がシステムのアーキテクチャの「骨」を露呈せずに何らかの形で有用なデバッグデータを何らかの形で伝えない何らかの方法で正常に失敗するようにすることです。
アプリケーションが正しく設計されていれば、エラーメッセージのテキストを表示してもセキュリティ上の問題にはなりません。もしそうなら、それはあなたのセキュリティが悪い習慣と見なされる難読化に依存していることを意味します。
それが本当の質問だと言われている：そのようなメッセージに直面しているユーザーエクスペリエンスは何でしょうか？アプリケーションが平均的なユーザー向けのものである場合、ユーザーは何も理解していないか、またはそれを使用して何か有用なことを行うことができないという、有用な情報をもたらさないメッセージを受け取ります。さらに悪いことに、彼らはこれらの怠惰な開発者はエラーを正しく処理しさえしなかった-それは私が思うことです...
これが、一般的な使用法が、問題が発生したことを示すソフトなメッセージを表示する理由です。エラーが解消されない場合は、再試行し、サポートに連絡してください。サポート技術者がエラーの詳細に関心を持っているため、アプリケーションが特別なモードでサポートによって実行されている場合にのみ、完全なエラーメッセージが表示されます。
エラーで本当に素晴らしい仕事をしたい場合：
- エラーとそのコンテキストをログに記録していることを確認してください：リクエストの日時、ユーザー、パラメーター、最終的にはサポートがチケットに入力できるようにするキーセッションデータは、アプリケーションで修正する必要があります
- ソフトのみを表示externalユーザーへの情報
- エラーを再現しようとするときに、サポートがエラーの詳細すべてにアクセスするための特定の方法を追加します-コストがかかりますが、サポート技術者から高く評価されます
- 最終的にインシデントに一意のIDを割り当て、それをユーザーに表示します
この最後の可能性は、ユーザー数が限られた高価値のアプリケーションに対してのみ意味があります。これにより、ユーザーから連絡があったときに、サポートが問題のすべてのリファレンスをすぐに入手できるようになります。しかし、それはnormalアプリケーションにとって非常にコストのかかるエラーに対して個別に回答する準備ができていることも意味します。
攻撃者が入手できる技術的な詳細は、潜在的に、欠陥を悪用したり、システムをより深く理解したりするために利用できます（後で、欠陥を悪用します...）。あなたのケースでは、SQLインジェクションに利用できる可能性がありますが、DBMSを特定し（たとえば、MySQLに固有の機能を持つネイティブクエリを使用する場合）、システムにパッチが適用されていない場合にDBMS固有のエクスプロイトをテストできます。
したがって、質問に答えるには、いいえ、クエリを開示することは安全ではありません。これを行うと、セキュリティリスクが高まるためです。
コメントで述べたように、ベストプラクティスは、本番環境でそのような情報を非表示にすることです。
一般的な方法（たとえば、Java開発者）のMavenプロファイル）は、特定の環境用にプロジェクトをビルドすることです。「本番」プロファイルには、html応答にスタックトレースを表示しない別の構成があります代わりにそれらをバックエンドに記録するだけです。
補足として、技術的なエラーメッセージを表示すると、弱いターゲットのように見えるため、システムをハッキングしてスキルを磨こうとするランダムな攻撃者を「引き付け」ます。
多くの回答が、これらのエラーを表示することはベストプラクティスではないと指摘しています。しかし、私はあなたの質問に焦点を当てます：それは安全ですか？
エラーメッセージの例を見てみましょう。このアプリはPython and Flaskで記述されています：
これは、アプリケーションについていくつかのことを教えてくれます。それはSQLiteを使用しており、アプリケーションはc:\jobs\token\、テーブルdataといくつかの他のものがあります。
ここにはユーザーデータはありません。他人の口座残高やプライベートメッセージなどは明らかにしません。エラーメッセージがそれを明らかにする可能性がありますが、実際にはまれです。
では、アプリケーションの詳細はどの程度機密ですか？ここでの主な関心事は、攻撃者の生活を楽にすることです。パストラバーサルやSQLインジェクションなどの特定の脆弱性は、エラーメッセージに少しの情報漏えいがあれば、より悪用されやすくなります。ただし、情報漏えいなしで引き続き悪用可能です-それはより困難な作業です。エラーメッセージを制限しても、これらの攻撃は阻止されません。それは悪用を少し難しくするだけです。 SQLインジェクションのような脆弱性のリスクを評価しているときは、変更はあまりにも小さいので考慮しません。
だから、あなたの質問への答えははい、それは安全です。これはベストプラクティスではありませんが、特に安全ではありません。
データベース設定の詳細を提供することは、一般的に悪い考えです。正当なユーザーはそれを知る必要はありません。悪意のあるユーザーは、推測する必要がある何かをそこで見つける可能性があります。
他の回答では、これがデータベースにどのようなリスクをもたらす可能性があるかをかなり詳しく説明しています。
エラーレポートを表示すると、Webサイトにまったく新しい攻撃ベクトルが開かれる可能性もあります。たとえば、ID <script>alert('XSS')</script>のドキュメントをリクエストした場合、データベースにドキュメントが見つからず、エラーレポートが表示されたとしましょう。多くの場合、エラーハンドラーはコードベースの最も慎重に構築された部分ではないため、サイトに対してXSS攻撃を実行できた可能性があります。
SQLステートメントの構文エラーメッセージはneverを明らかにする必要があります。これにより、攻撃者がSQLiを悪用しようとする時間を節約できます。脆弱性。
アプリケーションの行番号はそれほど深刻ではありませんが、セキュリティの観点から、エラーページすべきではありませんは詳細を明らかにします。エラーページは、ハッキングを成功させるための中間ステップであるためです。
詳細なエラーページの利便性を維持したい場合は、LAN IPアドレスに基づいて許可された人にのみそのような詳細を公開するようにシステムを構成することをお勧めします。また、いくつかのCookieベースの認証もお勧めします。独自のカスタムエラーページをコーディングする場合、これはかなり簡単なことです。
それ以外の場合は、そのような詳細が必要な場合はいつでも、エラーログを調べるというあまり便利ではないアプローチを使用する必要があります。
ユーザーに実際のエラーを表示しないことを強くお勧めします。これは、MySQLだけでなく、どこにでも当てはまります。エラーを処理するには、try catchブロックを使用する必要があります。
あなたのケースでは、ユーザーまたは攻撃者がテーブル名、行の詳細、名前を見る可能性があります。ハッカーは、提供されたエラーを通じてSQLインジェクションまたはその他の攻撃を使用する可能性があります。したがって、これらの機密情報を非表示にすることをお勧めします。
間違いなくnotデータベース環境の詳細をユーザーに示すことは良い考えです。システムのバックエンドは、ユーザーにとって完全に謎である必要があります。サーバーログには、表示したエラーなどのエラーを診断するのに十分な情報が含まれているはずです。
また、ユーザーがWebアプリケーションの任意のページのソースを表示した場合に何が表示されるかを検討する必要があります。ページのソースはデータベーステーブルまたは列の詳細をフォームフィールド名で明らかにしますか？
時間がある場合は、データベースに存在しないデータベースオブジェクトを説明する偽のエラーメッセージを表示して、攻撃者を混乱させることができます。その後、攻撃者はこれらのテーブルを攻撃しようとして苛立ちます。