HTTP GET と HTTP POST を比較すると、セキュリティの観点からどのような違いがありますか? 選択肢の 1 つは、他の選択肢よりも本質的に安全ですか? もしそうなら、なぜですか？
POST が URL に関する情報を公開しないことは理解していますが、それには本当の価値があるのでしょうか、それとも隠蔽による単なるセキュリティなのでしょうか? セキュリティが懸念される場合に、POST を使用する必要がある理由はありますか?
編集:
HTTPS を介して、POST データはエンコードされますが、サードパーティによって URL が傍受される可能性はありますか? さらに、私は JSP を扱っています。JSP または同様のフレームワークを使用する場合、機密データを POST または GET に配置することを完全に避け、代わりにサーバー側コードを使用して機密情報を処理することがベスト プラクティスであると言えますか?
GET 要求は、POST 要求よりもわずかに安全性が低くなります。どちらもそれ自体で真の「セキュリティ」を提供しません。POST リクエストを使用しても、Web サイトが悪意のある攻撃に対して魔法のように安全になるわけではありません。ただし、GET 要求を使用すると、安全なアプリケーションが安全でなくなる可能性があります。
「変更を加えるために GET リクエストを使用してはならない」というマントラは依然として非常に有効ですが、これは悪意のある動作とはほとんど関係ありません。ログイン フォームは、間違ったリクエスト タイプを使用して送信されることに最も敏感です。
これが、データの変更に POST リクエストを使用する必要がある本当の理由です。検索スパイダーは、Web サイト上のすべてのリンクをたどりますが、見つけたランダムなフォームを送信することはありません。
Web アクセラレータは、クライアントのマシンで実行され、ログインしているユーザーのコンテキストですべてのリンクを「クリック」するため、検索スパイダーよりも劣っています。したがって、GET リクエストを使用して何かを削除するアプリケーションは、管理者が必要な場合でも、(悪意のない) Web アクセラレータの命令に喜んで従い、目にしたものすべてを削除します。
GET または POST リクエストのどちらを使用するかに関係なく、混乱した代理人攻撃(代理人がブラウザーである場合) が可能です。
攻撃者が制御する Web サイトでは、ユーザーの操作なしで GET と POST を同じように簡単に送信 できます。
POST の影響がわずかに少ない唯一のシナリオは、攻撃者の制御下にない多くの Web サイト (サードパーティ フォーラムなど) が任意の画像の埋め込みを許可し (攻撃者が任意の GET 要求を挿入できるようにする)、すべてを防止する場合です。自動か手動かを問わず、任意の POST リクエストを挿入する方法。
Web アクセラレータは混乱した代理攻撃の例であると主張する人もいるかもしれませんが、それは単なる定義の問題です。どちらかといえば、悪意のある攻撃者はこれを制御できないため、代理人が混乱していても、攻撃とは言えません。
プロキシ サーバーは、クエリ文字列を削除せずに、GET URL 全体をログに記録する可能性があります。通常、POST 要求パラメーターはログに記録されません。どちらの場合も、Cookie がログに記録される可能性はほとんどありません。（例）
これは、POST を支持する非常に弱い議論です。まず、暗号化されていないトラフィック全体をログに記録できます。悪意のあるプロキシは、必要なものをすべて備えています。第 2 に、攻撃者にとってリクエスト パラメータの用途は限られています。攻撃者が本当に必要としているのは Cookie であるため、プロキシ ログしか持っていない場合、GET または POST URL を攻撃することはほとんどできません。
ログイン リクエストには例外が 1 つあります。ログイン リクエストには、ユーザーのパスワードが含まれる傾向があります。これをプロキシ ログに保存すると、POST の場合には存在しない攻撃のベクトルが開かれます。ただし、プレーンな HTTP 経由のログインは本質的に安全ではありません。
キャッシング プロキシは GET 応答を保持する場合がありますが、POST 応答は保持しません。そうは言っても、URL を POST ハンドラーに変換するよりも少ない労力で、GET 応答をキャッシュ不可にすることができます。
ユーザーが GET 要求に応答して提供されたページからサード パーティの Web サイトに移動した場合、そのサード パーティの Web サイトはすべての GET 要求パラメーターを参照できます。
「要求パラメーターを第三者に公開する」のカテゴリに属し、その重大度はそれらのパラメーターに存在するものに依存します。POST リクエストは当然これに影響を受けませんが、GET リクエストを悪用するには、ハッカーは自分の Web サイトへのリンクをサーバーの応答に挿入する必要があります。
これは「プロキシ ログ」引数と非常によく似ています。GET リクエストは、パラメータとともにブラウザの履歴に保存されます。攻撃者は、マシンに物理的にアクセスできる場合、これらを簡単に取得できます。
ユーザーが「更新」を押すとすぐに、ブラウザーは GET 要求を再試行します。シャットダウン後にタブを復元するときに、それが行われる可能性があります。したがって、あらゆるアクション (支払いなど) が警告なしに繰り返されます。
ブラウザーは、警告なしに POST 要求を再試行しません。
これは、データの変更に POST 要求のみを使用する正当な理由ですが、悪意のある動作とは何の関係もないため、セキュリティとは関係ありません。
HTTPS 経由で POST データはエンコードされますが、URL は第三者によって傍受される可能性がありますか?
いいえ、盗聴することはできません。ただし、URL はブラウザーの履歴に保存されます。
機密データを POST または GET に完全に配置することを避け、代わりにサーバー側のコードを使用して機密情報を処理することがベスト プラクティスであると言えますか?
それがどれほど敏感か、より具体的にはどのような方法であるかによって異なります。明らかに、クライアントはそれを見ます。クライアントのコンピューターに物理的にアクセスできる人は誰でもそれを見ることができます。クライアントは、あなたに送り返すときにそれを偽装することができます. それらが重要な場合は、機密データをサーバーに保持し、放置しないでください。
セキュリティに関しては、それらは本質的に同じです。POST が URL を介して情報を公開しないことは事実ですが、クライアントとサーバー間の実際のネットワーク通信で GET と同じくらい多くの情報を公開します。機密情報を渡す必要がある場合、最初の防御策は、Secure HTTP を使用して情報を渡すことです。
GET またはクエリ文字列の投稿は、特定のアイテムをブックマークしたり、検索エンジンの最適化やアイテムのインデックス作成を支援したりするために必要な情報に非常に適しています。
POST は、1 回限りのデータを送信するために使用される標準フォームに適しています。ユーザーがクエリをブックマークに保存できるようにする検索フォームや、それらの行に沿ったものでない限り、実際のフォームを投稿するためにGETを使用しません。
変数は HTTP POST 経由で送信されるため、HTTP GET 経由で送信される変数よりも優れたセキュリティは提供されません。
HTTP/1.1 は、リクエストを送信するための一連のメソッドを提供します。
<html>
<body>
<form action="http://example.com" method="get">
User: <input type="text" name="username" /><br/>
Password: <input type="password" name="password" /><br/>
<input type="hidden" name="extra" value="lolcatz" />
<input type="submit"/>
</form>
</body>
</html>
ブラウザは何を尋ねますか? これは次のように尋ねます。
GET /?username=swordfish&password=hunter2&extra=lolcatz HTTP/1.1
Host: example.com
Connection: keep-alive
Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/ [...truncated]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) [...truncated]
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
POST / HTTP/1.1
Host: example.com
Connection: keep-alive
Content-Length: 49
Cache-Control: max-age=0
Origin: null
Content-Type: application/x-www-form-urlencoded
Accept: application/xml,application/xhtml+xml,text/ [...truncated]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; [...truncated]
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
username=swordfish&password=hunter2&extra=lolcatz
これらの HTTP リクエストは両方とも次のとおりです。
多くのブラウザーは、POST/GET 以外の HTTP メソッドをサポートしていません。
多くのブラウザー動作はページ アドレスを保存しますが、これは、これらの他の問題を無視できるという意味ではありません。
具体的には：
あるものは別のものよりも本質的に安全ですか? POST は URL に関する情報を公開しないことは理解していますが、それには本当の価値があるのでしょうか、それとも隠蔽による単なるセキュリティなのでしょうか? ここでのベストプラクティスは何ですか?
HTTP を話すために使用しているソフトウェアは、ある方法でリクエスト変数を保存する傾向があるため、これは正しいことです。別の方法では、誰かがあなたのブラウザの履歴を見たり、h4x0r1ng を理解していると思っている 10 歳からの素朴な攻撃を防いだりするだけです。 、または履歴ストアをチェックするスクリプト。履歴ストアをチェックできるスクリプトがあれば、ネットワーク トラフィックをチェックするスクリプトも同じように簡単に作成できます。
https を介して、POST データはエンコードされますが、URL は第三者によって傍受される可能性がありますか?
SSL の仕組みは次のとおりです。上記で送信した 2 つのリクエストを覚えていますか? SSL での表示は次のとおりです ( example.com は SSL で応答しないため、ページをhttps://encrypted.google.com/に変更しました)。
q5XQP%RWCd2u#o/T9oiOyR2_YO?yo/3#tR_G7 2_RO8w?FoaObi)
oXpB_y?oO4q?`2o?O4G5D12Aovo?C@?/P/oOEQC5v?vai /%0Odo
QVw#6eoGXBF_o?/u0_F!_1a0A?Q b%TFyS@Or1SR/O/o/_@5o&_o
9q1/?q$7yOAXOD5sc$H`BECo1w/`4?)f!%geOOF/!/#Of_f&AEI#
yvv/wu_b5?/o d9O?VOVOFHwRO/pO/OSv_/8/9o6b0FGOH61O?ti
/i7b?!_o8u%RS/Doai%/Be/d4$0sv_%YD2_/EOAO/C?vv/%X!T?R
_o_2yoBP)orw7H_yQsXOhoVUo49itare#cA?/c)I7R?YCsg ??c'
(_!(0u)o4eIis/S8Oo8_BDueC?1uUO%ooOI_o8WaoO/ x?B?oO@&
Pw?os9Od!c?/$3bWWeIrd_?( `P_C?7_g5O(ob(go?&/ooRxR'u/
T/yO3dS&??hIOB/?/OI?$oH2_?c_?OsD//0/_s%r
rV/O8ow1pc`?058/8OS_Qy/$7oSsU'qoo#vCbOO`vt?yFo_?EYif)
43`I/WOP_8oH0%3OqP_h/cBO&24?'?o_4`scooPSOVWYSV?H?pV!i
?78cU!_b5h'/b2coWD?/43Tu?153pI/9?R8!_Od"(//O_a#t8x?__
bb3D?05Dh/PrS6_/&5p@V f $)/xvxfgO'q@y&e&S0rB3D/Y_/fO?
_'woRbOV?_!yxSOdwo1G1?8d_p?4fo81VS3sAOvO/Db/br)f4fOxt
_Qs3EO/?2O/TOo_8p82FOt/hO?X_P3o"OVQO_?Ww_dr"'DxHwo//P
oEfGtt/_o)5RgoGqui&AXEq/oXv&//?%/6_?/x_OTgOEE%v (u(?/
t7DX1O8oD?fVObiooi'8)so?o??`o"FyVOByY_ Supo? /'i?Oi"4
tr'9/o_7too7q?c2Pv
(注: HEX を ASCII に変換しましたが、一部は明らかに表示できないはずです)
HTTP 会話全体が暗号化され、通信の唯一の目に見える部分は TCP/IP 層 (つまり、IP アドレスと接続ポート情報) にあります。
POST が対象とする唯一のセキュリティ対策は? ブラウザの履歴をひっくり返す嫉妬深い元からの保護。それでおしまい。残りの世界はあなたのアカウントにログインし、あなたを笑っています。
POST が安全でない理由をさらに示すために、Facebook はあらゆる場所で POST リクエストを使用しています。
HTTPS を使用していて、サイトにXSS脆弱性が含まれていない場合でも、 CSRFで攻撃される可能性があることに注意してください。要するに、この攻撃シナリオは、被害者 (サイトまたはサービスのユーザー) が既にログインしており、適切な Cookie を持っていることを前提としています。次に、被害者のブラウザーが (おそらく安全な) サイトで何かを行うように要求されます。CSRF に対する保護がない場合でも、攻撃者は被害者の資格情報を使用してアクションを実行できます。サーバーの応答は被害者のブラウザに転送されるため、攻撃者はそれを見ることができませんが、通常、その時点ですでに損害が発生しています。
追加のセキュリティはありません。
投稿データは履歴やログ ファイルには表示されませんが、データを安全に保つ必要がある場合は SSL が必要です。
そうしないと、ネットワークを盗聴している誰かがあなたのデータを読み取ることができます。
ログインフォームや比較的機密性の高い情報を含むその他のフォームPOSTに対して、実際のセキュリティ上の利点がない場合でも、次のように使用していることを確認してください。GETPOST
POSTはユーザーの履歴に保存されません。GETすると、履歴と URL バーに表示されます)。また、GETデータの理論的な制限があります。POSTしません。
実際の機密情報については、必ずSSL( HTTPS)を使用してください
Neither one of GET and POST is inherently "more secure" than the other, just like neither one of fax and phone is "more secure" than the other. The various HTTP methods are provided so that you can choose the one which is most appropiate for the problem you're trying to solve. GET is more appropiate for idempotent queries while POST is more appropiate for "action" queries, but you can shoot yourself in the foot just as easily with any of them if you don't understand the security architecture for the application you're maintaining.
It's probably best if you read Chapter 9: Method Definitions of the HTTP/1.1 RFC to get an overall idea of what GET and POST were originally envisioned ot mean.
GET と POST の違いは、セキュリティの観点からではなく、サーバーに対する意図の観点から見る必要があります。GET はサーバー上のデータを変更するべきではありません (少なくともログ以外では)。ただし、POST は新しいリソースを作成できます。
優れたプロキシは POST データをキャッシュしませんが、URL からの GET データをキャッシュする可能性があるため、POST の方が安全であると言えます。しかし、POST データは、うまく動作しないプロキシでも引き続き利用できます。
多くの回答で述べたように、唯一確実な方法は SSL を使用することです。
ただし、データベース行の削除など、GET メソッドが変更をコミットしないようにしてください。
これはセキュリティ関連ではありませんが...ブラウザはPOSTリクエストをキャッシュしません。
私の通常の選択方法は次のようなものです。
どちらも魔法のようにリクエストにセキュリティを付与するわけではありませんが、GET には、一般的にセキュリティを確保するのを妨げるいくつかの副作用があります。
GET URL は、ブラウザーの履歴と Web サーバーのログに表示されます。このため、ログイン フォームやクレジット カード番号などには使用しないでください。
ただし、そのデータを POST するだけでは安全ではありません。そのためにはSSLが必要です。GET と POST はどちらも、HTTP 経由で使用される場合、データを平文でネットワーク経由で送信します。
データを POST する他の正当な理由もあります - 無制限の量のデータを送信する機能や、一般ユーザーからパラメーターを非表示にする機能などです。
欠点は、ユーザーが POST 経由で送信されたクエリの結果をブックマークできないことです。そのためには、GET が必要です。
次の状況を考えてみましょう: ずさんな API は、次のような GET 要求を受け入れます。
http://www.example.com/api?apikey=abcdef123456&action=deleteCategory&id=1
一部の設定では、この URL をリクエストしたときに、リクエストに関するエラー/警告が発生した場合、この行全体がログ ファイルに記録されます。さらに悪いことに、本番サーバーでエラー メッセージを無効にするのを忘れた場合、この情報はブラウザにそのまま表示されます。これで、API キーを全員に配布できました。
残念ながら、このように動作する実際の API があります。
ログに機密情報を記録したり、ブラウザに表示したりするのは好きではありません。POST と GET は同じではありません。それぞれ適切な場所で使用してください。
POST リクエストを変更するのは困難です (クエリ文字列を編集するよりも多くの労力が必要です)。編集：言い換えれば、それはあいまいさによるセキュリティであり、それはほとんどありません。
何に対してセキュリティを確保したいかを定義しない限り、セキュリティの概念は無意味です。
保存されたブラウザの履歴、ある種のログ記録、および URL を見ている人々に対して安全を確保したい場合は、POST の方が安全です。
誰かがあなたのネットワーク アクティビティを傍受するのを防ぎたいのであれば、違いはありません。
また、サイトに他の外部サイトへのリンクが含まれている場合、GETを使用して制御できない場合、外部サイトがサイトのリンクを押すと、そのデータが外部サイトのrefeererヘッダーに配置されることに注意してください。したがって、GETメソッドを介してログインデータを転送することは常に大きな問題です。ログを確認するか、Google Analytics（または同様のもの）を調べるだけで簡単にアクセスできるように、ログイン資格情報が公開される可能性があるためです。
他のすべての答えを繰り返すつもりはありませんが、まだ言及されていない側面が1つあります。それは、データが消えるという話です。どこにあるのかわかりませんが...
基本的には、不思議なことに数晩ごとにすべてのデータが失われ、その理由を誰も知らなかったWebアプリケーションに関するものです。後でログを調べると、サイトがグーグルまたは別の任意のスパイダーによって発見され、「このエントリを削除する」および「よろしいですか？」を含む、サイトで見つかったすべてのリンクを喜んでGET（読み取り：GOT）することがわかりました。リンク。
実際、これの一部が言及されています。これは、「GETでデータを変更せず、POSTでのみデータを変更する」の背後にあるストーリーです。クローラーは喜んでGETに従い、POSTはしません。robots.txtでさえ、クローラーの誤動作を防ぐのに役立ちません。
多くの人は、GET リクエストはデータを取得するだけで、サーバー上のデータを変更しないという規則 (Ross がほのめかした) を採用しており、POST リクエストはすべてのデータ変更に使用されます。一方が他方よりも本質的に安全というわけではありませんが、この規則に従えば、分野横断的なセキュリティ ロジックを適用できます (たとえば、アカウントを持つ人だけがデータを変更できるため、認証されていない POST は拒否されます)。
RFC7231:
" URI は、保護されたリソースを識別する場合でも、共有されることを意図しており、保護されていません。URI は、多くの場合、ディスプレイに表示され、ページが印刷されるときにテンプレートに追加され、さまざまな保護されていないブックマーク リストに保存されます。したがって、含めることは賢明ではありません。機密情報、個人を特定できる情報、または開示するリスクがある URI 内の情報。
サービスの作成者は、機密データの送信に GET ベースのフォームを使用しないようにする必要があります。これは、そのデータがリクエスト ターゲットに配置されるためです。多くの既存のサーバー、プロキシ、およびユーザー エージェントは、第三者に見える可能性のある場所にリクエスト ターゲットを記録または表示します。そのようなサービスでは、代わりに POST ベースのフォーム送信を使用する必要があります。」
この RFC は、GET を使用して機密データを送信してはならないことを明確に述べています。この注意事項のため、一部の実装者は、GET 要求のクエリ部分から取得したデータを同じ注意で処理しない場合があります。私は、データの整合性を保証するプロトコルに取り組んでいます。この仕様によれば、GET データの整合性を保証する必要はありません (誰もこれらの仕様に準拠していないため、保証します)。
違いは、GETがデータを開いてPOSTを非表示（httpヘッダー内）に送信することです。
したがって、Googleのクエリ文字列など、セキュリティで保護されていないデータにはgetの方が適しています。Auth-dataはGET経由で送信されないため、ここでPOSTを使用します。もちろん、テーマ全体はもう少し複雑です。詳細をお読みになりたい場合は、この記事（ドイツ語）をお読みください。
GET は誰にでも (今はあなたの肩に乗っている人でも) 見ることができ、キャッシュに保存されるため、投稿を使用する安全性は低くなります。ところで、いくつかの暗号化ルーチンを使用せずに投稿することは確実ではありません。少しセキュリティを確保するために、SSL を使用する必要があります ( https)
最近、中間者が圧縮された HTTPS リクエストのリクエスト ボディを明らかにできる攻撃が公開されました。リクエスト ヘッダーと URL は HTTP によって圧縮されないため、GET リクエストはこの特定の攻撃に対してより安全に保護されます。
GET リクエストも脆弱なモードがあり、SPDY はリクエスト ヘッダーを圧縮し、TLS はオプションの (めったに使用されない) 圧縮も提供します。これらのシナリオでは、攻撃を防ぐのは簡単です (ブラウザー ベンダーは既に修正プログラムを提供しています)。HTTP レベルの圧縮はより基本的な機能であり、ベンダーがそれを無効にすることはまずありません。
GET が POST よりも安全であるシナリオを示した単なる例ですが、この攻撃の理由から、POST よりも GET を選択することは得策ではないと思います。攻撃は非常に巧妙で、重要な前提条件が必要です (攻撃者は要求コンテンツの一部を制御できる必要があります)。攻撃が有害なシナリオでは、HTTP 圧縮を無効にすることをお勧めします。
POST がセキュリティ上劣る理由の 1 つは、GETがデフォルトでログに記録され、パラメータとすべてのデータが Web サーバーによってほぼ普遍的にログに記録されることです。
POSTは反対で、ほぼ例外なくログに記録されないため、攻撃者の活動を特定するのが非常に困難になります。
私は「大きすぎる」という議論を支持しません。それは何もログに記録しない理由にはなりません。少なくとも 1KB は、攻撃者が攻撃者を識別するのに大いに役立ちます。 HTTP ベースのバックドアが黙って無制限の量のデータを通過できるようにすることで、二重の不利益をもたらします。
これは古い投稿ですが、いくつかの回答に反対したいと思います。機密データを転送する場合は、SSLを使用することをお勧めします。GETパラメーター（例：？userid = 123）でSSLを使用する場合、そのデータはプレーンテキストで送信されます。POSTを使用して送信する場合、値はメッセージの暗号化された本文に入れられるため、ほとんどのMITM攻撃で読み取ることはできません。
大きな違いは、データが渡される場所です。データがURLに配置されている場合、暗号化できないことは意味があります。そうしないと、URLを読み取ることができるのは自分だけであるため、サーバーにルーティングできません。これがGETの仕組みです。
つまり、POST over SSLでデータを安全に送信できますが、SSLを使用しているかどうかに関係なく、GETでは送信できません。
POST でも GET リクエストを受け付けます。user.name や user.passwd などの入力を含むフォームがあるとします。これらはユーザー名とパスワードをサポートするはずです。単に ?user.name="my user&user.passwd="my password" を追加すると、「ログオン ページをバイパスする」ことによって要求が受け入れられます。
これに対する解決策は、サーバー側でフィルター (e としての Java フィルター) を実装し、文字列クエリが GET 引数として渡されないことを検出することです。