web-dev-qa-db-ja.com

管理者のログインユーザー名/パスワードとしてGETメソッドを使用することは悪い習慣ですか？

私はウェブアプリケーションに取り組んでいます。ご存知のように、ほとんどの場合、管理者パネルを用意する必要があります。多くのWebアプリケーションには、管理者がパネルにログインするために使用できるフォーム（通常はPOSTメソッド）がある管理者用の特定のログインページがあることがわかります。

しかし、フィールド名がわかっているため、一部のセキュリティメソッドが実装されていても、ハッカーはパスワードを解読しようとする可能性があります。

では、単純なGETキー（ユーザー名として）とその値（パスワードとして）の問題は何でしょうか。なぜそれがあまり使われないか、少なくとも多くの記事で提案されていないのですか？

管理者にとって、ユーザーフレンドリーなログインページは本当に必要ありません！ MiTM攻撃者がいる場合、データは両方のケース（GET/POST）でログに記録されます。

ただし、この方法を使用すると、フィールドは管理者自身にとっては不明になります。サンプルPHPコード：

"category.php"：（無意味なページ名）

<?php
if (isset($_GET['meaningless_user']) && $_GET['meaningless_Word'] == "something"){
    session_start();
    $_SESSION["user"] = "test";
    header('Location: category.php');   // Redirect to same or other page so GET parameters will disappear from the url     
} else {
    die(); // So it'll be like a blank page
}
?>
authenticationweb-applicationphphttp
51
Amirreza Nasiri

これが理想的とは言えない理由がいくつか考えられます。

  • 投稿したコードスニペットでは、秘密鍵をプログラムのソースコードにハードコーディングしています。これは悪いことです。ソースコードを公開したり、他の人と共有したりする場合は、そのキーを編集することを忘れないでください。システムのセキュリティは、ソースコードが非表示になっていることに依存するべきではありません。
  • これはうまくスケーリングしません。すべての管理者が共有する必要がある秘密鍵が1つしかない場合は、誤って漏洩する可能性が非常に高くなります。リークが発生した場合、誰がリークしたかを知る方法はありません。管理者ごとに異なるキーを提供することもできますが、これは非常に煩雑になります。
  • キーを簡単に変更することはできません。一般的に言えば、サイト管理者はnotもサーバーオペレーターである必要があります。ただし、この設定では、ハンドルの使用方法を知っているかどうかわからないソースコードとサーバーへのアクセスも許可しない限り、キーを変更する権限を誰にも付与できません。本番システムで実行されているソースコードを微調整すると、エラーが発生しやすくなり、ダウンタイムが発生する可能性があります。
  • GETを使用するため、ブラウザの履歴や偶発的なリンク共有を通じてキーが漏洩するのは非常に簡単です。
  • あまりユーザーフレンドリーではありません。これを使用するには、特定のGETパラメータを手動で操作する方法を知っている必要があります。あなたは管理者にとって使い勝手は必要ないと言っていますが、これは間違いなく一般的には当てはまりません。サイト全体は、管理者パネルを含め、できるだけユーザーフレンドリーである必要があります。

要約すると、この種のシステムは、サイトのソースコードを記述してサーバーを管理するサイト管理者が1人いる小さなサイトでの一時的な対策として使用されていることがわかります。しかし、それよりも大きい場合は、実際の管理者ログインパネルを使用し、他のユーザーと同様に、ハッシュ化およびソルトされた資格情報をデータベースに保存する必要があります。

63
tlng05

これにより、パスワードとユーザー名を含むログインリンクがブラウザの履歴に保存されます。また、ファイアウォールのログなど、post変数をキャプチャしないものによって誤ってキャプチャされる可能性もあります。

137
jdow

厳密にはセキュリティの立場からではありませんが、 Hypertext Transfer Protocol-HTTP/1.1 RFC 2616 を使用すると、非常に明確になります。

...GETおよびHEADメソッドには、取得以外のアクションを実行することの重要性があるべきではないという規則が確立されています。これらのメソッドは「安全」と見なされるべきです。これにより、ユーザーエージェントはPOST、PUT、DELETEなどの他のメソッドを特別な方法で表すことができるため、ユーザーは安全でない可能性があるという事実をユーザーに認識させることができます。アクションが要求されています。

GETは検索にのみ使用してください。あなたのケースでは、あなたはサーバーにデータを送信しています、サーバーはこれらの特定のアクションを（少なくとも）実行しています：

  • ユーザーの認証
  • ユーザー状態を追跡するためのセッションの作成（PHPはフラットファイルまたはデータベースにセッションデータを作成します）
  • セッションを追跡するためのセッションCookieの設定

POST over HTTPSは、機密データを送信するための推奨される方法です。この場合のユーザー名、パスワード。

28
AbraCadaver

Webサーバーのアクセスログにクリアテキストで管理者パスワードを保存することにどの程度満足していますか？

ここで私が見る問題は、GETリクエストmustがすべてのフィールド名と値をリクエストURIに入れることです。リクエストURIはあらゆる種類のプロセスによってログに記録され、おそらくWebサーバーアクセスログに完全に保存されます。

これは、GETベースのログインページのユーザー名とパスワードが含まれているため、Webサーバーアクセスログのセキュリティリスクが高まることを意味します。通常、サーバーログは特権情報（たとえば、顧客のIP）を含むものとして扱うかもしれませんが、クライアントの管理インターフェイスを危険にさらすのに十分な情報を含むほど機密性が高いわけではありません。

フィールド名と値はログに保存されないため、POSTの方が優れています。

26
Andy Holland

悪意のあるユーザーが管理者の資格情報を取得します。画像タグの使用

<img src="https://example.com/login?username=admin&amp;password=topsecret" style="display:none">

ブラウザをだましてログインさせます（画像はデフォルトでクロスドメイン制限の対象ではありません）。次に、一連の「イメージ」呼び出しを使用してデータを取得または変更できます（AJAX呼び出しはGETを誤って使用します）。 これを回避する方法 =、しかし、ほとんどの人はそれらを有効にしません。POSTを使用している場合、この攻撃ベクトルは機能しません。

4
Machavity

Getメソッドを使用する際の問題は、デフォルトではデータが画面上とWebサーバーログに表示されることです。

私の経験則では、パスワードやブログ記事の編集者などの大きな情報には投稿を使用し、他のほとんどすべてにはgetを使用します。もちろん、データが機密性が高すぎてログにも表示できない場合は、いくつかの例外があります。しかし、それは企業部門でもまれです。

たとえば、5つのステップを持つウィザードのような機能があり、最初のステップでプロセスIDを生成し、すべてのステップで?proc_id=123が表示されます。 PHPは、postメソッドでもクエリ文字列をサポートします。フォームデータが大きすぎて、postメソッドを使用せざるを得ない場合でも、プロセスIDは?proc_id=123のようにURLに表示されます。

これにより、ブックマークがしやすくなり、アクセスログを理解しやすくなり、アプリとの統合を望むサードパーティの教育にも役立ちます。

このシナリオでは、再送信してはいけない履歴URLからのクリアなど、戻るボタンの問題を回避するためにいくつかの予防策を講じる必要があります。ほとんどの保存アクションはそのようなものです。

もちろんPOSTはMiTM攻撃から保護しません。パスワードなどの機密情報がサイトのログやブラウザのローカル履歴に書き込まれるのを防ぐだけです。

3
Lucas

また、GET要求はサーバー側で何も変更しないことを目的としていることも考慮してください。 「ログアウト」->「ログイン」のような状態変更は、常にPOSTリクエストで行う必要があります。

のようなGETパラメータを持っている

_https://example.com/loginpage.php?password=topsecret 
_

意味的に完全に同じ

_https://example.com/loginpage/password/topsecret 
_

したがって、認証はまったくありません。これは、「ログイン」するために知っておくべき「秘密」のURLにすぎません。

より明確にするために。たとえばApacheを使用している場合は、次のようなリダイレクトで同じ結果を得ることができます。

 RedirectTemp password/topsecret veryobfuscateddirectoryname/loggedin

次に、ログインしたページにsession_start()を配置します

3
Andre Geddert

ユーザーとパスワードがブラウザの履歴（URLパラメータとして）に保存されていない場合でも、ハッカーが情報を盗むのは非常に簡単です。それはサーバーのログに表示され、中間者攻撃をより簡単に実行します。また、ログインURLにブックマークを付けたり、それを忘れたり、他の人間にWebブラウザを使用させたりするなど、多くの悪い習慣を許します。

TL; DR：これは恐ろしい考えです。

2
Leo Wilson

はい、それは悪い習慣です。シークレットフィールド名を持つことで得られるセキュリティ上の利点は、そのシークレットをパスワードの先頭に追加することによっても得られます。

GETの代わりに

elephant=rthg4e5sdc

POST

password=elephantrthg4e5sdc

そしてもちろん、セキュリティをさらに向上させることができます。

password=ehu3dva7rthg4e5sdc
1
bdsl