web-dev-qa-db-ja.com

Webサイトがスタック情報をスローするかどうか心配する必要がありますか？

Webページに簡単なログインフォームがあり、URLは次のようになっています。

example.com/signup/signup.php?q=1

私がこのようなことをしようとすると：

example.com/signup/signup.php?q=1&()

次のようなスタックダンプにリダイレクトされます。

exception 'DOMException' with message 'Invalid Character Error' in /<mydirectory>/a_xml.class.php:74
Stack trace:
#0 /<mydirectoy>/a_xml.class.php(74): DOMDocument->createElement('()')
...
#6 {main}

これはセキュリティの面で大きな問題ですか？悪意のあるユーザーがデータベースを改ざんまたは盗むことができる攻撃はありますか？それともこれは比較的無害であり、無視できますか？

web-applicationphpvulnerabilityerror-handling
49
Kevin

本番環境（開発とは逆）では、スタックトレースとエラーメッセージを画面にダンプするのではなく、ファイルに記録する必要があります。これは、攻撃者がシステムのセキュリティを侵害する可能性のあるシステムのことを知る可能性があるためです。

オペレーティングシステム、Webサーバーのバージョン、PHPバージョンなど）の情報。一部のスタックトレースには、公開すべきではないシステム/環境変数が含まれている可能性があります。

ユーザー/訪問者は、訪問者にとって役に立たないメッセージではなく、見栄えのよいHTTPエラーページを取得する必要があります。

66
Alasjo

これには2つの異なる側面があります。

  • スタックトレースの原因となるバグはセキュリティの脆弱性ですか。
  • スタックトレースを部外者に表示するように構成されたフレームワークです。

エラーメッセージInvalid Character Error忘れられたエスケープのように聞こえます。これは非常に頻繁に何らかの方法で悪用される可能性があります。スタックトレースはセキュリティの脆弱性の可能性があるため、心配する必要があります。

もう1つの質問は、部外者に表示されるスタックトレースについて心配する必要があるかどうかです。一方では、システムの内部に関する情報を隠すことは、あいまいさによるセキュリティと見なすことができます。ほとんどの場合、私はそれに同意しますが、スタックトレースの場合はそうではありません。

スタックトレースは問題がある場合にのみ表示されるため、スタックトレースがある場合はバグが存在するという重大なリスクがあり、バグがある場合はそれが悪用される可能性があります。したがって、スタックトレースを部外者から遠ざけることをお勧めします。さらに、スタックトレースに呼び出された関数の名前だけでなくパラメーター値も含まれている場合、キー、パスワード、Cookie、またはその他の種類の資格情報が簡単に漏洩する可能性があります。

上記の両方の理由により、スタックトレースが表示される場所に注意することが重要です。

ただし、問題を修正する必要がある人がスタックトレースを利用できることが重要です。したがって、スタックトレースのロギングは重要です。スタックトレースが実際のセキュリティの脆弱性を示している場合は、それらをできるだけ早く修正する必要があります。説明のないエラーメッセージは、攻撃者が操作するのに多くを与えるわけではありませんが、どの文字が機能し、どの文字が機能しないかを理解するだけで、とにかくそれを悪用する方法を見つけることができます。

25
kasperd

ここには2つの問題があり、OPはそれほど重要でない問題について尋ねます。

トレースを表示する

これはOPが尋ねる問題です。トレースを示す問題の程度が一般的であるという議論があり、この特定の例は、トレースを表示することをうまく表示していますセキュリティ上の問題。その理由は、それが私たち（あなた、私、そしてハッカー）に2番目の問題の存在を知らせてくれるからです。

ユーザー入力をフィルタリングしない

これは本当の問題です。 （トレースのおかげで）アプリケーションがフィルタリングされていない未検証のユーザー入力をネイティブのPHP関数に渡すことを知っているだけでなく、DOMDocument->createElement()が関数であることも知っていますこのサイトと、SQLインジェクションなどの他のフィルタリングの問題について、この会社で特定できるすべてのサイトを攻撃します。 、XSS、CSRF、ad nauseum。

15
dotancohen

スタックトレースにはパラメータが含まれていることに注意してください。引数としてパスワードを渡す関数呼び出しがある場合、それらは最終的にスタックトレースになります。

あるユーザーが別のユーザーのパスワードを彼に表示させることができれば、それは明らかに災いです。それほど明白ではありませんが、ユーザーパスワードはログファイルに保存されています。ユーザーを非常に怒らせるでしょう。少なくとも、パスワードのログが記録されないようにする必要があります。

7
Rob

あなたの例では、人々は潜在的な攻撃に使用できるディレクトリの構造を見ることができます。ほんの少しの情報で「ハッカー」がどれだけできるのか驚くでしょう。 はい一般に、セキュリティの点で大きな問題です。 Alasjoが言っているように、それもユーザーフレンドリーではなく、エラーページは良い代替手段です。

たとえば、ユーザーにエラーを表示するいくつかのケースでは、次の原因になる可能性があります Path Traversal

パストラバーサルは、.. /（ドットドットスラッシュ）攻撃、ディレクトリクライミング、バックトラックとも呼ばれます。

4
Loko

上記のコメントで言及されていますが、1つの理由に注意することは有用かもしれません

"オペレーティングシステム、Webサーバーのバージョン、PHPバージョンなどの情報。一部のスタックトレースには、公開すべきではないシステム/環境変数が含まれている可能性があります！"（@Alasjoによる上記のコメントと@ダニー・ベケット）

アプリケーションの構築に使用されるソフトウェアスタックを知っているため、攻撃者がそれらのコンポーネントのセキュリティ上の欠陥を悪用できるためです（一般的なソフトウェアのセキュリティの問題は広く公開されている情報です（ https://cve.mitre.org/ ））に加えて、アプリケーションの欠陥/欠陥がスタックトレースで明らかになります。

たとえば、サイトでPHPを使用していることがわかっているので、PHP関連するセキュリティ上の欠陥をすべて試してみませんか。 PHPその欠陥に対処するためのインストール...ソフトウェアスタックのパッチレベルを最新の状態に保ちますか？:-)）アプリケーションがスタックトレースの独自の欠陥を公開していなくても。

0
gentwo